Closed Bug 35273 Opened 20 years ago Closed 20 years ago
"Open in new window" doesn't check for permission
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.
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.
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
Status: RESOLVED → VERIFIED
Err, misread mstoltz's last comments about 13871. But if Marko mentioned the problem here, I still think that warrants making bug 13871 visible.
You need to log in before you can comment on or make changes to this bug.