User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2; MultiZilla v1.1.32 final) Gecko/20021126 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2; MultiZilla v1.1.32 final) Gecko/20021126 When using a RFC1737 encoded URL with username and password prepended with an @ to the hostname (i.e http://alice:firstname.lastname@example.org/ ), the sites configuration entry is not correctly applied. Reproducible: Always Steps to Reproduce: 1. restrict js-capabilities to a specific URL and check it is correctly enforced as described in http://www.mozilla.org/projects/security/components/ConfigPolicy.html 2. Now, type in exactly the same URL but prepend a:b@ Actual Results: the formerly restricted capability is now accessible. Expected Results: Mozilla should have blocked the capability regardless of the prepended @-string
Good catch! I'm making this Security-Sensitive. Martin, if you disagree, you can uncheck the box above. Turns out the problem is the use of GetPrePath in nsCodebasePrincipal::GetOrigin, since PrePath includes the username/password. I think we should exclude those from security comparisons, so that foo.com and a:email@example.com are treated as the same origin. Patch to follow.
15 years ago
15 years ago
I don't think this bug needs to be security sensitive since by default we provide a secure configuration that doesn't depend on site lists. Sure, not good that an extra feature we provide (unavailable in other browsers) can so easily be defeated, but that's just a bug and isn't necessarily sensitive.
Comment on attachment 112228 [details] [diff] [review] Patch - ignore user:pass in host comparisons sr=dveditz
To request approval from drivers to land a reviewed patch use the "approval1.3b ?" flag in the patch manager rather than the blocking1.3b? flag in the bug.
Comment on attachment 112228 [details] [diff] [review] Patch - ignore user:pass in host comparisons a=asa (on behalf of drivers) for checkin to 1.3beta.
Fix checked in. Should I patch the 1.0.x branch too?
Bugs published on the Known-vulnerabilities page long ago, removing confidential flag.