Site Security Policy - Yahoo! Security Week

Web Application Security and the Browser Brandon Sterne 5/15/2008

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

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] http://www.owasp.org/index.php/Secure_Coding_Principles 3

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

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

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

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] - http://weblog.infoworld.com/zeroday/archives/2007/10/study_90_percen.html [2] - http://weblog.infoworld.com/zeroday/archives/2007/11/report_90_perce.html [3] - http://www.webappsec.org/projects/whid/statistics.shtml [4] - http://www.webappsec.org/projects/whid/byyear_year_2007.shtml 7

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

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] - http://www.cgisecurity.com/articles/xss-faq.shtml [6] - http://www.owasp.org/index.php/Cross_Site_Scripting [7] - http://ha.ckers.org/xss.html 9

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

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 *.example.com; deny public.example.com 11

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

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] - http://www.owasp.org/index.php/Cross-Site_Request_Forgery [9] - http://www.cgisecurity.com/articles/csrf-faq.shtml [10] - http://shiflett.org/articles/cross-site-request-forgeries 13

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

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] - http://www.w3.org/TR/access-control/ 15

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 *.example.com post,get; deny public.example.com *; expires 3600 16

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

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 *.example.com *, deny public.example.com post 18

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

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: http://www.example.com/policy.cgi • Who is attacking us with XSS or CSRF? • Which of our pages are misconfigured? 20

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

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] - http://www.gerv.net/security/content-restrictions/ 22

Thank You Questions? Brandon Sterne bsterne@mozilla.com

Site Security Policy - Yahoo! Security Week

by guest9663eb on May 20, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

Site Security Policy - Yahoo! Security Week — Presentation Transcript