What Makes A Good Browserscope Security Test?
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.