On January 31st, Deusen disclosed what was described as a Same Origin Policy Bypass flaw called “Universal XSS (U-XSS)” in IE 9 through 11 on Full Disclosure. This zero-day is another reminder of why a “Defense in Depth” strategy is so important, even within web applications. That’s because this particular flaw has to do with the way Internet Explorer handles the Same Origin Policy within IFrames. Even though this is called a “Universal XSS” flaw, the simple step of consistently returning a properly configured X-FRAME-OPTIONS header effectively inoculates any website by preventing its content from working in an IFrame.
An IFrame (or Inline Frame) is an element of HTML that allows content from one website to be displayed “inline” within the content of another website. The browser’s Same Origin Policy (SOP) is responsible for essentially sandboxing the framed content from any scripts running on the parent page. This should make it impossible for a script on the main page to interact with content inside the framed page unless both pages come from the same “origin”. Origin is defined as having the same scheme, host, and port.
Having “frameable pages” on a web application is one of those little security details that in many cases gets completely forgotten. Sometimes the excuse is that not all browsers have the same fix (i.e. X-FRAME-OPTIONS is not supported on all versions of all browsers), so it may require additional effort to protect a website across all browsers (e.g. frame-busting code). It’s also not one of the first things (or even one of the second or third things) a web penetration tester is going to look at because it isn’t nearly as compelling as a SQL Injection, XSS, authentication, or authorization flaw. Depending on the tester it might even be completely overlooked in the report.
I spent some time playing around with Deusen’s proof of concept to get a better understanding of what is really going on. It’s somewhat complicated as it requires a specific sequence of requests and thread blocking, but it amounts to a sort of “Time of Check – Time of Use” (TOCTOU) behavior (bug) in the IFrame code in Internet Explorer. Under the right conditions it is possible to initialize the IFrame with content from one origin (i.e. one the attacker fully controls) and then switch that content to any website that can be framed without an additional origin check.
Deusen’s U-XSS disclosure is a great example of why these “little things” should not be overlooked. And it isn’t the first example of the emergence of a flaw specific to IFrames. This reminds me of Paul Stone’s whitepaper on Pixel-Perfect Timing Attacks in HTML5, in which he describes another flaw for which simply configuring the X-FRAME-OPTIONS response header will provide a good defensive measure.
We live in a world of wonderful and rapidly changing technology, but it is also a world of vulnerabilities and zero-days that criminals are leveraging for a variety of unsavory purposes. We cannot anticipate where we will see the next zero-day, but we can prepare for it. One of the best ways to prepare is to employ a “Defense in Depth” strategy, and this means we have to fix all the “little things”. Make use of X-FRAME-OPTIONS – it’s usually very easy to implement. Make sure all sensitive content is encrypted over SSL. Properly protect session cookies with the Secure and HttpOnly flags. Enforce strong passwords. Sometimes, like with Deusen’s U-XSS, it’s these little things that make the difference between being exposed or being protected.
Note: Deusen’s U-XSS on Internet Explorer was patched in March, 2015.
Jason Gillam is a Senior Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at email@example.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.