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

Jeff Williams jeff.williams at owasp.org
Tue Jan 25 21:57:09 EST 2011

My testing on millions of requests under load doesn’t show any performance issues with a wrapper that overloads the setHeader() and addHeader() response methods.  I believe that the right place to defend against header injection is right at the point when data is put into headers, and that the wrapper is an elegant solution that requires no other code changes.


I can’t figure out what your point is with regard to validation.  I never suggested that validation should be either “generic” or “context-sensitive” as you call them.  That choice depends on the application.  I also never suggested double-validation.  However, my testing suggests that your “performance killer” claim for double-validation unfounded.


Ahh wait – you’re talking about specifically using ESAPIFilter/SafeRequest/SafeResponse, aren’t you?  I’m suggesting the use of targeted wrappers to prevent header injection.  I do believe that the ESAPIFilter has caused issues since it does everything.  But I see no problem with the idea of ResponseWrappers in general.





From: Jim Manico [mailto:jim.manico at owasp.org] 
Sent: Monday, January 24, 2011 11:50 PM
To: Jeff Williams
Cc: Sean Malone; ESAPI-Developers; ESAPI Users List
Subject: Re: [Esapi-dev] Response Splitting


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


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?




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.






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)


- Jim
Esapi-dev mailing list
Esapi-dev at lists.owasp.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20110125/b3d1c1e1/attachment.html 

More information about the Esapi-user mailing list