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 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