Launchpad itself

Bug #560246
Comment #29

Comment 29 for bug 560246

Revision history for this message

David Wagner (daw-bugzilla) wrote on 2012-09-15:

#29

I recently learned some additional information that may be of some modest utility in evaluating how much we should rely upon the unforgeability of Referer headers.

In April 2010, one developer wrote "The only browser-related ways of forging REFERER headers I found appeared to be pertinent to older versions of software; and HTTP, not HTTPS."

My response was that I may not know of a specific attack, but "there have been numerous [Referer-forgery attacks] in the past as well (e.g., Flash-based attacks), some of which may still be pertinent today, and I fully expect other attacks may well exist, too, even if we are not aware of them."

I recently learned of a new vulnerability that was not publicly disclosed at the time, but has since been revealed. Even as one developer wrote in April 2010 that he believed Launchpad's reliance upon Referer headers to be safe, there was an extant vulnerability in Flash that allowed forgery of request headers. If I'm understanding things correctly, this would appear to allow forgery of arbitrary custom headers, even for POST requests (I wasn't able to find any mention about HTTP vs HTTPS). The vulnerability was not publicly reported until almost a year later. The vulnerability has since been fixed, so if users are running a fully patched version of Flash, the vulnerability should not be exploitable any longer. Nonetheless it means that, even though we didn't know it at the time, there apparently was a vulnerability that allowed forgery of request headers at the time that one developer was expressing confidence that this couldn't happen.

References: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html

(Yes, this was in Flash. But many users do use Flash, and the site presumably needs to be secure for them, too.)

Someone else wrote "Redirects are not a problem. They can only result in GET requests". While at the time I believed this statement, my belief appears to have been mistaken; the vulnerability listed above apparently involved POST requests and redirects.

Of course, all of that history now, water under the bridge. But it may be relevant to an assessment of the likelihood of other such vulnerabilities being found in the future. When there have been two or three or four bugs of a certain type found so far, it is natural to suspect that there could be one more that we don't know about yet, just waiting to be found. Historically, confidence in the Referer header has been mis-placed. I don't know whether there's a solid basis for believing we've seen the last of such vulnerabilities. I leave it to you to form your own opinion about the implications of this past history.

I recently learned some additional information that may be of some modest utility in evaluating how much we should rely upon the unforgeability of Referer headers.

In April 2010, one developer wrote "The only browser-related ways of forging REFERER headers I found appeared to be pertinent to older versions of software; and HTTP, not HTTPS."

I recently learned of a new vulnerability that was not publicly disclosed at the time, but has since been revealed.  Even as one developer wrote in April 2010 that he believed Launchpad's reliance upon Referer headers to be safe, there was an extant vulnerability in Flash that allowed forgery of request headers.  If I'm understanding things correctly, this would appear to allow forgery of arbitrary custom headers, even for POST requests (I wasn't able to find any mention about HTTP vs HTTPS).  The vulnerability was not publicly reported until almost a year later.  The vulnerability has since been fixed, so if users are running a fully patched version of Flash, the vulnerability should not be exploitable any longer.  Nonetheless it means that, even though we didn't know it at the time, there apparently was a vulnerability that allowed forgery of request headers at the time that one developer was expressing confidence that this couldn't happen.

References: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html

(Yes, this was in Flash.  But many users do use Flash, and the site presumably needs to be secure for them, too.)

Someone else wrote "Redirects are not a problem. They can only result in GET requests".  While at the time I believed this statement, my belief appears to have been mistaken; the vulnerability listed above apparently involved POST requests and redirects.

Of course, all of that history now, water under the bridge.  But it may be relevant to an assessment of the likelihood of other such vulnerabilities being found in the future.  When there have been two or three or four bugs of a certain type found so far, it is natural to suspect that there could be one more that we don't know about yet, just waiting to be found.  Historically, confidence in the Referer header has been mis-placed.  I don't know whether there's a solid basis for believing we've seen the last of such vulnerabilities.  I leave it to you to form your own opinion about the implications of this past history.