Archive for September, 2008

Mike Perry's Automated HTTPS Cookie Hijacking just made Slashdot's front page, so I decided to spend some time nesting a countermeasure inside NoScript's request intercepting guts.

The original idea comes from an email conversation I had with pdp just after his GMail account had been compromised: he suggested to mark every cookie with the "Secure" attribute, causing the browser to send it exclusively over HTTPS connections.
Later he detailed this concept as a feature of his yet to be developed BrowserSecurify plugin:

Secure cookies: The feature will prevent the browser from sending cookies over unecrypted channels, once activated. This feature will mark insecure cookies as always secure. This effectively means that you login into GMail and continue browsing Google over unencrypted channel not being afraid of leaking sensitive data which can be used to compromise your GMail account.

NoScript's new feature, called Forced Secure Cookies is slightly different, less obtrusive and non-interactive.
In facts, NoScript just intercepts the "Set-Cookie" headers which are being sent over encrypted connections and are not flagged as "Secure" yet, adding the missing attribute on the fly before the cookie is stored.
This way, only those cookies actually created in the context of an encrypted transaction are forcibly switched to "Secure", and therefore sites having lower security requirements and needing insecure cookies to work as a non-sensitive persistence mechanism are less likely to break.
Obviously those sites creating session-identifier cookies over insecure channels and recycling them after secure authentication won't be helped by this implementation, but it's apparently not the case of GMail, for instance.
However, should that prove itself to be such a common pattern to be worth protecting, a check on HTTP/HTTPS switching could be added to erase any previously set domain cookie.

Forced Secure Cookies, like Anti-XSS Filters, are designed to work independently from your trusted whitelist; in other words, it does not care about JavaScript and plugins permissions and will be effective even if you "allow script globally" (not recommended, as usual).
Are you're in the mood for beta testing? Please grab latest NoScript development build and drop me a line if it appears to summon any black hole swallowing your planet.

Since I spent a relevant portion of my past two days answering email messages similar to the following, I decided to post a catch-all answer here.

Hi Giorgio,

I just read Google's introduction to its Chrome browser.
I was so impressed with its security features that I may even switch from Firefox to Chrome. (I didn't think that was even possible when I first heard of Chrome.)
Would you consider adapting your NoScript add-on to it?
I tried out Chrome and loved it, but the absence of NoScript was immediately apparent!


Hi Seth,

I've been playing with Chrome since it's been available, and I cannot say I'm impressed with its security.
I do like its speed, but Fx 3.1 builds with TraceMonkey enabled are already faster.
I really love its taskmanager: opening a random MySpace page and watching CPU and RAM consumption skyrocketing blamed precisely on the Flash plugin (70MB Flash, 28MB the page itself versus 11MB for an empty tab) is kind of cool, even if it comes with the cost of redundant resource allocation (if it was Firefox, crowds would be screaming "memory hog").
On the other hand, there's nothing apparently novel in its security approach, and it doesn't address any in-browser security problem, such as XSS or CSRF, at all.

The worst part, though, is that Chrome is not nearly as extensible as Firefox: cynical people may suspect this is to prevent something like AdBlock Plus or NoScript itself to be ported, biting advertisement bottom lines.
This is such a bummer that Google had to issue a late announcement about an extension API, but if it's gonna be like Opera's widgets (as I strongly suspect) it won't help.

BTW, one of Chrome's most hyped features, stability due to the claim you might crash one tab but not the whole browser, fully justifies the "beta" tag:
Chrome Crash


Bad Behavior has blocked 931 access attempts in the last 7 days.