John Melton's Weblog
Java, Security and Technology
Java, Security and Technology
What is it and why should I care?
Libraries and frameworks are a reality for every J2EE developer (pretty much any developer, actually) out there. We use them for MVC, DB, logging, web services, security, XML processing, as well as a host of other features. We rely on them in our production apps every single day. All this code written by someone else. Code that likely hasn’t been internally vetted. Code that likely hasn’t even been looked at. Yet, we still use these masses of code (generally MUCH larger than the custom code written for the app itself) to add functionality to our applications.
Knowing your frameworks means you don’t accept the code blindly. When you include a piece of software in your application, you’ve inherited and are now responsible for it. From a functionality perspective, you fix it when it breaks. From a security perspective, you are now responsible for dealing with it’s vulnerabilities. This is the crux of the problem: we manage a LOT of code now (code we didn’t write) and are responsible for making sure it is functional and secure: no easy task.
What should I do about it?
There are many things you should do when dealing with frameworks. I’ll cover the two I think are most important.
First, you should patch your frameworks when new vulnerabilities are found. This is a significant effort because it obviously requires much testing and coordination to upgrade frameworks within applications. However, there have been significant vulnerabilities found in libraries that are extremely popular, and that necessitates patching. Sometimes, patching can be done without upgrading the library actually. It could be moved off to a WAF or some such product. The point is you need to prevent the vulnerability that’s been exposed.
Second, you should really know and understand how your framework functions. While most frameworks patch vulnerabilities reasonably quickly (especially if the vuln public knowledge), they will often not patch their “design decisions”. These are often architectural patterns that benefit functionality, but not security. One popular pattern that comes to mind is auto-binding / mass assignment. The technique of populating the model using request data is not new, and is very powerful. It can make code much easier and cleaner to write. However, it’s often implemented with no security at all. The best you’ll usually get is an opt-in mechanism for securing it. However, most people are not going to opt-in, so it will be used insecurely in many cases. Patterns like this are frequently seen in modern frameworks, and developers really need to be aware of what’s going on internally in the framework to understand how the security and functionality of their application is going to be affected.
Frameworks are a necessary piece to most any development work going on today, but blindly trusting them is not. Be aware of what the frameworks you’re using do and how they do it. Keep an eye on them and patch them as necessary. This will help manage the risk of using them in your applications.
This post turned out to be very timely. Aspect Security just put out a nice paper (sorry, behind registration wall) on some analysis they did regarding the usage of java libraries through the maven central repo. They analyzed 113 million downloads and found that 26% of those downloads have known vulnerabilities! That’s a significant number. Their analysis doesn’t say whether or not those downloads were followed by requests for the patched versions, but I would bet not.
References
———–
https://www.aspectsecurity.com/blog/the-unfortunate-reality-of-insecure-libraries/
What is it and why should I care?
Log forging is an issue that can occur if you allow un-trusted data to be written to a log storage mechanism. The intent of the attacker using log forging is to cover his tracks in the logs or at least make understanding what he was doing more difficult. Unfortunately, like most log-related issues, it’s generally not a concern until something happens and you actually need the logs.
A simple example of log forging might look like this: (first the code)
String someVar = getRequestParameter("xyz");
log("Data is: " + someVar);
And now for what a normal request and the associated log entry might look like:
?xyz=my name is Bob [2012-03-15 02:04:31] [bob] Data is: my name is Bob
And finally what a forged request and the associated log entry might look like:
?xyz=my name is Bob\r\n[2012-03-15 02:04:39] [mary] Mary created new user\r\n[2012-03-15 02:04:46] [josh] Josh logged out\r\n[2012-03-15 02:04:55] [susan] Susan performed an important transaction [2012-03-15 02:04:31] [bob] Data is: my name is Bob [2012-03-15 02:04:39] [mary] Mary created new user [2012-03-15 02:04:46] [josh] Josh logged out [2012-03-15 02:04:55] [susan] Susan performed an important transaction
The idea here is that the attacker has surmised what a standard log entry might look like and then using simple newline characters created what appear to be new legitimate log entries.
Note: If you are using a database for logging, you likely won’t have as much of an issue since each entry is going to be in a single row. However, it could still affect you if your log viewer doesn’t distinguish between rows. However, you still need to be aware of SQL injection here, which is actually a much more serious issue.
What should I do about it?
Fortunately, log forging has a relatively simple fix.
The general approach is to validate input (you should already be doing this) and encode output (you also should be doing this). Validating input alone is not generally going to stop this attack, since there are valid cases to allow input with newlines. Encoding output in addition to validating the input, however, should solve your problem. There are various options for encoding depending on your needs. A simple fix might be to strip out any user-supplied newlines or replace them with some benign character or character sequence. Another alternative might be to HTML encode the data before storing it. This allows you to decode the data later if you need to get back to the original data, as well as have it set up nicely for a web-based log viewing experience if that’s desirable.
Log forging is a simple issue to understand and solve – it just takes some planning ahead to deal with properly. You’ll be glad you did though when you get that 3am call to look through the logs and figure out what’s happening!
I’ve actually already written a longer, more detailed article about log forging prevention here, but this shorter version was meant to show the essentials and fits in with the year of security for Java content.
References
———–
http://www.jtmelton.com/2010/09/21/preventing-log-forging-in-java/
What is it and why should I care?
X-XSS-Protection is a Microsoft IE technology used to help prevent reflected XSS attacks in IE.
Note 1: This is not a “panacea” for XSS. There is no excuse for not developing your site in a secure manner to prevent XSS. This however is a protection offered by the browser itself (as opposed to an application), meant to protect the masses from the vast amount of XSS litter on the internet.
Note 2: Firefox (by way of NoScript), Chrome (by way of WebKit) and Safari(also WebKit) have similar protections, but apparently don’t use the X-XSS-Protection header as a controlling mechanism.
The XSS protection provided essentially checks for request content that is matched in the response and would cause an XSS vulnerability to be exploited. The filter then performs some mangling of the content to prevent the attack from succeeding. According to the docs, IE has the protection turned on by default for most security zones, including the Internet zone, which is the primary concern for most users.
What should I do about it?
The first thing you should do is work towards resolving any and all XSS issues in your application. As a security minded developer, this is a must.
The recommendation for the use of this header is actually not so straightforward in my opinion. In general, the other HTTP headers I’ve described already in the series have had very little downside. However, the X-XSS-Protection header has had some problems in the past. As far as I’m aware, the IE folks have done a good job of dealing with the known vulns, but I still have concerns since some of the vulns have exposed security problems.
In general, I would recommend keeping the protection enabled, unless you are very sure you have XSS all cleaned up in your app. However, this comes with the caveat that you should at least put some thought into the use cases in your site first. Depending on your choice, here are the options you have available to use, and how you enable them in your application using the X-XSS-Protection HTTP header.
1. Enable the protection for all security zones in blocking mode (Blocking mode means the site won’t display at all if an XSS attempt is found, but rather a simple warning to the user that the attack has been blocked):
X-XSS-Protection: 1; mode=block
2. Enable the protection for all security zones:
X-XSS-Protection: 1
3. Leave the protection enabled for the default zones:
Do nothing.
4. Disable the protection entirely (I only recommend this in 2 cases: either you’re positive that you’ve completely resolved XSS in your app, or there’s an issue in the XSS filter that you’re aware of that causes an additional vulnerability) :
X-XSS-Protection: 0
The protection provided by the X-XSS-Protection header is not complete, but it does raise the bar against attackers and helps protect users. While there have certainly been some implementation issues, the fact that all the major browsers have some implementation of reflected XSS protection shows the importance of this issue. Be prudent in implementation, but certainly do everything you can to help your users be safe.
References
———–
http://blogs.msdn.com/b/ieinternals/archive/2011/01/31/controlling-the-internet-explorer-xss-filter-with-the-x-xss-protection-http-header.aspx
http://blogs.msdn.com/b/ie/archive/2008/07/02/ie8-security-part-iv-the-xss-filter.aspx
http://blogs.msdn.com/b/mikeormond/archive/2009/01/26/ie8-cross-site-scripting-xss-protection.aspx
http://msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx
http://michael-coates.blogspot.com/2009/07/ie-8-anti-xss-bit-overblown.html
http://jeremiahgrossman.blogspot.com/2010/01/to-disable-ie8s-xss-filter-or-not.html
http://www.jtmelton.com/2009/01/12/the-owasp-top-ten-and-esapi-part-2-cross-site-scripting-xss/
http://michael-coates.blogspot.com/2009/11/ie8-xss-filter-bug.html
http://xforce.iss.net/xforce/xfdb/47442
http://hackademix.net/2009/11/21/ies-xss-filter-creates-xss-vulnerabilities/
http://www.theregister.co.uk/2009/11/20/internet_explorer_security_flaw/
What is it and why should I care?
X-Content-Type-Options is an HTTP header that can help prevent browser content-type sniffing problems.
The content-type for a given resource should match the “type” (too obvious?) of the resource. For example, an HTML page would use “text/html”, a PNG image would use “image/png”, and a CSS document would use “text/css”. However, often times, the content-type is either not specified or is wrong. This has led to browsers having to implement “sniffing” algorithms to determine what the actual data is that is being served, and then apply the appropriate parsing and execution semantics for the sniffed type. This, however, has caused certain bugs. One well-known example allowed attackers to have files that were supposedly images be interpreted as javascript and executed.
What should I do about it?
There are actually 2 things to do here.
Step 1. When serving resources, make sure you send the content-type header to appropriately match the type of the resource being served. For example, if you’re serving an HTML page, you should send the HTTP header:
Content-Type: text/html;
Step 2. Add the X-Content-Type-Options header with a value of “nosniff” to inform the browser to trust what the site has sent is the appropriate content-type, and to not attempt “sniffing” the real content-type. Adding this additional header would look like this:
X-Content-Type-Options: nosniff
These 2 simple steps will provide additional protection against content-type sniffing issues.
An important note to mention here is that while this is a useful protection, not all browsers have implemented it. As of this writing (3/6/2012), only Chrome and IE support this protection (though NoScript does apparently add the protection to Firefox). Even though it won’t save all your users, it’s a useful mechanism to provide even more assurance for your users.
References
———–
http://www.browserscope.org/?category=security
http://blogs.msdn.com/b/ieinternals/archive/2011/02/11/ie9-release-candidate-minor-changes-list.aspx
http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx
http://msdn.microsoft.com/en-us/library/gg622941(v=vs.85).aspx
http://htaccess.wordpress.com/2009/09/22/x-content-type-options-nosniff-header/
http://www.adambarth.com/papers/2009/barth-caballero-song.pdf
http://www.w3.org/TR/html4/types.html#h-6.7
http://hackademix.net/2010/10/30/x-content-type-options-noscript-and-browserscope/
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
What is it and why do I care?
Session cookies (or the cookie containing the JSESSIONID to Java folks) are the cookies used to perform session management for web applications. These cookies hold the reference to the session identifier for a given user, and the same identifier is maintained server-side along with any session scoped data related to that session id. Since cookies are transmitted on every request, this is the most common mechanism used for session management in web applications.
The HttpOnly flag is an additional flag that is used to prevent an XSS (Cross-Site Scripting) exploit from gaining access to the session cookie. Since gaining access to the session cookie, and subsequently hijacking the victim’s session, is one of the most common results of an XSS attack, the HttpOnly flag is a useful prevention mechanism.
What should I do about it?
The resolution here is quite simple. You must add the HttpOnly flag to your session cookie (and preferably all cookies).
Here’s an example of how a session cookie might look without the HttpOnly flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H;
And now, with the HttpOnly flag:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly;
And, if you were following along from last week, with both the secure and HttpOnly flags:
Cookie: jsessionid=AS348AF929FK219CKA9FK3B79870H; HttpOnly; secure;
Not much to it. You can obviously manually do this, but if you’re working in a Servlet 3.0 or newer environment, there’s a simple configuration setting in the web.xml that takes care of this for you. You should add this snippet to your web.xml.
true
And, if you also use the secure flag, it looks like this:
true true
As you can see, resolving this issue is quite simple. It should be on everyone’s TODO list.
References
———–
http://blog.mozilla.com/webappsec/2011/03/31/enabling-browser-security-in-web-applications/
http://michael-coates.blogspot.com/2011/03/enabling-browser-security-in-web.html
https://www.owasp.org/index.php/HttpOnly