InformAction Forums

https://thestack.com/security/2015/09/2 ... -browsers/

I wonder if NoScript protect us against that?

If setting the browser to only allow first-party cookies isn't enough, then can't you protect against this with NoScript's Force-HTTPS feature?
(Well, at least, I'd think it'd work if the sites use proper encryption and all that over their HTTPS connection...)

Three points:

1.
The URL in the first post (thestack dot com).
When I clicked the link there seemed to be 'something trying to download'.

I used another Profile [which was also using Fx 43.0a2 (2015-09-27)] and used
startpage https://startpage.com to search for the URL This found the same URL as in the first post.

Clicking on the link, from the 'startpage results',
also had the 'something trying to download'.

So, I've not read the linked post.
I don't know is there is 'an issue at thestack's website'.
Might be something at my end.

However, I decided to post in case others 'see odd things' when clicking the link.


2.
US-CERT's "Current Activity" page
https://www.us-cert.gov/ncas/current-activity
Has a link to the Vulnerability Note
Cookies set via HTTP requests may be used to bypass HTTPS and reveal private information
http://www.kb.cert.org/vuls/id/804060
Original Release date: 24 Sep 2015. Last revised: 24 Sep 2015

This page has helpful information and links.

Selective quotes include:

> A complete solution may include future updates to RFC 6265 and/or RFC 6454
> to enable safer handling of cookies via an updated same origin policy for cookies.

> However, the following workarounds help mitigate this issue:

> Deploy HSTS on top-level domain
I speculate that this might take sometime.

> Ensure you are using the latest version of your browser of choice so you have full HSTS support.
See the list, on the page, of when some browsers included HSTS support.


3.
Serendipity, FYI, about HSTS cookies.

CCleaner, v5.10.5373 (24 Sep 2015)
has
- Added Firefox HSTS (HTTP Strict Transport Security) cookie cleaning.
see
http://www.piriform.com/ccleaner/releas ... /5.10.5373

DJ-Leith

@DJ-Leith

1) Server problem that wasn't there when yes_noscript posted. The thing trying to download is a gzip of the HTML page, and it comes out clean in a scan by ClamAV.
HTTPFox: So just wrong MIME type and (as seen when attempting the download) wrong file extension.
We can temporarily mangle the link if this really a problem for users or too much a red flag, but I personally don't think it's needed.

2) FWIW, last I checked, NoScript provides HSTS in browsers it supports that don't have builtin HSTS...

3) CCleaner is reportedly very dangerous to Firefox and Firefox profiles. Proceed with caution when following that suggestion.

@barbaz

Re: 1.
Thanks for checking thestack's site.
I agree, you don't need to edit the URL.
I bailed before the "gzip of the HTML page" was downloaded.

Re 2.
I've yet to read the
"research paper by Zheng, et. al., published at USENIX Security 2015."

The abstract does include:
"... An adversary controlling a related domain is also capable to disrupt
a cookie's integrity by making use of the shared cookie scope. Even worse,
there is an asymmetry between cookie's read and write operations involving
pathing, enabling more subtle form of cookie integrity violation. ..."
The PDF is 16 pages.


Re 3.
I'm not endorsing CCleaner, just noting that HSTS cookie cleaning has recently
been added.

My personal frequent use of CCleaner (with 'tidy Profiles' - that are also backed up)
has been trouble free.

On Windows,
Profiles that are not in the 'expected place' e.g.
are not 'detected (or cleaned)' by CCleaner.

Ones that are in the 'expected part of the tree' are cleaned.

Also, I don't keep any HSTS cookies (but if I did I might be interested in a tool that
allowed one to do somthing along the lines of: 'clear all the cookies except for {my list}').

DJ-Leith

Perhaps the best approach for this would be something like integration between HTTPS Finder and NoScript? It's been requested before, but the author seems to have pretty much abandoned the project.

