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 220.127.116.11 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.
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.