Closed Bug 35273 Opened 20 years ago Closed 20 years ago

"Open in new window" doesn't check for permission

Categories

(Core :: Networking, defect, P3, major)

x86
Windows 98
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: jruderman, Assigned: security-bugs)

Details

(Whiteboard: security)

No description provided.
Clicking on links from untrusted content to "file:///c|/" 
and "resource:/res/samples/test0.html" doesn't do anything, and webpages are 
also blocked from going to these urls through window.open, 
document.location.href=, and target=_blank.  If the user chooses "open in new 
window" or "save link as", however, they have no trouble getting to it.
->norris
Assignee: gagan → norris
That seems like good behavior to me--what would you like to see changed?


Aren't webpages supposed to not be able to make the browser access local 
content?  I don't think selecting "open in new window" is enough user 
intervention to bypass this, especially since (1) webpages can mess with the 
status bar and (2) there will probably be keyboard+click equivalents to 
selecting "open in new window" in the future.
Ah, this is the popup from the right mouse click (on windows at any rate).

The main reason for disallowing clicking on certain links is to avoid the
ability to access chrome: urls, which contain functions that are all-powerful.
By clicking on a link with a TARGET attribute, a malicious web site can cause a
URI to be opened in a way that allows the content to be placed in a named window
that is reachable by the malicious content.

I don't think that there's any way with "open in new window" or "save link as"
to be opened in a way that the originating page can obtain a reference to the
new window object. So I don't see a security reason for restricting this.

Make sense?
I think the "TARGET" is more general problem also.

I know of two sites that use the same target name for a window and this means
that I can't open both of them at once. (And I would like to this)
(Practical example are: http://www.formula1.com/ and http://www.f1-live.com/
live race results windows (the results and comments)).

This should not be possible (document from one site replaces content of another
site in the same window). I think that a list of TARGETs should not be browser
global.

Status: NEW → ASSIGNED
Target Milestone: --- → M18
Bulk reassigning most of norris's bugs to mstoltz.
Assignee: norris → mstoltz
Status: ASSIGNED → NEW
Security reviews and denial-of-service attacks. These will be addressed in the 
post-beta2 timeframe (unless someone's interested in tackling them earlier?)
Status: NEW → ASSIGNED
This should be XP.
Looks like the original issue is not really an issue and the issue raised by
Marko is bug 13871, so I'm marking this one INVALID.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
verif. INVALID
Status: RESOLVED → VERIFIED
This issue is being reconsidered in bug 55237.  (Btw, bug 13871 probably 
shouldn't be restricted if it contains comments from Marko.)
Err, misread mstoltz's last comments about 13871.  But if Marko mentioned the 
problem here, I still think that warrants making bug 13871 visible.
Whiteboard: security
You need to log in before you can comment on or make changes to this bug.