Closed Bug 832558 Opened 7 years ago Closed 7 years ago

userpass in URLs treated as part of the host name, allowing injected app content to bypass CSP

Categories

(Firefox OS Graveyard :: General, defect)

x86
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED INVALID
blocking-b2g -

People

(Reporter: dveditz, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: sec-high)

+++ This bug was initially created as a clone of Bug #779918 +++

The flip side of bug 779918 blocking too much because of the "auth" part of a URI is using fake auth to bypass CSP restrictions. I haven't tested this in B2G, but if true this would allow bypasses of the system-imposed restriction of "script-src: 'self'" so that a malicious (or XSS'd) app could load remote scripts (among other things).

This might only apply to Open Web Apps rather than packaged apps. I hope the app: protocol handler rejects URLs with auth in them, but even if they're allowed injected content would still be stuck with the app: scheme so could at best inject script content from another installed app:. Injections of other types of resources could happen though.

The fix will be bug 779918, filing this one to track fixing it in B2G because it's somewhat more severe in this case.
OS: Windows XP → Gonk (Firefox OS)
blocking-b2g: --- → tef?
Blocks: CSP
Doesn't look like 779918 is moving.  

Can you help me understand the vector of the bypass?  I understand (at least I think I do) that we are mistakenly including the "auth" part of scheme in the origin check, but I don't understand how that could transform a given remote origin into the equivalent origin as "self" (lets say self == "http://www.goodguy.com").  Seems like goodguy would have to instead use a very strange origin like "random:junk@www.goodguy.com"?
Assignee: nobody → imelven
Flags: needinfo?(dveditz)
Assignee: imelven → nobody
If someone writes a test case for this bypass that I don't fully understand, I am happy to write the fix.
Please renom after needinfo is satisfied.
blocking-b2g: tef? → -
This is not a separate bug than 779918, but filed this here for b2g tracking because I believe this may be more serious in that context. But on reflection I may be over-worried: I was thinking https://www.goodguy.com:foo@evil.com would match a whitelist of https://www.goodguy.com -- but it should NOT since a sub-string match like that would be broken in other ways as well.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: needinfo?(dveditz)
Resolution: --- → INVALID
Group: core-security
You need to log in before you can comment on or make changes to this bug.