[Esapi-user] [Esapi-dev] Response Splitting

Jim Manico jim.manico at owasp.org
Mon Jan 24 23:50:08 EST 2011


Wrappers are good, Jeff. But there are some shops who cannot afford the latency overhead of so many (essentially) filtered layers. Also, this is a fairly invasive operation (validation of all input and output in a non-contextual way). Why waste validating all the headers generically when of course you also validate all input contextually in a whitelist way? This double-validation is a performance killer for some apps. There may be other unintended side effects. Or maybe your boss just wont let you use that code, like when you are part of a real SDLC where every change needs to be carefully vetted. These request/response filters have broken several apps in the past from personal experience that I and other ESAPI implementors have run into.

So. When the wrappers are not possible for you, a more surgical solution is needed. (side note, ESAPI modularization will be a big hit).

-Jim Manico
http://manico.net

On Jan 24, 2011, at 7:39 PM, "Jeff Williams" <jeff.williams at owasp.org> wrote:

> There are really three things we can do with input to make it safe:
> 
> 1)      Validate – this checks the data, generates warnings, and detect attacks (but does not change the data)
> 
> 2)      Sanitize – this actually changes the data to make it safe
> 
> 3)      Encode – this transforms the data to be safe in a particular output context
> 
>  
> 
> I always recommend using both validation AND encoding. Validation will stop many attacks, but cannot stop them all.  Encoding focuses on stopping injection, which covers many but not all attacks.  I don’t use sanitization very often, but there are applications where it makes sense.
> 
>  
> 
> You might try StringUtilities.stripControls.  It replaces unprintables with a SP, as suggested by the HTTP specification.
> 
>  
> 
> I do like the automatic fix in aspect of the SafeResponseWrapper.  Jim can you clarify exactly when wrappers don’t work?
> 
>  
> 
> --Jeff
> 
>  
> 
> From: esapi-dev-bounces at lists.owasp.org [mailto:esapi-dev-bounces at lists.owasp.org] On Behalf Of Sean Malone
> Sent: Monday, January 24, 2011 1:55 PM
> To: Jim Manico
> Cc: ESAPI-Developers; ESAPI Users List
> Subject: Re: [Esapi-dev] Response Splitting
> 
>  
> 
> I agree; both of those would be useful to have.  I would especially appreciate having the Header Encoder to recommend for vulnerability remediation in existing code.
> 
>  
> 
> Regards,
> 
>  
> 
> Sean
> 
>  
> 
> On Mon, Jan 24, 2011 at 9:35 AM, Jim Manico <jim.manico at owasp.org> wrote:
> 
> I think we need a better strategy for response splitting defense.
> 
> Right now, the only advice we give is to use the Request/Response
> wrappers, a defense that is not practical for all shops.
> 
> I think we need 2 approaches:
> 
> 1) Input Validation function that specifically strips linefeed line
> control characters after cannonicalization
> 2) Header Encoder that renders linefeed control characters innert (the
> best defense is always at the usage boundary)
> 
> Thoughts?
> 
> - Jim
> _______________________________________________
> Esapi-dev mailing list
> Esapi-dev at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/esapi-dev
> 
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20110124/36844f29/attachment.html 


More information about the Esapi-user mailing list