Your SlideShare is downloading. ×
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Site Security Policy - Yahoo! Security Week
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Site Security Policy - Yahoo! Security Week

2,589

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,589
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
85
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Web Application Security and the Browser Brandon Sterne 5/15/2008
  • 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. 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
  • 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. 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. 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. 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
  • 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. 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
  • 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. 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
  • 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. 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
  • 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. 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
  • 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 *.example.com post,get; deny public.example.com *; expires 3600 16
  • 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. 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
  • 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. 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
  • 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. 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
  • 23. Thank You Questions? Brandon Sterne bsterne@mozilla.com

×