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

Status: VERIFIED INVALID

(Core :: Networking, defect, P3)

Comment 1

[Jesse Ruderman]

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.

Comment 2

[Gagan]

->norris

Comment 3

[Norris Boyd]

That seems like good behavior to me--what would you like to see changed?

Comment 4

[Jesse Ruderman]

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.

Comment 5

[Norris Boyd]

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?

Comment 6

[Marko Macek]

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.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Bulk reassigning most of norris's bugs to mstoltz.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

Security reviews and denial-of-service attacks. These will be addressed in the 
post-beta2 timeframe (unless someone's interested in tackling them earlier?)

Comment 9

[Marko Macek]

This should be XP.

Comment 10

[Mitchell Stoltz (not reading bugmail)]

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.

Comment 11

[Tom Everingham]

verif. INVALID

Comment 12

[Jesse Ruderman]

This issue is being reconsidered in bug 55237.  (Btw, bug 13871 probably 
shouldn't be restricted if it contains comments from Marko.)

Comment 13

[Jesse Ruderman]

Err, misread mstoltz's last comments about 13871.  But if Marko mentioned the 
problem here, I still think that warrants making bug 13871 visible.