Minor clobbering issue of NamedNodeMap about dompurify

[cure53]

I agree, we need to work around that problem. We kinda saw it coming... #64 (comment) :)

[cure53]

This is the PR we should have a look at: #70 The issue itself is minor indeed so we're not in a hurry.

[cure53]

@filedescriptor I am not 100% sure if we should fix this issue. The problem affects an outdated browser and requires an attacker to have access to an Iframe's src attribute on the target page.

We could implement a type check and make sure that MozNamedNodeMap is of type function and not object as the attacker would clobber it with window. But then again, is it really a feasible attack?

[cure53]

@filedescriptor My tests further sowed that this attach doesn't seem to be possible using (cross-origin) redirects. So an attacker cannot seem to e.g. provide a legitimate URL, then redirect, then clobber MozNamedNodeMap and then deactivate DOMPurify. Or am I missing something? Thoughts are welcome :)

[Joris-van-der-Wel]

@cure53 typeof MozNamedAttrMap is "object"

Since jsdom does not implement MozNamedAttrMap, you could use Object.prototype.toString() for that one specifically (I have not checked if this works properly in FF22-34, but I can test it if you want).

[cure53]

I just chatted with @filedescriptor and we concluded that it is not an exploitable issue for now. The problem only appears when the Iframe's URI can be attacker controlled directly. Redirects do not work. Closing this for now.

[filedescriptor]

So I had a look and it seemed that FF 23 or below may be vulnerable to this attack. The main thing is that in older FF we can clobbering iframe without it being same-origin. FF 24 and after changed its behavior.

[neilj]

You would still have to do the clobbering before the purify library loads, since the value is cached. We also presume that you haven't clobbered the document before purify loads.

[filedescriptor]

Yeah I already mentioned that, though it is not totally impossible. I haven't checked DOMPurify for a while and didn't notice now we rely on document not being polluted before the library loads (we used to check a bunch of types to ensure them not being clobbered in the first place).

[cure53]

I think one of the core points here is:

A website might load an Iframe from a third-party domain. If that Iframe could redirect to data URI and then use this to clobber, we'd have a major issue. Since this is only the case in legacy FF, we should be good here.

So, in summary, I am good with the "wontfix" unless additional concerns pop up.