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.

14 Responses to “NoScript vs Insecure Cookies”

  1. #1 Josep says:

    What happens with sites that only use HTTPS for the submission of the login/pass?

    I mean, you login to a site over HTTPS, it checks your username and if correct sends a session cookie to be used over non HTTPS connections (to not overload the server with encryption). If NoScript force the cookie to be secure, then navigating to non HTTPS pages of the site won't log you out?

  2. #2 Giorgio says:

    you're right, sites working like that are would break and, unless they can be forced to always use HTTPS, they could not be protected anyway.
    That's why NoScript checks a noscript.secureCookiesExceptions about:config preference to work-around this kind of situation.
    Unluckily, I've found that this "secure login only" flaw is surprisingly common (Hotmail and Yahoo! Mail are examples), so switches to an opt-in policy controlled by the noscript.secureCookiesForced preference, whose default will be "www.google.com, gmail.google.com".
    I've also added noscript.httpsForced preference that can be used to list domains which we want to always use secure connections.

  3. #3 Aerik says:

    I'm using with fresh cookies, no problems for me anywhere. Places I go to often:

    .blogspot.com blogs
    .wordpress.com blogs

    * I use google firefox extensions to always force https across google minus ap.google.com and www.google.com/search . The "secure-em-all" extension works well on other sites I force https across multiple subdomains but not all subdomains.

  4. #4 Philipp says:

    I am currently using the Add-on Redirector for forcing sites to use HTTPS, it can redirect from one URI to another on an wildcard or RegExp scheme, so it would - unlike the Noscript nigthly - also work if sites that force you to use another subdomain (most often "secure." or like) for secure connections.

  5. #5 Philipp says:

    PS: It may be noted however that this Add-on unfortunately does not work with sites redirected to by POST or embedded content (images, objects).

  6. #6 Zero Day mobile edition says:

    [...] 10 free security utilities you should already be using ] Maone described the new feature as a countermeasure against Mike Perry's automated HTTPS cookie-hijacking attack (see CookieMonster tool) that's [...]

  7. #7 ammad says:

    What if Noscript checks whether a site sends bad cookies and just warns the user, like xss does now?

  8. #8 Blaise Alleyne says:

    In the last few days, I've been unable to log into del.icio.us, Twitter and Fire Eagle. I just disabled NoScript, and now I can login fine.

    Could this new feature be getting in my way?

  9. #9 Giorgio says:

    @Blaise Alleyne:
    some of the early versions could, but latest stable and development versions of NoScript have no problem with logins.

  10. #10 Blaise Alleyne says:

    Turns out I did have an older version, it was just auto-updated to and the Twitter fix was explicitly mentioned in the release notes. Thanks!

  11. #11 Wat sind eigentlich flash-cookies? | Der Gretzer says:

    [...] NoScript vs Insecure Cookies [...]

  12. #12 Keybounce says:

    ... switches to an opt-in policy controlled by the noscript.secureCookiesForced preference, whose default will be “www.google.com, gmail.google.com”. ...

    What about all the rest of the stuff at google?

    Reader, maps, news, personalized home page, ** DOCS **, etc.

    Most of the pages support secure stuff. Right now I have "Always use HTTPS" in gmail, and I have the newest noscript, yet going to the insecure pages (such as www.google.com) still identify me by email.

    Gaa, there's a noscript warning below me, with a recaptcha. Hope this works.

  13. #13 Giorgio says:

    account info (not service authorization!) is on cookie belonging to www.google.com. This means that you can leak your user id token, but not your authorization token.
    BTW, there's no default for forcing secure cookies anymore.
    For your purposes, putting "google.com" in your NoScript Options|Advanced|HTTPS|Cookies|Force encryption for all the cookies... list should suffice.

  14. #14 hackademix.net » You Don't Know What My Twitter Leaks says:

    [...] to your HTTPS behavior forced list and enabling automatic secure cookies management, to defeat cookie hijacking [...]

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