article The Underappreciated X-Frame-Options Header in HP Security Research Bloghttp://h30499.www3.hp.com/t5/HP-Security-Research-Blog/The-Underappreciated-X-Frame-Options-Header/ba-p/5987195
<P>While in San Francisco last week for the <A target="_blank" href="http://www.rsaconference.com/events/2013/usa/">2013 RSA Conference</A>, some of us made the trek to B-Sides to catch a few talks since we arrived a bit early. To our delight, Mike Shema was speaking about &nbsp;<A target="_blank" href="http://deadliestwebattacks.files.wordpress.com/2013/02/javascript-security-html5.pdf">JavaScript Security &amp; HTML5</A> and we were eager to see his presentation. Mike also gave another talk at RSA about&nbsp;<A target="_blank" href="https://ae.rsaconference.com/US13/connect/sessionDetail.ww?SESSION_ID=1788&amp;tclass=popup">using HTML5 WebSockets securely</A>, which was equally informative and engaging (however, I preferred the ambiance of the DNA Lounge for the first presentation).</P><P>&nbsp;</P><P>Back to B-Sides. It didn’t take long for Mike to mention the HTML5 Iframe tag and the sandbox attribute. Quite a timely mention, given that we’d spent the better part of the last few months studying Cross-Frame Scripting (XFS) and Clickjacking attacks for our contribution to the <A target="_blank" href="http://www.hpenterprisesecurity.com/register/guarding-against-a-data-breach-hpblog">HP 2012 Cyber Risk Report</A>. Immediately following this discussion was the mention of the X-Frame-Options header and how it effectively discourages Clickjacking attacks. Where Mike stopped short, however, is answering the question we posed at the beginning of our research project, “Just how many developers are using the X-Frame-Options header?”</P><P>&nbsp;</P><P>Disappointingly, even in the face of stout remediation measures such as the X-Frame-Options header, XFS continues to exist and has enabled other, more popular vulnerabilities such as Clickjacking to take root and flourish. One of the most surprising findings we uncovered throughout our research&nbsp;was the sheer number of websites that didn’t even attempt to set the X-Frame-Options header, which could just be because they don’t need it. Or do they?</P><P>&nbsp;</P><P>As a test, we figured we’d create a simple script to passively examine top level requests for information worth protecting – so we decided to look for HTTP responses that contained password fields as an initial gauge to pages that actually had a reason to protect something sensitive. The <A target="_blank" href="http://www.hpenterprisesecurity.com/register/guarding-against-a-data-breach-hpblog">HP 2012 Cyber Risk Report</A>&nbsp;contains the details of our findings, but a quick spoiler alert will tell you that&nbsp;<SPAN>less than a tenth of a percent of our sample included proper use of the X-Frame-Options header.</SPAN></P><P><SPAN>&nbsp;</SPAN></P><P>It’s difficult to explain the grounds for why there’s such a wicked absence of websites incorporating the X-Frame-Options header. &nbsp;Could it be that developers don’t understand the threat of Clickjacking or the X-Frame-Options header just hasn’t been properly evangelized enough for developers to take it seriously? Either way, the X-Frame-Options header is indeed an effective deterrent to Clickjacking, but only if it’s used!</P><P>&nbsp;</P><P>One common misconception is that client-side frame-busting JavaScript takes care of XFS. While a few “frame-buster-buster” iterations went around for a few years, the HTML5 IFrame tag coupled with a sandbox attribute that neglects to specify the “allow-top-navigation” permission in its value effectively disables this protection…so it’s even more imperative to use the X-Frame-Options header now more than ever.</P><P>&nbsp;</P><P>There are several helpful resources on how and why you should incorporate the X-Frame-Options response header in your applications, here are a few:</P><P>&nbsp;</P><OL><LI>OWASP: <A target="_blank" href="https://www.owasp.org/index.php/Clickjacking">https://www.owasp.org/index.php/Clickjacking</A></LI><LI><SPAN style="line-height: 15px;">For IIS: </SPAN><A target="_blank" href="http://support.microsoft.com/kb/2694329">http://support.microsoft.com/kb/2694329</A></LI><LI>For Apache, nginx: <A target="_blank" href="https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options">https://developer.mozilla.org/en-US/docs/HTTP/X-Frame-Options</A></LI><LI>Busting Frame Busting: A Study of Clickjacking Vulnerabilities on Popular Sites <A target="_blank" href="http://cdn.ly.tl/publications/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites.pdf">http://cdn.ly.tl/publications/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites.pdf</A></LI><LI>X-Frame-Options IETF Draft: <A target="_blank" href="http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01">http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01</A></LI></OL>Fri, 08 Mar 2013 03:36:53 GMTjoe_sechman2013-03-08T03:36:53ZThe Underappreciated X-Frame-Options Headerhttp://h30499.www3.hp.com/t5/HP-Security-Research-Blog/The-Underappreciated-X-Frame-Options-Header/ba-p/5987195
<P><SPAN>Disappointingly, even in the face of stout remediation measures such as the X-Frame-Options header, Cross-Frame Scripting (XFS) continues to exist and has enabled other, more popular vulnerabilities such as Clickjacking to take root and flourish. One of the most surprising findings we uncovered throughout our research in the <A target="_blank" href="http://www.hp.com/go/riskreport">HP 2012 Cyber Risk Report</A>&nbsp;was the sheer number of websites that didn’t even attempt to set the X-Frame-Options header, which could just be because they don’t need it. Or do they?</SPAN></P>Fri, 08 Mar 2013 03:36:53 GMThttp://h30499.www3.hp.com/t5/HP-Security-Research-Blog/The-Underappreciated-X-Frame-Options-Header/ba-p/5987195joe_sechman2013-03-08T03:36:53Z