I've now read the Paper "sec15-paper-zheng-updated.pdf", the 2015-08-13 version, from
https://www.usenix.org/conference/useni ... tion/zheng

Some comments:

* this is a peer reviewed paper, some references were last checked (by the authors) in February 2015,
some issues have been documented since 2002. So the underlying issues have been present, and poorly
understood, for a long time.

* I'm no expert (in this area) but I did find the paper very interesting.

To whet your appetite:
" ... For example, a cautious user might only visit news websites at open wireless networks like those at
Starbucks. She might not know that this is sufficient for a temporary MITM attacker to inject malicious cookies
to poison her browser, and compromise her bank account when she later logs on to her bank site at home.

We aim to understand how could attackers launch cookie inject attacks, and what are the damaging consequences
to real-world websites. Our study shows that most websites are potentially susceptible to cookie injection
attacks by network attackers. For example, only one site in the Alexa top 100 websites has fully deployed HTTP
Strict Transport Security (HSTS) on its top-level domain, a sufficient server-side protection to counter cookie
injection attacks by network attackers (Section 3). ... ..."

They did manage to compromise several e-commerce sites.

Back to the OP's question

yes_noscript wrote: I wonder if NoScript protect us against that?

The use of the NoScript,
Options, Advanced, HTTPS, "Enable Automatic Secure Cookies Management"
might help in some cases.

Rephrasing the question:
Will NoScript's "Automatic Secure Cookies Management" defeat all the
vulnerabilities mentioned in the paper?

I don't think so. I certainly would not assume so.

What might defeat many of these attacks is to use Firefox JUST to do one
important thing (e.g. webmail) and then close Firefox, discarding all the cookies.

I advocate and use 'specific Firefox Profiles for specific uses / sites'.
Examples include a Profile 'just used for Bank' and a separate one 'just for webmail'
and a third one 'just for making online purchases' (general looking at 'things to buy'
is done in yet another Profile).

All my Profiles have NoScript (NS) to block Javascript (and other active content) and
RequestPolicy Continued (RPC) to block all outgoing requests from the 'site I appear to be on',
as seen in the 'URL bar', to other sites.

These 'other sites' might be to Content Delivery Networks (CDNs)
but they might be to Advertising Networks.

RPC is controlling 'all outgoing Requests', which might 'collect an image', 'collect a script',
'collect an advert' etc
FROM the 'site you appear to be on' TO another domain.

All Profiles, where I do ANY 'logging in', are set to clear all
Cookies, Active Logins, Cache, Forms & Search History,
Site Preferences and Offline Web Site Data when you close Firefox.
Most of these Profiles also clear Browsing & Download History as well.

See
Using Release, ESR, Beta, Aurora, and/or Nightly together.
http://forums.mozillazine.org/viewtopic ... &t=2821799
for a good source of ideas of how to use many Profiles.


Another piece of serendipity FYI, (please don't comment in the bugzilla bug)
Richard Barnes has added a telemetry probe to Nightly (Fx 44).

Add telemetry to measure how often secure cookies are set from non-secure origins
https://bugzilla.mozilla.org/show_bug.cgi?id=1208847

Richard Barnes wrote: Some recent research highlights risks that arise from non-secure origins being able to set secure cookies.

https://www.usenix.org/system/files/con ... pdated.pdf

As a prelude to making any changes to cookie handling rules, we should add a telemetry probe to see how often
this happens in practice. (For completeness, though, let's measure the whole matrix of cookie/origin
secure/nonsecure.)

DJ-Leith

DJ-Leith wrote: What might defeat many of these attacks is to use Firefox JUST to do one important thing (e.g. webmail) and then close Firefox, discarding all the cookies.

Have you checked out the Self-Destructing Cookies extension? It monitors your cookies and promptly wipes them after you close the associated tab(s). I think it's how cookie-based login should always have been!

(Personal endorsement only, not official - and as I'm not the developer, I can't make any guarantees about its usefulness or safety, of course, only that it's worked well for me.)