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

Jeff Williams jeff.williams at owasp.org
Mon Jan 24 22:39:19 EST 2011

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


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/20110124/3bc0a749/attachment.html 

More information about the Esapi-user mailing list