Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Site Security Policy - Yahoo! Security Week


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

Site Security Policy - Yahoo! Security Week

  1. 1. Web Application Security and the Browser Brandon Sterne 5/15/2008
  2. 2. Agenda • Browsers can do more to protect users and websites • “Intranet Hacking” • Protect the resources that live inside the firewall or home router • Cross-site Scripting and Cross-Site Request Forgery • Protect users and websites from each other in a world where the Same-Origin policy is often broken 2
  3. 3. Not the only solution... • Best Option: Writing secure applications • Employ good input and output filtering • Check form keys, HTTP Referer, etc. • Follow security best practices [1] • Defense in Depth • Writing reliably secure web applications is hard • The browser can provide an additional layer of security and can intervene to prevent malicious activity [1] 3
  4. 4. Hacking the Intranet • Malicious webpages use the victim's browser to make HTTP requests to protected intranet resources • Corporate directories, IP telephones, printers, routers • Any firewall that blocks unwanted ports and services provides no protection here because HTTP is enabled everywhere • Any web-enabled device can be potentially attacked by malicious content • Home routers have been attacked using this technique to tamper with DNS settings, etc. • Ask Jeremiah Grossman about what other types of evil you can cause using these techniques 4
  5. 5. Drawing the Boundary • Why should websites on the Internet be able to initiate requests to resources in my intranet? • Let's draw a line between “public” and “private” resources (RFC1918 is a good start) • Mozilla is developing a patch to prevent public resources from making requests to private resources (but allowing the reverse) 5
  6. 6. Easy, Tiger... Not So Fast • Proxies complicate matters • There are many, usually corporate, environments that use HTTP proxies for their web surfing, e.g. WebSense • Even some home users configure their browser to use an internal web proxy • How should we treat proxied content? • Mark all proxied content as “public”? – Protects intranet resources but breaks a lot of functionality • Place proxy outside NAT environment and use it for “public” resources only – Lots of work for IT department: reconfigure network and DNS • Rely on proxies to mark resources as “public” and “private”? – Introduces external dependency on other services to behave predictably • Any Ideas? Really. 6
  7. 7. Site Security Policy •Background • Last 3 years: dramatic increase in both awareness [1][2] and exploitation [3] of Web Application Vulnerabilities • 2007: dozens of high profile attacks [4] against websites using Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) • Many sites have programs in place to find and remediate the vulnerabilities • Sheer size and complexity of websites make complete remediation of the security holes implausible [1] - [2] - [3] - [4] - 7
  8. 8. Again, browsers can do more... ● Protect users from vulnerable sites ● Protect sites from receiving forged requests ● Enable websites to define security policies that the browser enforces ● restrict the capabilities of web content which makes these attacks possible in the first place ● Not a silver bullet... only an additional layer of security 8
  9. 9. Review: Cross-Site Scripting (XSS) • Many good XSS references available [5][6][7] • Exploits the client's trust of the server • 3 Types of XSS • Stored (Persistent) • Reflected • DOM-based • Cookie stealing, website defacement, XSS worms... [5] - [6] - [7] - 9
  10. 10. XSS and Site Security Policy • Provides a way for server administrators to reduce or eliminate XSS attack surface • Administrators specify which domains are valid sources of script • Browser only executes script in source files from white-listed domains 10
  11. 11. XSS and Site Security Policy • Script-Source Instructions • Indicate a (potentially empty) set of domains that should be treated as valid sources of JavaScript • Any script embedded within the page and any script from non-white-listed hosts will not be executed • Consequence: authors must place event handling code in external script files • Syntax (open to debate) • Instructions contain one or more pairs of the form (“allow or deny”, “host item”) • Script-Source: allow *; deny 11
  12. 12. Impact on XSS • Dramatically changes the difficulty of mounting a successful XSS attack • Attacker needs to control the contents of white-listed JavaScript source files • Attacks using inline JavaScript are no longer effective • In some cases, XSS risk can be fully mitigated • Sites can choose to globally disallow JavaScript 12
  13. 13. Review: Cross-Site Request Forgery (CSRF) • Many good CSRF references [8][9][10] • Exploits a server's trust of the requests it receives from clients • Attackers craft web content that creates bogus requests on behalf of the victim • Extremely widespread • Non-trivial solution • Best practice: create a CSRF-protection framework in your application, use it globally [8] - [9] - [10] - 13
  14. 14. CSRF and Site Security Policy • Provides controls for admins to define how websites handle cross-site requests • Ingress Filtering • Explicitly define which domains can initiate cross-site requests to resources in the site • Egress Filtering • Define domains to which content in their site can initiate requests • “Good net citizen” 14
  15. 15. CSRF and Site Security Policy • Ingress Filtering: Request-Source Instructions • Indicate a (potentially empty) set of domains whose content should be allowed to request the resource • Supporting User-Agents will make a preemptive policy check before sending content-initiated cross-site requests • CSRF prevention is primarily the responsibility of the receiving server (precedence over Request-Target) • Similar to the Access-Control model [11] • Requests made via non-safe HTTP methods will be blocked if they violate security policy [11] - 15
  16. 16. CSRF and Site Security Policy • Syntax (open to debate) • Policy query – HEAD request from the UA to the cross-site resource – Contains HTTP header Policy-Query • Policy response: Request-Source – Instructions consist of one or more triplets of the form (“allow or deny”, “host item”, “list of HTTP methods”) plus optional “expires” value for policy caching – Request-Source: deny * post; allow * get; expires 60 – Request-Source: allow * post,get; deny *; expires 3600 16
  17. 17. CSRF and Site Security Policy • Egress Filtering: Request-Target Instructions • Indicate a (potentially empty) set of hosts to which page's content can make cross-site requests • Stop page content outbound communication • Prevents data from being exfiltrated from the site • Prevents additional non-intended resources from being included in the page • Restrict a website from being used as a platform to attack other websites via CSRF • May be useful for sites that permit users to post HTML and JavaScript in publicly accessible areas 17
  18. 18. CSRF and Site Security Policy • Request-Target Syntax (open to debate) • Contains one or more triplets of the form (“allow or deny”, “host item”, “list of HTTP methods”) • Request-Target: allow * *, deny post 18
  19. 19. Impact on CSRF • Simple way for a website to prevent CSRF against its sensitive resources • Adds layer of security to an application's CSRF protection mechanisms • CSRF protection complicated to implement and difficult to integrate into existing web applications • Even properly implemented CSRF-protection systems will not stand up when XSS is present • Fully control how content inside and outside a website interacts 19
  20. 20. Who Is Breaking Our Rules? • Site Security Policy can tell us when policies are “violated” • Report-URI instruction tells the browser where to send reports when something is blocked • A POST to the specified URI containing the full HTTP request which led to the policy violation • Possible Syntax: Report-URI: • Who is attacking us with XSS or CSRF? • Which of our pages are misconfigured? 20
  21. 21. Backward Compatibility • Fully backward compatible • Will not affect sites or browsers which do not support Site Security Policy • User-Agents can disregard policy definition headers and fall back to Same-Origin policy • In the absence of policy headers, supporting Uas will fall back to Same-Origin • Admins can define Site Security Policy without fear of web compatibility problems 21
  22. 22. Conclusions • Computer Security best achieved through a variety of overlapping controls • Site Security Policy aims to be one part of a larger defense-in-depth strategy • “Belt-and-braces...” -Gerv [12] • Mitigate broad classes of vulnerabilities (for supporting UAs) by defining a few simple rules • Admins should maintain normal security auditing and remediation process [12] - 22
  23. 23. Thank You Questions? Brandon Sterne