Thanks for the report, but this is working as intended. If a site treats the absence of a referer or origin header as indicating trust, then the site has a vulnerability.

yes, I know that it's working as intended. But the thing is that "intended" way of work is a little bit weird. Lots of websites rely on empty referer/orig(image hostings are good example). 

Surely it's a vulnerability for them but a tiny percent of user agents don't send it - those sites got to take 'bad agents' into account so should we blame them for accepting an empty referer? they do their best to not lose % of traffic. due to weird behavior of about:blank it turns into CSRF.

anyway, according http://msdn.microsoft.com/en-us/library/cc848897(v=vs.85).aspx data: shouldn't work for populating iframes. 

P.S. btw if it works as intended *why* src=javascript:... *sends* proper origin but data: iframe doesn't ? It looks like work around inside of webkit, doesn't it?

It's always trivially possible to block the referer, which is why it's absence is never a security indicator. Any discussion about relying on it as such is a waste of time.

As for the line you cited in Microsoft's documentation, it's solely in the context of their partial implementation of data URLs, without any explanation or justification for the claim. It's not part of any relevant standard, and has no bearing on other implementations of data URLs. So, it's a mistake to interpret it as anything more than Microsoft's position on their own implementation.

>It's always trivially possible to block the referer
agreed with this point, closed.

>Microsoft's position on their own implementation.
agreed. but if you approve data protocol to be legit for frames population - I see no profit in "html5" srcdoc attrbiute, by the way.

slight notice - openDatabase and WebSQL works on about:blank but cookies/localStorage etc don't, probably webkit forgot to deny access to websql..

If you think there's a bug in some other feature please file a separate issue. If it is a WebKit issue and not specific to Chrome, please file it at bugs.webkit.org.

Adam, any thoughts on whether any Origin guarantee is being bypassed? I'm surprised to see it blank.

There's nothing going wrong. Data URLs in WebKit have never inherited the origin of the containing document. I don't remember exactly why, but there are quirks in WebKit's data URL implementation that make this restriction necessary.

Oh, that's right. data: URLs in WebKit have a resolutely unique origin (a security measure in and of itself that has avoided us some problems).

Any web app that confers any sort of permission based on a blank Origin: would be very buggy.

Sorry for the noise.

My fault. I should have noted the data URL behavior in an earlier reply. It's just that data URL implementations currently vary quite a bit between the different browsers, so it gets really messy to speak about their security attributes in any general sense.

>My fault. I should have noted the data URL behavior in an earlier reply. It's just that data URL implementations currently vary quite a bit between the different browsers, so it gets really messy to speak about their security attributes in any general sense.

absolutely! honestly Origin thing is not a security issue, anyway. But with referer in MY humble opinion is. Referer is wide spreaded and developers(low skilled OK) use it and this trick is only trick for http:// page I know to omit it. So I thought when I created this ticket that you can fix it somehow because no compatibility issues involved, thanks.

@homakov - There really is nothing to fix on that front. A web app is fundamentally broken if it trusts the absence of the referer header to indicate a request is not a CSRF. It's an inherently unsafe assumption.

See the Browser Security Handbook, https://code.google.com/p/browsersec/wiki/Part1

In particular, "Is Referer header sent on pseudo-protocol → HTTP navigation?"

You can also cause empty referers by various other documented techniques, such as bouncing through FTP or arranging for the evil POST to come from https://

Also, I think something like ~1% of internet users are behind a special http proxy that _strips_ referers in the name of privacy.

Any web site granting privileges based on empty referer is broken, unfortunately.

Thank you, you both share my opinion too. So I just made sure that there is nothing unexpected in those cases and people shouldn't rely/support clients that don't send those Headers; I appreciate your help.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Bulk release of old security bug reports.

Bulk update: removing view restriction from closed bugs.