We would like to share a white paper of our ongoing clickjacking research and some demos by CyLab researchers David Huang and Collin Jackson at Carnegie Mellon Silicon Valley. In our white paper, we describe a practical de-anonymization attack on social network users, based on Likejacking. We also introduce a new type of click timing attack called double-clickjacking that can bypass current defenses and steal the user’s data from popular OAuth service providers. We would like to make clear that IFRAME-based defenses are ineffective. Moreover, clickjacking is not all about IFRAMEs.
White paper: Clickjacking Attacks Unresolved
Browser UI spoofing attacks have been threatening users’ security ever since the early stage of the World Wide Web. Edward Felten described several UI spoofing attacks in a technical report written in 1996 (and revised in 1997). These attacks attempt to mimic portions of the browser UI in order to deceive the users into performing unsecure actions. The report mentioned three major browser components used for spoofing: the location line, the status line, and the browser’s menu bar.
Location line: These are commonly seen in phishing attacks, where the attacker uses a misleading URL to deceive the user. For example, www.bankofthevvest.com.
Status line: Since any website is allowed to set its own status line at the bottom of the window, an attacker could use the status line to trick the users into believing that they are browsing a benign site.
Another UI element that was not mentioned in Felten’s report was the location bar itself. Websites were allowed to create a pop-up window with its location bar disabled. An attacker may leverage this to craft an arbitrary URL to display at the top of the pop-up window.
The picture-in-picture attack works as follows (see diagram below):
- User visits attacker’s site.
- Attacker includes a picture that looks exactly like a pop-up window of paypal.com on her site.
- User looks at the address bar, thinking it is the legitimate paypal.com, and proceeds with entering his credentials.
Four years have passed since Collin’s picture-in-picture attack paper, and the attack has been largely ignored by the community. Various authentication mechanisms have been designed to continuously use pop-up windows to bootstrap security, putting many users at risk. To demonstrate the threat of picture-in-picture attack, I created a demo here, using Facebook’s login pop-up as an example (Currently, the attack only spoofs the UI of a Chrome pop-up using OS X).
To mimic a real pop-up window, I added the following features to the picture:
- A text box is used to create an illusion of a location bar.
- A text box and a password field are used to create the login box.
- An event handler is attached to the top of the window to simulate the dragging effect of the window.
- A separate image is used to create the loading screen.
Although it does not fully simulate a pop-up window, a motivated attacker could make the following additions to further enhance the quality of the attack:
- Add scripts for resizing the window, and simulating the shadow effects of OS X(I used a cheap get-around for this in my demo).
- Detect the browser type/version using standard user agent detection techniques and display different pop-up images accordingly.
- Simulate as many clickable elements of a pop-up window as possible(with exception to maximize/minimize).
We haven't seen these attacks much yet in the wild. “Why not?” is an interesting question. Maybe they're too hard to pull off in practice, and maybe attackers have an easier time with simple phishing attacks. Nevertheless, picture-in-picture attack is a real threat and has to be stopped.
For starters, it is never a good idea to authenticate the user through an attacker-controlled screen area. Web sites should use a new tab to authenticate their users, instead of using a pop-up window. However, this defense (by itself) is not enough to mitigate UI spoofing attacks for the same reason that a broken(or missing) lock icon cannot stop people from entering their credit card numbers. At the end of the day, we have to educate users to differentiate a UI spoofing attack, which in itself could be a challenging task.
We're happy to announce that a solution is now available for a long-standing security flaw in browsing handling of style sheets. Internet Explorer 9 now joins Opera, Google Chrome, Safari, and Firefox in adopting the defense for this vulnerability.
How the attack works
Browsers must constantly guess what web authors intended. Guess correctly and the user is delighted. Guess wrong and the web site will break... or worse. Last year, the WebBlaze group at UC Berkeley helped browser vendors rein in their guessing of content types to prevent third-party PDFs and images from being incorrectly treated as privileged HTML. However, a related vulnerability remained.
The vulnerability has to do with loading of cross-origin resources. Normally, one web site cannot directly read HTML documents belonging to another web site. This important browser functionality keeps attacker.com from reading your Gmail, for example. However, web sites can include resources like scripts, stylesheets (CSS), images, and movies from other sites. By including another site's documents as a stylesheet, it is possible to read secrets from of other sites and even hijack the user's session.
How it was fixed
Our proposed client-side defense is to enforce content type checking for style sheets loaded cross-origin. This behavior gives web servers a way to block their HTML documents from being parsed as stylesheets.
However, coming up with defenses is easy. The real problem is how to deploy them. Any time you make a change to browser behavior there's a chance you'll break someone's favorite web site, so we did our best to make sure that this defense would really be acceptable. We looked at the top 100,000 web sites and found 74 CSS references that would be broken by this behavior. We then developed a "minimal" defense that has perfect compatibility with these sites and similar security properties.
Our proposed behavior was first deployed in a stable release of Opera 10.10 last November. Google Chrome, Safari, and Firefox followed suit with stable releases in January, March, and July. Internet Explorer has not yet deployed the change in a stable release, but it can been seen in Internet Explorer 9 Preview 4. We hope that Microsoft will include it as a security update for stable versions of IE as well. Update: Microsoft has patched IE6, IE7, and IE8.
This research is a collaboration between David Huang, Zack Weinberg, and Collin Jackson from the CMU Silicon Valley web security group and Chris Evans of Google. Eric Lawrence was our contact at Microsoft. We've written up a paper with all the gory details of the attack and our compatibility assessment of the defense. The paper will appear at the ACM Computer and Communications Security conference in October.
Are you protected?
We've added a BrowserScope security test that checks for the presence of the new, secure CSS handling behavior. You can use this test to see if your browser is protected. The test loads a text/html document as a stylesheet and sees if the browser parses it. You can check your browser by following this link:
We've also added two other security tests: cross-origin resource sharing and preventing attacks on a user's history through CSS :visited selectors. I'll write up some more thoughts about the latter defense in a future post.
When we originally wrote “Regular Expressions Considered Harmful in Client-Side XSS Filters,” we did not fully understand the design of the NoScript reflected cross-site scripting (XSS) filter. Several factors contributed to this confusion, including a bug that prevented NoScript from working properly in our test environment and the fact that NoScript provides different levels of XSS protection on same-origin requests and cross-origin requests. In this post, we'll present our current understanding of the NoScript's XSS filter design and how it relates to the concepts introduced in that paper.
The NoScript XSS filter mediates on the HTTP request instead of on the HTTP response. Instead of altering how the response is processed by the browser, NoScript mangles the HTTP request to remove dangerous content. For example, if the request contains a script tag, NoScript will replace the angle brackets with whitespace characters, essentially "mangling" the original request. If the server has a reflected XSS vulnerability, the server will echo the mangled script tag, which will not execute in the browser.
Instead of relying only on regular expressions to detect dangerous snippets of content, NoScript uses a combination of regular expressions and the browser’s native HTML parser. When we did our testing on Mac OS X, Firefox had a bug on Mac OS X that caused NoScript to use the wrong HTML parser. In our experiments, we observed that the regular expressions alone were insufficient to provide XSS protection. However, once NoScript worked around the bug and used the correct HTML parser in NoScript 220.127.116.11, it was correctly able to identify the complex parsing examples in our test suite.
One disadvantage of the design of NoScript’s XSS filter is that altering the request has a higher false positive rate because the filter cannot consider the content of the response in deciding whether the user is under attack. To compensate for this increased false positive rate, NoScript has a “same-origin exception” similar to that used by Internet Explorer 8. However, the same-origin exception is not without its own risks, as discussed in the paper. Sites that allow users to post hyperlinks should be aware that these links may be used to work around the browser's reflected XSS protection. NoScript does seem to provide limited protection against very obvious attacks in same-origin links, but the
<img/src> example we gave in the paper is an example of a link that is allowed in same-origin requests.
To prevent the hyperlink injection attack we described in the paper, NoScript blocks a broader range of injections than other filters on cross-origin requests to a site. Aggressive filtering can cause false positives on sites with multiple domains, where the same-origin exception doesn't apply. For example, searching for "alert()" on eBay is mangled by NoScript and a warning is shown, even though eBay has no XSS vulnerabilities in its search box. NoScript has a user interface that power users can use to alleviate these false positives with domain whitelists.
There are other approaches for mitigating the risks of the same-origin exception that may have fewer false positives, such as decoding multiple layers of attack encoding or subjecting requests generated from pages that might contain an injection to further scrutiny. Analyzing the security of these approaches is a promising direction for future work.
“Harmful” considered harmful?
In our paper, we made an effort to describe XSSAuditor’s key design decisions, which allowed us to create a fast and effective XSS filter with few false positives and no need for a same-origin exception. We believe that XSSAuditor’s unique mediation point has a number of advantages, and we have made an effort to explain the rationale for this mediation point in the paper. However, we want to emphasize that there is nothing fundamentally impossible about overcoming the limitations of other mediation points used by regular-expression-based XSS filters. We hope that our discussion of the trade-offs will provide some background and inspiration for browser vendors and researchers who are pursuing further improvements in this space.
In our last post, we introduced a new web-based suite of security tests for Browserscope, a community-driven project and resource for profiling web browsers and tracking their functionality. In addition to running the security tests, you can use Browserscope to find out if your browser is ahead of the pack on the Acid3 web standards test, network performance, and more.
Our goal for the Browserscope security suite is to encourage openness and innovation in browser security. Here are some of the essential elements of a good Browserscope security test:
- The test should check for a behavior that makes the web a safer platform for developing web applications.
- The test needs to be able to run without user interaction.
- The test should be applicable and realistically attainable for all major browser vendors.
- The behavior should not yet have universal adoption among popular browsers at the time it's added to Browserscope.
These criteria might seem obvious, but they rule out a lot of test topics. For example, we can't test password managers or private browsing mode. We'll leave those features for others to test and focus on what web application authors are clamoring for.
With those requirements in mind, we're excited to announce some new additions to the Browserscope security test suite. These tests are contributed by David Lin-Shung Huang and Mustafa Acer of Carnegie Mellon Silicon Valley. We hope you'll agree that these new tests clearly meet the bar we've set for a good test.
HTTP Origin Header. Validating the HTTP Referer header can be an effective defense against cross-site request forgery (CSRF) attacks, yet privacy concerns have lead to widespread Referer blocking at the network layer. The HTTP Origin header proposal provides a more robust CSRF defense while respecting the user's privacy. Particularly, the Origin header does not contain the path or query portions of the URL and does not leak via following hyperlinks. We check the browser's POST requests to see if the Origin header is supported.
Strict Transport Security (STS), originally proposed as ForceHTTPS, allows high-security web sites to declare themselves accessible only via secure connections. This new feature improves the security of HTTPS by enabling browsers to redirect insecure connections to secure connections and treat all TLS errors as fatal. We test STS by intentionally downgrading a secure connection to an insecure connection and checking if the browser attempts to connect securely.
Sandbox Attribute. It is quite common for web sites to embed third party content (e.g. ads or widgets) that they may have little or no control over. The HTML5 sandbox attribute provides additional protection for iframes by isolating and restricting the privileges of untrusted contents. We test whether the browsers are blocking scripts in a sandboxed iframe. As browsers start to support the sandbox attribute, we may include tests for the text/html-sandboxed MIME type later on, which is designed to prevent older browsers from rendering untrusted content.
X-Frame-Options is a Microsoft proposal for an HTTP response header which controls how a web page can be framed. This header is effective in preventing clickjacking attacks. In this type of attack, misleading images or text are overlaid on a frame to convince the user to click on the frame, leading to unwanted consequences such as unintended transactions. X-Frame-Options blocks rendering of a web page in a frame if X-Frame-Options value is set in the page's HTTP response header. We test this feature by loading a page with X-Frame-Options header set to "deny" in a frame, and check if the page is blocked or not.
X-Content-Type-Options is another Microsoft proposal for controlling MIME sniffing behavior of browsers. When the content type of a web document is not received in its HTTP response headers, browsers try to determine the type of the document by looking at the first 512 bytes of its content. Attackers may use this behavior to run scripts by embedding
<script> tags into generally harmless file types such as postscript documents, which the browser may treat as HTML. Setting X-Content-Type-Options header of a document to "nosniff" forces the browser to display plain text view of the document, without trying to infer the document's content type. We test this feature by loading a page with X-Content-Type-Options header set to "nosniff" in a frame, and checking if the browser displays the page as plain text or as HTML.
Removed tests. We've also decided to remove the Browserscope tests for cross-origin
contentDocument, which checked for a security policy behavior specified in HTML5. We believe that browser vendors should implement this behavior to reduce the risk of cross-origin privilege leaks, and to make the web a more consistent platform to develop on. However, the browsers that deviate from the specification do so in a way that has no currently known vulnerabilities. We have decided to remove these tests and focus the Browserscope security suite on features that have a clear security use case for web application developers.
What's next? We've been eyeing CSP and phishing filters as possible candidates for future Browserscope tests. We've also received some feedback from the author of NoScript on how to improve our XSS filter test. Are we on the right track? Join the Browserscope discussion group and let us know.
I'm often asked whether browsers are moving in the right direction when it comes to security. We are constantly barraged by news about the latest embarrassing browser exploit or social network worm, so it's easy to get the impression that vendors are just twiddling their thumbs as civilizations burn, or that new features cause more problems than they solve.
I think there actually has been a great deal of progress, and that far from being a catastrophic failure, the web today is a safer place to do your banking, shopping, and communicating than ever before. I think that negative news stories are about the worst success metric imaginable, and that as an industry we place far too little emphasis on concrete improvements that make the web a better platform for secure web applications. If you believe that you make what you measure, it's a wonder we've made any progress at all.
With the help of my colleagues, I'm hoping we can change that. Today, we're announcing a new web-based suite of security tests that are designed to provide a constructive metric for browser security. These tests are part of Browserscope, a community-driven project for tracking browser functionality. Browserscope was created to foster innovation by vendors by making it easy to compare functionality across browsers. It's also a great resource for web developers who want to know which browsers can provide the functionality they need.
The Browserscope security tests are not there to tell you whether your browser is vulnerable to the latest buffer overflow exploit that's in the news. Rather, we're interested in long-term security improvements that can be adopted by all vendors and make the web a better platform for developing powerful web applications. We've just scratched the surface in terms of the tests we hope to add, but here's what's in the initial test suite:
Secure cross-origin messaging. (3 tests) It used to be that in order to get some data from another site on the client side, you'd have to find a loophole in the browser's same origin policy. The common trick was to give the other site all your privileges via a <script> tag, which requires a trust relationship between sites that is bordering on absurd. Luckily, we've seen rapid deployment of secure cross-origin messaging in recent years. We're testing for the new postMessage communication primitive, as well as deserialization (JSON.parse) and sanitization (toStaticHTML) features that allow sites to safely manipulate the data they receive.
XSS mitigations. (3 tests) Web 2.0 is all about combining user-generated content, but sanitizing this content is quite difficult. Recently browser vendors have stepped in to make life easier by automatically blocking the most common form of cross-site scripting (XSS) attacks. We simulate a reflected XSS attack to check whether these filters are in place. Stylesheets are another common XSS vector, so we check whether the browser blocks script in CSS (expressions and cross-site XBL). And finally, we test the httpOnly cookie attribute, which makes it harder for XSS attacks to hijack a session.
Execution environment integrity. (2 tests) Earlier this year, we wrote about the various challenges that script authors face when running in a hostile execution environment. For example, Flash Player, Google's AJAX API, and many bookmarklets use the global
location object to determine what page they're running on. If a web page can trick the script into thinking it's running on a different page, the script might give away the user's password or otherwise behave incorrectly. We're testing whether browsers are protecting the integrity of
location and other native APIs that can be used for JSON hijacking.
Cross-origin DOM access. (2 tests) We've also included some tests for whether browsers are following the HTML5 standard for accessing documents in other origins. Following the industry standards for security policy enforcement reduces the risk of cross-origin privilege leaks, and helps web application authors by providing consistent a consistent platform to develop on.
These tests are just the beginning. We're planning to add tests for browser encryption (Strict-Transport-Security), clickjacking mitigations (X-Frame-Options), and more. Got an idea for a test you'd like to see? Send a message to the Browserscope group and let us know. Oh, and don't forget to run the tests: