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

Issue metadata

Status: WontFix
Owner:
User never visited
Closed: Apr 2012
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug-Security

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Security: Referrer And Origin issue

Reported by homakov@gmail.com, Apr 27 2012 Back to list

Issue description

VULNERABILITY DETAILS

http://homakov.blogspot.com/2012/04/playing-with-referer-origin-disquscom.html

allows to execute code with empty referer and origin

REPRODUCTION CASE
The code is shown in the post. Empty referer allows csrf attacks for some services and/or loading external resources(hot linked) e.g. images.

The case with empty origin is weird - I thought origin is Always attached by design of Webkit and related to Tab. But it doesn't for data: protocol - please check.

+ how do you think about denying data: protocol for iframes(quote from  http://msdn.microsoft.com/en-us/library/cc848897(v=vs.85).aspx  in the post)


 

Comment 1 by jsc...@chromium.org, Apr 27 2012

Status: WontFix
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.

Comment 2 by homakov@gmail.com, Apr 27 2012

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?

Comment 3 by jsc...@chromium.org, Apr 27 2012

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.

Comment 4 by homakov@gmail.com, Apr 27 2012

>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..

Comment 5 by jsc...@chromium.org, Apr 27 2012

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.
Owner: abarth@chromium.org
Adam, any thoughts on whether any Origin guarantee is being bypassed? I'm surprised to see it blank.

Comment 7 by jsc...@chromium.org, Apr 29 2012

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.

Comment 9 by jsc...@chromium.org, Apr 29 2012

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.

Comment 10 by homakov@gmail.com, Apr 29 2012

>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.

Comment 13 by homakov@gmail.com, Apr 30 2012

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.
Project Member

Comment 14 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 15 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security Type-Bug-Security
Project Member

Comment 16 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-Undefined
Project Member

Comment 17 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Labels: -Restrict-View-SecurityTeam
Bulk release of old security bug reports.

Project Member

Comment 19 by ClusterFuzz, Feb 6 2014

Labels: -Restrict-View-EditIssue
Bulk update: removing view restriction from closed bugs.
Labels: allpublic

Sign in to add a comment