Closed Bug 1408400 Opened 2 years ago Closed 2 years ago

Consider using a blacklist for blocking toplevel data URI navigations

Categories

(Core :: DOM: Security, enhancement, P1)

enhancement

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ckerschb, Assigned: ckerschb)

References

Details

(Whiteboard: [domsecurity-active])

Maybe we should consider using a blacklist (as discussed here [1]) instead of a whitelist to block toplevel data URI navigations. I would imagine it's sufficient to block:

* text/html
* text/svg
* image/svg

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1403814#c17
Assignee: nobody → ckerschb
Blocks: 1401895
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [domsecurity-active]
> I would imagine it's sufficient to block

It's not.  We want to block at least for anything in gHTMLTypes, gXMLTypes, gSVGTypes, gXULTypes in nsContentDLF.cpp.  It doesn't look like we have an existing API for checking those lists, unfortunately (e.g. nsIWebNavigationInfo::IsTypeSupported will return "OTHER" for not just those types but also text types and audio/video types).  But we could add such an API, of course.

The big question is whether that list of types is enough.
I suggested blacklisting, since white listing is hard to get right. We don't know for what all people validly use data:.
Thanks Smaug and Boris for your feedback. As discussed the blacklist approach seems hard. It makes more sense to evaluate data: URI loads that are actually going to be openend in the browser, which we are going to implement over in
https://bugzilla.mozilla.org/show_bug.cgi?id=1403814#c27
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.