Closed
Bug 189799
Opened 22 years ago
Closed 22 years ago
JavaScript Security policy for specific site can be circumvented
Categories
(Core :: Security: CAPS, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: martin, Assigned: security-bugs)
Details
(Whiteboard: patch)
Attachments
(1 file)
1.26 KB,
patch
|
hjtoi-bugzilla
:
review+
dveditz
:
superreview+
asa
:
approval1.3b+
|
Details | Diff | Splinter Review |
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:secret@mozilla.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
Assignee | ||
Comment 1•22 years ago
|
||
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:b@foo.com are treated as the same origin. Patch to follow.
Group: security
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: patch
Assignee | ||
Comment 2•22 years ago
|
||
Assignee | ||
Updated•22 years ago
|
Attachment #112228 -
Flags: superreview?(jst)
Attachment #112228 -
Flags: review?(heikki)
Updated•22 years ago
|
Attachment #112228 -
Flags: review?(heikki) → review+
Updated•22 years ago
|
Flags: blocking1.3b?
Comment 3•22 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 4•22 years ago
|
||
Comment on attachment 112228 [details] [diff] [review]
Patch - ignore user:pass in host comparisons
sr=dveditz
Attachment #112228 -
Flags: superreview?(jst) → superreview+
Comment 5•22 years ago
|
||
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.
Flags: blocking1.3b?
Comment 6•22 years ago
|
||
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.
Attachment #112228 -
Flags: approval1.3b+
Assignee | ||
Comment 7•22 years ago
|
||
Fix checked in. Should I patch the 1.0.x branch too?
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 8•21 years ago
|
||
Bugs published on the Known-vulnerabilities page long ago, removing confidential
flag.
Group: security
You need to log in
before you can comment on or make changes to this bug.
Description
•