Site Security Policy - Yahoo! Security Week


Published on

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

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

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