John Melton's Weblog
Java, Security and Technology
Java, Security and Technology
What is it and why should I care?
X-Frame-Options (moving towards just Frame-Options in a draft spec – dropping the X-) is a new technology that allows an application to specify whether or not specific pages of the site can be framed. This is meant to help deal with the clickjacking problem.
The technology is implemented as an HTTP response header specified per-page. Browsers supporting the (X-)Frame-Options header will respect the declaration of the page and either allow or disallow the page to be framed depending upon the specification.
What should I do about it?
Yet again, this is a very low-risk item that only adds additional assurance. There are some limitations that may prevent the header from offering protection in some instances, but it does NOT make you less safe. It is an additional layer of protection.
A page can specify 3 different options for how it wants to be framed.
Option 1: DENY
This option means this page can never be framed by any page, including a page with the same origin. A sample code snippet is below:
HttpServletResponse response ...;
response.addHeader("X-FRAME-OPTIONS", "DENY");
Option 2: SAMEORIGIN
This option means this page can be framed, but only by another page within the same origin. A sample code snippet is below:
HttpServletResponse response ...;
response.addHeader("X-FRAME-OPTIONS", "SAMEORIGIN");
Option 3: Allow-From
This option means the page can be framed, but only by the specified origin. A sample code snippet is below:
HttpServletResponse response ...;
response.addHeader("X-FRAME-OPTIONS", "Allow-From https://some.othersite.com");
As an additional help, the good folks at owasp have put together a simple example J2EE filter for X-Frame-Options.
(X-)Frame-Options is a good additional layer of protection to add to your site to prevent clickjacking. While it won’t stop everything, it costs very little, and can help protect your users.
References
———–
https://developer.mozilla.org/en/The_X-FRAME-OPTIONS_response_header
https://www.owasp.org/index.php/Clickjacking#Defending_with_response_headers
http://blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx
http://blog.mozilla.com/security/2010/09/08/x-frame-options/
http://lcamtuf.blogspot.com/2011/12/x-frame-options-or-solving-wrong.html
http://www.jtmelton.com/2012/02/03/year-of-security-for-java-week-5-clickjacking-prevention/
http://tools.ietf.org/html/draft-gondrom-frame-options
What is it and why should I care?
HTTP Strict Transport Security (HSTS) is a new(ish) technology that allows an application to force browsers to only use SSL/TLS (HTTPS, not HTTP) when visiting their application. This occurs when the application sets an HSTS specific HTTP response header. Browsers that support HSTS recognize the response header and only communicate with that application over HTTPS for the specified time. Here are the basic steps of the flow:
Step 1: A user visits application, either over HTTP or HTTPS. For most users this will be HTTP as they often forget (or don’t know) to type in https://
Step 2: The application renders the response, including the HSTS response header that specifies the site should be loaded over HTTPS only for the next 90 days.
Step 3: Supporting browser will not issue a non-SSL request to that application for the next 90 days.
What should I do about it?
Set the header! This is another no-brainer. There are no backwards compatibility issues and it only enhances your security posture. By adding the header, you give your users greater security with very little effort on your part. Here’s a quick example of what setting the header might look like if you happen to code in Java.
HttpServletResponse ...;
response.setHeader("Strict-Transport-Security", "max-age=7776000; includeSubdomains");
The snippet above sets the amount of time that the browser should only use HTTPS when accessing the application (or any subdomains) to the next 90 days.
max-age
The max-age attribute is required and sets the number of seconds that only HTTPS should be used. This can be set to whatever you want. Setting this to 0 tells the browser to delete the existing policy and not require HTTPS.
includeSubdomains
The includeSubdomains attribute is optional. It does not take a value; its’ presence signifies that any sub-domains should abide by the same HSTS policy.
Expiration Reset
The time length (90 days in our example above) should be reset (overwritten) by the supporting browser every time the HSTS response header is received. What this means is that if you set the length to 90 days, and a person never goes more than 90 days without visiting your site, they’ll always be visiting over HTTPS since the 90 days starts over every time they visit. Just keep in mind that if you change the setting, all browsers that access your site (post-change) will get the update. If you set it to 90 days today and 10 tomorrow, the browser throws away the 90 days and replaces it with 10.
Click-Through Insecurity
The HSTS spec also recommends (though the current spec doesn’t seem to require) that the browser not send any data to the server if the channel is insecure for any reason (certificate issues, domain issues, etc.). This appears to be the route being taken by current browser implementers, which is the most secure option. This means that those warning pop-ups users often see over HTTPS connections (mixed content, expired cert) don’t appear any more and instead the user is simply shown an error.
Pre-loaded HSTS Lists
If you want to have even more assurance that your site is only ever visited over HTTPS, you can even request that your site be pre-loaded into a list of HSTS sites. This means the browser will require you to got that site over HTTPS on your very first visit! Paypal is one such well-known site that does this.
HSTS is a simple and effective control to let an application further protect its’ users by forcing them over HTTPS. If your site is (or at least should be) HTTPS only, then implementing HSTS can provide you and your users with enhanced assurance.
References
———–
http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/
http://dev.chromium.org/sts
http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
https://tools.ietf.org/html/draft-ietf-websec-strict-transport-sec
http://michael-coates.blogspot.com/2011/07/enhancing-secure-communications-with.html
http://www.troyhunt.com/2011/11/owasp-top-10-for-net-developers-part-9.html
What is it and why should I care?
Content Security Policy (CSP) is a new(ish) technology put together by Mozilla that web apps can use as an additional layer of protection against Cross Site Scripting (XSS), which is the primary goal of the technology. A secondary goal is to protect against clickjacking.
XSS is quite a complex issue, as is evidenced by the recommendations in the OWASP prevention cheatsheets for XSS in general and DOM based XSS. CSP does several things to help app developers deal with XSS.
Whitelist Content Locations
One reason XSS is quite harmful is that the browsers implicitly trust the content received from the server, even if that content has been manipulated and is loading from an unintended location. This is where CSP comes in: CSP allows app developers to declare a whitelist of trusted locations for content. Browsers that understand CSP will then respect that list and only load content from there, and will ignore content that references locations outside the list.
No Inline Scripts
Adding scripts inline to content is the way XSS is done, made possible because browsers have no way of telling whether the site actually sent that content, or if the attacker added the script to the site content. CSP prevents this entirely by forcing the separation of content and code (Great design!). This means that you have to move all your scripts to external files, which will require work for most apps, though it can be done (Twitter is one example of a high-profile site using CSP). The upside is in order for an attack to be successful with CSP, an attacker has to be able to:
Step 1) Inject a script tag at the head of your page.
Step 2) Make that script tag load from a trusted site within your whitelist.
Step 3) Control the referenced script at that trusted site.
This makes an XSS attack significantly more difficult.
Note: one common question here is what about event handling. CSP does still allow event handling through the onXXX handlers or the addEventListener mechanism.
No Code From Strings (eval dies)
Another welcome addition is the blacklisting of functions that create code from strings. This means that usage of the evil eval is out (along with a few others). Creating code from strings is a popular attack technique and is rather difficult to trace, so the removal of all these functions is actually quite helpful.
Another common question stemming from this is how to deal with JSON parsing. The right way to do this from a security perspective has always been to actually parse the JSON instead of eval it anyhow, and this functionality is still available, so nothing changes there.
Policy Violation Reporting
A rather cool feature of CSP is that you can configure your site to have a violation reporting handler, and then have that data available whether you run in report-only or in enforcing mode. In report only mode, you can get reports of locations in your site that will be prevented from execution when you enable CSP (a nice way to test). In enforcing mode, you can still get this data, but in production, you can also use this as a simple XSS detection mechanism (bad guy tried XSS and it didn’t run).
What should I do about it?
Well, you should use it! Actually, CSP doesn’t really seem to have a downside. It’s there to make your site safer, and even if a client’s browser doesn’t support it, it’s entirely backwards compatible, so your site won’t break for the client.
In general, I think the basic approach should be:
Step 1) Solve XSS through your standard security development practices (you should already be doing this)
Step 2) Learn about CSP – read the specs thoroughly
Step 3) Make the changes to your site and test and re-test (normal dev process)
Step 4) Run in report-only mode and monitor any violations to find areas you still need to fix. (could be avoided if you have a full functional test suite you can execute against your app in testing – good for you if you do!)
Step 5) After you’re confident your site is working properly, turn it on in enforcing mode.
As for how you actually implement it, you have 2 basic options: an HTTP header and a META tag. The header option is preferred, and an example is listed below.
Content-Security-Policy: default-src 'self';
img-src *;
object-src media1.example.com media2.example.com *.cdn.example.com;
script-src trustedscripts.example.com;
report-uri http://example.com/post-csp-report
The example above says the following:
Line 1: By default, only allow content from ‘self’ or the site represented by the current url.
Line 2: Allow images from anywhere.
Line 3: Allow objects from only the listed urls.
Line 4: Allow scripts from only the listed url.
Line 5: Use the listed url to report any violations of the specified policy.
CSP is a very interesting and useful new technology to help battle XSS. It’s definitely a useful tool to add to your arsenal.
Update (2/15/2012) Here’s an interesting post on using ModSecurity to add CSP to your site – a nice look for the administrators. (h/t @ryancbarnett)
References
———–
https://developer.mozilla.org/en/Introducing_Content_Security_Policy
https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html
https://wiki.mozilla.org/Security/CSP/Design_Considerations
https://wiki.mozilla.org/Security/CSP/Specification
https://dvcs.w3.org/hg/content-security-policy/raw-file/bcf1c45f312f/csp-unofficial-draft-20110303.html
http://www.w3.org/TR/CSP/
http://blog.mozilla.com/security/2009/06/19/shutting-down-xss-with-content-security-policy/
https://mikewest.org/2011/10/content-security-policy-a-primer
http://codesecure.blogspot.com/2012/01/content-security-policy-csp.html
https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet
http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html
What is it and why should I care?
Cross Site Request Forgery (CSRF) is an attack wherein a victim is forced to execute unknown and/or undesired requests to a website at which he/she is currently authenticated. It exploits the fact that the “credentials” needed to perform a function on a website are generally loaded into a client-side cookie, which is transmitted automatically with every request. By exploiting this fact, an attacker can cause a victim to execute almost any request that isn’t protected against CSRF.
Here is a simple image that shows a basic CSRF attack. The steps are:
Step 1. The victim is lured to visit an evil site (evil.com)
Step 2. The victim’s browser loads the evil site, which contains a hidden image whose src points at an important transaction on good.com)
Step 3. The victim’s browser executes the transaction at good.com, passing along the session cookie (general authn/z mechanism).
Step 4. The transaction occurs, and the victim is not aware until later, if at all.
What should I do about it?
Now that we know what CSRF is and why it is dangerous, let’s consider some possible solutions.
Token
The classic solution to CSRF has been a per-session token (known as the synchronizer token design pattern). The basic flow is:
Step 1. User logs in and a randomized string (token) is placed in the user session
Step 2. On every form for a non-idempotent request (meaning essentially any request that changes server-side state – should be your HTTP POSTs), place the token in the form when it’s submitted.
Step 3. On the request handler for the non-idempotent request, validate that the submitted token matches the token stored in the session. If either is missing or they don’t match, do not process the transaction.
This solution has served pretty well for most situations over the years, but can be time-consuming to implement and often creates opportunities for forgetting validation on some requests.
The ESAPI project does have built in CSRF protection, but it is tied to the authentication scheme. Here is a writeup I previously did for ESAPI’s CSRF protection.
CSRFGuard
A very good option with solid protection is the OWASP CSRFGuard project. This library makes it relatively simple to include CSRF protection into your application by simply mapping a filter and updating a configuration file. This is certainly a resource worth checking out.
Stateless CSRF Protection
One more thing I’d like to point out is some interesting work John Wilander (@johnwilander) is doing in the area of stateless CSRF protection. In the case where you can’t or don’t want to maintain the user token in server-side session state, John proposes a seemingly novel solution. The proposal is to allow the client side to create a cookie with the CSRF token (which gets submitted on every request) and to include the token as a request parameter. Since an attacker can’t read both the cookie and request parameter, all the server side should have to do is validate that the token in the cookie and the request parameter match. This solution, to my knowledge, has not been widely reviewed or tested, but it is a great example of an elegant solution to a difficult problem. Only time will tell if this is the go-forward solution for stateless CSRF protection.
CSRF is a popular and dangerous attack, but with the protections described above, it is certainly manageable.
One last note here is that the token approach (classic or stateless) does break down when the site it is deployed on contains XSS (Cross Site Scripting) vulnerabilities. If an attacker can XSS your site, they can read the content and extract out the token you’re using, effectively nullifying the protection. The lesson is simple: fix those XSS bugs too!
References
———–
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
http://www.cgisecurity.com/csrf-faq.html
http://www.jtmelton.com/2010/05/16/the-owasp-top-ten-and-esapi-part-6-cross-site-request-forgery-csrf/
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
https://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project
What is it and why do I care?
Clickjacking is a type of “web framing” or “UI redressing” attack. What that simply means in practice is that:
1. A user (victim) is shown an innocuous, but enticing web page (think watch online video)
2. Another web page (that generally does something important – think add friends on social network) is layered on top of the first page and set to be transparent
3. When the user thinks they are clicking on the web page they see (video), they are actually clicking on the higher layered (framed) page that is transparent
This attack is clever, and there are some interesting specifics in the actual execution of an attack (For more info, see the references), but here, I’m concerned with preventing the attack.
What should I do about it?
There is still no perfect answer on clickjacking, but things are getting better, especially as users upgrade to more modern browsers. The recommendation is two-fold:
1. Use the X-Frame-Options HTTP header
2. Include framebusting code
There is a future article in the series coming, I promise, on the X-Frame-Options HTTP header. All I’ll say for now is that this header is the more robust solution, but that it requires a relatively modern browser. Fortunately, folks are slowly moving towards more modern browsers, so the situation is improving.
As for the framebusting recommendation, it is breakable, but should still be done. It certainly raises the bar. There are many options for framebusting code, but the folks at Stanford put together a paper http://seclab.stanford.edu/websec/framebusting/ on framebusting where they evaluated the current code in the wild and showed ways to break it. They came up with their own proposed solution in the paper. I’ll omit the code here, but it’s at the top of page 11 of the pdf. The basic idea is to both:
a) use the stylesheet to disable display for the entire body of the page, and
b) use Javascript to either enable the display if not framed, or to bust out of the frame if framed.
This solution will probably (if it’s not already) be broken, but it appears to be the best we have today.
Clickjacking is unfortunately a less-than-clearcut issue to solve, but by combining a couple different approaches, you can resolve the issue with a fair amount of robustness.
Update 2/3/2012: The Stanford approach does not adequately support IE in all instances – here’s a post from August Detlefsen explaining the solution. (h/t Chris Schmidt)
References
———–
https://www.owasp.org/index.php/Clickjacking
http://seclab.stanford.edu/websec/framebusting/
http://michael-coates.blogspot.com/2010/08/x-frame-option-support-in-firefox.html
https://www.codemagi.com/blog/post/194