Web Application Security and the BrowserBrandon Sterne5/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

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

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

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)

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.

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

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

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

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

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

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

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

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”

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/

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

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

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

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

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?

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

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/

Questions?

Thank You

Brandon Sternebsterne@mozilla.com