In the past few days, Google’s Online Security blog has made a few posts related to closing the security hole that Javascript opens. As a popular vector for infecting site visitors, Google is helping where they can – inside the Google Chrome browser. Mozilla Firefox has its add-on, NoScript, which helps secure users with it installed from malicious Javascript on webpages. While Chrome has a similar, inspired-by-NoScript plugin called NotScripts, it’s less functional. Chrome is trying to include similar, smarter features in the browser natively.
A week ago, the Google Online Security Blog announced that in Chrome 14, currently in the dev-release channel, an alert bar will pop up whenever there are non-HTTPS scripts running on an HTTPS page.
You can enable this same behavior in Chrome 13 by starting Chrome with a certain parameter.
The latest Chromium 13 dev channel build (13.0.782.10) has a command line flag: –no-running-insecure-content. We recommend that website owners and advanced users run with this flag, so we can all help mop up errant sites. (We also have the flag –no-displaying-insecure-content for the less serious class of mixed content issues; there are no plans to block this by default in Chromium 14).
The Chromium 14 release will come with an inverse flag: –allow-running-insecure-content, as a convenience for users and admins who have internal applications without immediate fixes for these errors.
This will be an interesting setting change to watch as it travels through the beta channel to see how the feature is adopted. Whereas the previous alert of a broken lock was maybe too subtle, this change may swing to the other side and become too annoying for many users. The question for the Chrome development team then becomes a battle between improving security and increasing browser market share. User education can go a long way but steering the whole Internet can be a time-consuming change.
For Developers, Testers, and Security Researchers
On Tuesday, Google released an experimental plugin called Dom Snitch to help developers and testers identify insecure implementations of client-side code.
To do this, we have adopted several approaches to intercepting JavaScript calls to key and potentially dangerous browser infrastructure such as document.write or HTMLElement.innerHTML (among others). Once a JavaScript call has been intercepted, DOM Snitch records the document URL and a complete stack trace that will help assess if the intercepted call can lead to cross-site scripting, mixed content, insecure modifications to the same-origin policy for DOM access, or other client-side issues.
Google lists these benefits of using the plugin:
- Real-time: Developers can observe DOM modifications as they happen inside the browser without the need to step through JavaScript code with a debugger or pause the execution of their application.
- Easy to use: With built-in security heuristics and nested views, both advanced and less experienced developers and testers can quickly spot areas of the application being tested that need more attention.
- Easier collaboration: Enables developers to easily export and share captured DOM modifications while troubleshooting an issue with their peers.
DOM Snitch is intended for use by developers, testers, and security researchers alike. Click here to download DOM Snitch. To read the documentation, please visit this page.
Everything leading to a more secure web experience is always welcome but one must also wonder if this won’t speed up malicious users’ ability to find and exploit vulnerable code. The eternal race…