RE: Write-up by Amit Klein: "Forging HTTP request headers with Flash"

["Amit Klein (AKsecurity)" <aksecurity () hotpop com>]

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