Bug 1586630 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by

Paul Theriault [:pauljt] (no longer reading bugmail)

on 2019-10-06 18:03:20 PDT

(Hidden by Administrator)

Revision 1 by

Honza Bambas (:mayhemer)

on 2019-10-07 07:23:43 PDT

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 `/dir/subdir/cache.manifest`, has `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. 

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.