[WEB SECURITY] Attack Technique: File Download Injection

Jeff Williams jeff.williams at aspectsecurity.com
Sat Apr 12 00:54:33 EDT 2008


It's a fair point - but in my experience, most developers do use the
standard/default methods. So if they got those right, I'd be way
happier. And it's pretty easy to verify statically.

Header injection is a very good example of a problem that platform
vendors could easily stamp out. All they have to do is update their
standard/default addHeader/setHeader methods to prevent CR and LF from
ever getting into a response header. There's no downside.

As far as I'm concerned, any platform that doesn't take this simple step
is "vulnerable" and should be patched.

I'll go further. Applications that use "homegrown" security controls are
almost certainly vulnerable.  Most people know this for crypto and most
developers don't try to craft their own - although it's not as
infrequent as I'd like. But this principle should extend to
authentication, access control, input validation, canonicalization,
logging, and other security mechanisms.

I'll leave this with a shameless plug for the OWASP Enterprise Security
API (ESAPI) project at http://www.owasp.org/index.php/ESAPI (Java, .NET,
and PHP versions in the works). Every organization should provide
developers with a standard set of vetted security controls in a simple
API. If you're tired of seeing yet another broken security control, come
check it out.

--Jeff


-----Original Message-----
From: Nathanael Hoyle [mailto:nhoyle at hoyletech.com] 
Sent: Friday, April 11, 2008 1:46 PM
To: Jeff Williams; websecurity at webappsec.org
Subject: Re: [WEB SECURITY] Attack Technique: File Download Injection


This may be stating the obvious, but nothing about PHP requires one to 
use the header() functionality.  Web developers can and do on occasion 
write their own response either from scratch or with their own 
libraries.  Changes in behavior to the provided libraries are irrelevant

where they are not used and therefore no specific version of PHP or any 
other language can be termed to be 'vulnerable' or 'secure' with respect

to this type of vulnerability without some qualifier such as 'when the 
default header() implementation is used'.

-Nathanael

Jeff Williams wrote:
> Hmm... Yes, I saw the changelog that claims that this protection is in
> place. However, I've seen applications that claim to be running:
> 
>   Server: Apache/2.2.3 (Unix) mod_ssl/2.2.3 OpenSSL/0.9.8.b DAV/2
> PHP/5.1.2
> 
> That are definitely vulnerable.  I haven't had time to investigate
> further. Perhaps a PHP expert can figure out what's going on here?
> 
> --Jeff
> 
> Jeff Williams, CEO
> Aspect Security
> work: 410-707-1487
> main: 301-604-4882
> 
> 
> -----Original Message-----
> From: Michael Dreher [mailto:migg at migg.net] 
> Sent: Tuesday, April 08, 2008 4:12 AM
> To: Jeff Williams; websecurity at webappsec.org
> Subject: Re: [WEB SECURITY] Attack Technique: File Download Injection
> 
> Hi Jeff,
> 
> I would like to note that in PHP since version 4.4.2 / 5.1.2 this  
> attack technique will not work as described, because the behaviour of

> the header()-function changed to only allow a single line per  
> function call. Injecting a CRLF into the header()-function will  
> result in PHP issuing a warning:
> 
> Warning: Header may not contain more than a single header, new line  
> detected.
> 
> So it seems that PHP since these versions reached the ideal by not  
> allowing CR/LF in its header()-function. But I totally agree with  
> your opinion, that you should always verify anything coming from the  
> client before using it in your application.
> 
> 
> Best Regards,
> Michael
> 
> 
> PS: Since this is my first post on this mailing list, please do not  
> hesitate to tell me if I did something wrong. I apologize to  
> everybody if this is the case.
> 
> 
> On 07.04.2008 21:22 Jeff Williams wrote:
>> [...]
>> Susceptible header injection vulnerabilities are frequently found in
>> file download pages, but could be anywhere a web application uses
>> untrusted input in a response header. This type of vulnerability can
>> exist in virtually any web application environment, including  
>> Java, .NET
>> and PHP.
>> [...]
> 
> 
> 
> 
>
------------------------------------------------------------------------
----
> Join us on IRC: irc.freenode.net #webappsec
> 
> Have a question? Search The Web Security Mailing List Archives: 
> http://www.webappsec.org/lists/websecurity/
> 
> Subscribe via RSS: 
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
> 


----------------------------------------------------------------------------
Join us on IRC: irc.freenode.net #webappsec

Have a question? Search The Web Security Mailing List Archives: 
http://www.webappsec.org/lists/websecurity/

Subscribe via RSS: 
http://www.webappsec.org/rss/websecurity.rss [RSS Feed]



More information about the websecurity mailing list