WebApp Sec mailing list archives
RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash"
From: "Amit Klein (AKsecurity)" <aksecurity () hotpop com>
Date: Thu, 27 Jul 2006 21:28:07 +0200
Thanks for your response and clarification. Perhaps I'm missing something, but I do not see how this particular vehicle of attack changes the original known threat. Are you implying that the user (whose browser renders the malicious flash unknowingly) is open to new risks by this mechanism? As I understood your original report, the threat was on the web application itself (and thus your comment about how they shouldn't rely on the inviolability of the HTTP headers), and if so, it is just the same threat as
I mentioned before.
OK, let me try to provide a concrete example. The 2 CSRF texts I referenced: http://www.zope.org/Members/jim/ZopeSecurity/ClientSideTrojan http://www.tux.org/~peterw/csrf.txt They both introduce the problem commonly known now as CSRF. They both suggest using Referer as a protection mechanism. What is CSRF? in a nutshell, it's the ability of an attacker to force the client's browser to send requests to a 3rd part site. Using Referer to prevent it is a simple (and now known to be flawed) idea as following: since the attacker forces the client's browser to send those (unwanted) requests, the site owner can look at the Referer header. This URL should have a host part identical to the host of the site itself (OK, there are some real-life problems here, sich as deep-linking, Referer-removal, etc., but let's assume a naïve world for a moment). Now, if you look at the browser and its inherent capabilities (HTML+JS), there's almost no way of forging a Referer header. That is, the attacker cannot force the browser to send a Referer to a 3rd party site within HTML+JS (OK - here too there are exceptions, but let's again stick to the mainstream). The browser will either send no Referer, or the URL of the attacker's website. It will not send the "expected" Referer whose URL has the host of the website in question. That's why relying on the Referer for this kind of protection was considered by many people to be reasonable. In fact, some servers and applications do use Referer for this purpose (and for other purposes, I suppose).
I'm not trying to challenge your argument, I'm just trying to understand it better, as I may be understanding it.
Hope that helps...
In any case, your findings are certainly interesting, and something that should be addressed not only by browser implementors, but by Adobe on its Flash framework (and of course, by web developers, but I take that as a given).
Thanks :-) -Amit ------------------------------------------------------------------------- Sponsored by: Watchfire AppScan 6.5 is now available! New features for Web Services Testing, Advanced Automated Capabilities for Penetration Testers, PCI Compliance Reporting, Token Analysis, Authentication testing, Automated JavaScript execution and much more. Download a Free Trial of AppScan today! https://www.watchfire.com/securearea/appscancamp.aspx?id=70150000000CYkc -------------------------------------------------------------------------
Current thread:
- Write-up by Amit Klein: "Forging HTTP request headers with Flash" Amit Klein (AKsecurity) (Jul 24)
- ERRATA (Re: Write-up by Amit Klein: "Forging HTTP request headers with Flash") Amit Klein (AKsecurity) (Jul 26)
- RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash" James Pujals (Jul 27)
- RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash" Amit Klein (AKsecurity) (Jul 27)
- RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash" James Pujals (Jul 27)
- RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash" Amit Klein (AKsecurity) (Jul 27)
- RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash" Amit Klein (AKsecurity) (Jul 27)