Closed
Bug 327063
Opened 18 years ago
Closed 18 years ago
nsXFormsUtils::CheckSameOrigin should use the principal's URI, not the document's
Categories
(Core Graveyard :: XForms, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bzbarsky, Assigned: doronr)
Details
(Keywords: fixed1.8.0.2, fixed1.8.1, Whiteboard: [sg:nse])
Attachments
(1 file)
1.04 KB,
patch
|
dveditz
:
review+
allan
:
review+
mkaply
:
approval1.8.0.2+
|
Details | Diff | Splinter Review |
When doing security checks, you want to use the URI (or domain? not sure; no one's ever clearly explained the difference to me) from the principal, not the document's URI. nsXFormsUtils::CheckSameOrigin passes the document URI as the URI to the permission manager, however. This can definitely lead to things not getting the permissions they should (eg with data: URIs). It can also lead to privilege escalation once we have non-principals in place.
Assignee | ||
Comment 1•18 years ago
|
||
Assignee | ||
Updated•18 years ago
|
Attachment #211786 -
Flags: review? → review?(bzbarsky)
![]() |
Reporter | |
Comment 2•18 years ago
|
||
Comment on attachment 211786 [details] [diff] [review] like this? Like I said, I don't know whether you want GetURI or GetDomain. I suggest asking someone who knows the difference (caillon? dveditz?) for review.
Attachment #211786 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 3•18 years ago
|
||
Comment on attachment 211786 [details] [diff] [review] like this? is this really a security issue though?
Attachment #211786 -
Flags: review?(dveditz)
![]() |
Reporter | |
Comment 4•18 years ago
|
||
If it's not one now (which is possible, I guess), it sure will be one once bug 326506 lands!
Comment 5•18 years ago
|
||
Comment on attachment 211786 [details] [diff] [review] like this? r=dveditz Yeah, this is what we want.
Attachment #211786 -
Flags: review?(dveditz) → review+
Assignee | ||
Updated•18 years ago
|
Attachment #211786 -
Flags: review?(allan)
Updated•18 years ago
|
Attachment #211786 -
Flags: review?(allan) → review+
Assignee | ||
Comment 6•18 years ago
|
||
checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•18 years ago
|
||
Fixed on 1.8 branch. Does this need to go into 1.8.0?
Keywords: fixed1.8.1
Comment 8•18 years ago
|
||
Comment on attachment 211786 [details] [diff] [review] like this? a=mkaply
Attachment #211786 -
Flags: approval1.8.0.2+
Assignee | ||
Updated•18 years ago
|
Keywords: fixed1.8.0.2
Comment 9•18 years ago
|
||
I don't believe this was a security issue absent changes that haven't yet happened. What might happen with a non-http/ftp base URL is that there will be no host part, so the Permission Manager should not have an "approval" entry for it. The failure mode would seem to be that we'll block valid connections (data urls would appear to have no host) and not allowing connections we shouldn't.
Whiteboard: [sg:nse]
Updated•18 years ago
|
Group: security
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•