Closed
Bug 250862
Opened 20 years ago
Closed 20 years ago
browser accepts dragged javascript: links (same-origin security hole)
Categories
(Core :: DOM: Navigation, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jruderman, Assigned: jst)
References
Details
(Keywords: fixed-aviary1.0, fixed1.4.4, fixed1.7.3, Whiteboard: [sg:fix])
Attachments
(2 files, 1 obsolete file)
877 bytes,
text/html
|
Details | |
2.92 KB,
patch
|
caillon
:
review+
dveditz
:
superreview+
asa
:
approval-aviary+
asa
:
approval1.7.5+
|
Details | Diff | Splinter Review |
Firefox accepts drags of javascript: links, allowing same-origin violations.
Exploiting this hole requires getting the user to cooperate with instructions,
but does not require the user to do anything likely to make them suspicious.
I think Seamonkey has the same hole.
Combined with 250725 (Drag-and-dropped link skips CheckLoadURI), this
same-origin hole becomes an arbitrary code execution hole.
Reporter | ||
Updated•20 years ago
|
Flags: blocking-aviary1.0RC1?
Reporter | ||
Comment 1•20 years ago
|
||
This demo works in Firefox and Mozilla, but it works better in Firefox.
Reporter | ||
Comment 2•20 years ago
|
||
Mike, this should block Mozilla 1.7.2.
Comment 3•20 years ago
|
||
-> Browser product so we can make it block more releases
Component: General → Embedding: Docshell
Product: Firefox → Browser
Version: unspecified → 1.0 Branch
Comment 4•20 years ago
|
||
+ing for dveditz to look at.
Flags: blocking-aviary1.0RC1? → blocking-aviary1.0RC1+
Priority: -- → P5
Comment 5•20 years ago
|
||
Why do we allow privileged chrome inside a browser control? A few things
(about:config, about:plugins) would have to be moved into a chrome windows of
their own if we did that, but might be way safer in the long run.
Is javascript: the only scheme that isn't a complete replacement document?
Flags: blocking1.8a3+
Flags: blocking1.7.2+
Reporter | ||
Comment 6•20 years ago
|
||
We should also block data: URLs here, since like javascript: URLs, they inherit
their security context from the previous page. (The fact that they can also act
as replacement URLs caused both Mozilla and IE to be vulnerable to bug 88167.)
Updated•20 years ago
|
Priority: P5 → P2
Comment 7•20 years ago
|
||
dan any updates on when a patche will be ready for this?
Updated•20 years ago
|
Flags: blocking1.8a3+ → blocking1.8a3-
Comment 8•20 years ago
|
||
why not disallow dragging into location bar if the protocol or the begining of
the URL is not "http" or "https" ?
i don't see any functional advantage of dragging into location bar compared to
clicking or middle clicking.
Comment 9•20 years ago
|
||
sorry, didn't see the demo.
obviously the problem is not the location bar.
Assignee | ||
Comment 10•20 years ago
|
||
Assignee | ||
Comment 11•20 years ago
|
||
Attachment #156549 -
Attachment is obsolete: true
Comment 12•20 years ago
|
||
Comment on attachment 156550 [details] [diff] [review]
Same thing for both Firefox and SeaMonkey
sr=dveditz
Attachment #156550 -
Flags: superreview+
Assignee | ||
Updated•20 years ago
|
Attachment #156550 -
Flags: review?(caillon)
Comment 13•20 years ago
|
||
I checked the other onDrops in the codebase (except calendar) and everything
else javascript urls are either already rejected or harmless (e.g. setting your
home page to a js url).
Assignee: dveditz → jst
Updated•20 years ago
|
Attachment #156550 -
Flags: review?(caillon) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #156550 -
Flags: approval1.7.3?
Attachment #156550 -
Flags: approval-aviary?
Comment 14•20 years ago
|
||
Comment on attachment 156550 [details] [diff] [review]
Same thing for both Firefox and SeaMonkey
a=asa for branch landings.
Attachment #156550 -
Flags: approval1.7.3?
Attachment #156550 -
Flags: approval1.7.3+
Attachment #156550 -
Flags: approval-aviary?
Attachment #156550 -
Flags: approval-aviary+
Comment 15•20 years ago
|
||
looks like with the patch dragging "file" and "chrome" urls still may work which
may lead to trouble.
why not use a safe whitelist?
Updated•20 years ago
|
Whiteboard: [have patch]
Assignee | ||
Comment 16•20 years ago
|
||
We decided against blocking chrome for now, we'll need to investigate the
results of blocking that more before flipping the switch. Bug 250725 is for
tracking that part, but that, in combination with this, is really bad, thus the
fix for this to start with.
Updated•20 years ago
|
Whiteboard: [have patch] → [have patch] ready to land
Assignee | ||
Comment 17•20 years ago
|
||
Fixed on trunk, aviary, and 1.7 branches.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0,
fixed1.7.3
Resolution: --- → FIXED
Updated•20 years ago
|
Keywords: fixed1.7.2
Whiteboard: [have patch] ready to land → [sg:fix] fixed1.7.2+
Comment 19•20 years ago
|
||
Verified with Firefox 0.10 and Mozilla 1.7.3 on windows XP
Updated•20 years ago
|
Group: security
Whiteboard: [sg:fix] fixed1.7.2+ → [sg:fix] fixed1.7.3
Updated•20 years ago
|
Keywords: fixed1.7.5 → fixed1.7.3
Whiteboard: [sg:fix] fixed1.7.3 → [sg:fix]
Updated•20 years ago
|
Keywords: fixed1.4.4
Comment 21•17 years ago
|
||
What about images in data: URL's?
It could be useful to allow these, as right now there's a little incoherence: you can drag file: or http: based images but not data: ones.
You need to log in
before you can comment on or make changes to this bug.
Description
•