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
