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

Jim Manico jim.manico at owasp.org
Wed Jan 26 15:27:45 EST 2011


Jeff,

I see that you are indeed using validation to stop HTTP/RS (which is
basically a form of injection). This is a form of "boundary defense"
that again, I think is *good* in most situations. Key words: good and most.

But what about a function that prevents HTTP/RS via encoding or
(preferably) sanitation? Is there value in that to you?

I like the sanitation route because when locating places in code where
untrusted data is placed into a header, I can just add a nice simple
sanitation function, and without effecting the work-flow or
configuration of the app, woosh, I get protection a the boundary of
vulnerability (ie: right where the dev adds data into a header).

Is this perfect? No. Is this a solid option? Fo sure.

*** Here is the current ESAPI solution for header injection HTTP/RS
projection, btw.

    public void addHeader(HttpServletResponse response, String name,
String value) {
        try {
            String strippedName =
StringUtilities.replaceLinearWhiteSpace(name);
            String strippedValue =
StringUtilities.replaceLinearWhiteSpace(value);
            String safeName =
ESAPI.validator().getValidInput("addHeader", strippedName,
"HTTPHeaderName", 20, false);
            String safeValue =
ESAPI.validator().getValidInput("addHeader", strippedValue,
"HTTPHeaderValue", 500, false);
            response.addHeader(safeName, safeValue);
        } catch (ValidationException e) {
            logger.warning(Logger.SECURITY_FAILURE, "Attempt to add
invalid header denied", e);
        }
    }


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



More information about the Esapi-user mailing list