(In reply to Paul Theriault [:pauljt] (needinfo pls) from comment #0)
There is an issue in our appcache implementation that allows a manifest served from a subdirectory, to confuse the browser into using the appcache to requests to the top level directory. (i.e. we dont enforced the rule that appcache is only supposed to be able to be responsible for requests to sub-directories.
This bug was confirmed by Honza. From email:
I quickly confirmed on IIS 10 with statically served content: when the <html manifest> attribute value is in a form of "/dir%2fsubdir%2fcache.manifest" and the manifest, served at
FALLBACK: / some-evil-resource-url, we load the evil resource for anything that can't be found on the web site for the origin the document was loaded in.
An example of a real world attack scenario (which I'm not linking, so as not to draw attention) is given in https://bugzilla.mozilla.org/show_bug.cgi?id=1376459#c4.
That was a general case that have been fixed by bug 1376459 - to force fallback entries to be in the directory or a subdir of the manifest.
The problem that we are considering here is escaping of the path that can bypass that check easily (as I demoed in the email). If you make a request to
https://foo.com/dir1/dir2/resource it may or may not be the same as
https://foo.com/dir1%2fdir2%2fresource (or its variations). For IIS (static) it is the same path, but we see the Directory as '/'; for Apache (static/rewrite) it is not the same path (we are safe there, the attack is not possible). I haven't tested e.g. nginx static/rewrite path escaping behavior, but I probably don't have to.
Based on the different interpretation of a path with escaped slashes by servers, we can't canonicalize the path by unescaping (%2f -> '/') as that would lead to a different resource being requested on, specifically, Apache servers.
We could do the unescaping exclusively for appcache resources (and force reload/cleaning/fallback entries cleanup of existing users' appcaches?) to mitigate this attack. I don't think that modifying the Directory getter on nsIURI(L?) behavior generally to always unescape would be a good idea.
The only proper way IMO is to disable appcache.
While appcache is close to deprecation, as we have had external reports here of this issue, I'm filing this bug to consider if a fix is need in the short term, or if we can just push for appcache deprecation (1237782 ). The consensus from the discussion so far is that deprecation will not make ESR68, so we make need an interim fix.