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

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

On 27 Jul 2006 at 11:28, James Pujals wrote:

> Hello:
>    
> > > "In other words, the implicit assumption made by many software
> developers (and probably also by many security researchers) that
> most HTTP headers cannot be forced to have arbitrary values by an
> attacker who serves data to the victim browser is shown to be in
> error in this write-up."
>
> I wasn't aware that there was such implicit assumption.  As I understood it, it is well known that all HTTP headers 
> are created by the client, at its discretion, and that it is trivial to tamper with them, or to implement a custom 
> user-agent that posts arbitrary headers in its HTTP requests.
It's trivial for the attacker to forge any HTTP request header when the attacker is in 
DIRECT contact with the web server. And I think that's what you refer to, as well as the 
OWASP text you quoted. 

But the picture was considered to be significantly different when the attacker was NOT in
direct contact with the server. That is, the attacker is able to serve malicious HTML 
content to the victim, who uses a browser. In such scenario, the attacker is limited to 
whatever the victim's browser can do across domains. And that's very limited (well, unless
you throw in Flash...). Sure, you can send requests to URLs with any parameters (and that's 
quite interesting in itself, see today's message - 
http://www.webappsec.org/lists/websecurity/archive/2006-07/msg00086.html), but until this 
week, there was no control over the HTTP request headers that are sent across domain (well, 
you could inject data into some parts of the Referer header - not the entire host though, 
and you could control part of the host header, but not much beyond that). This browser 
limitation is what I meant when I wrote "implicit assumption". 

I hope that clarifies my statements.

Thanks,
-Amit

> I agree that relying on the HTTP headers on web applications is not a very good idea, but I don't think this is new, 
> and in fact its even specified in the OWASP Guide, in the section on threat risk modeling:
>
> "Tampering with data - Users can change any data delivered to them, and can thus change client-side validation, GET 
> and POST data, cookies, HTTP headers, and so on."
>
>      -dZ.

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