[OWASP-ESAPI] Making ESAPI HPP proof

Neil Matatall nmatatal at uci.edu
Wed Aug 26 09:02:35 EDT 2009


>E.g., for Java, it should get pushed back to the Java Servlet container
and API spec.

Yay!  That was always one of the goals for ESAPI.  Are there any other
cases of ideas being adopted by their respective processes?  http-only?

Neil


> lavakumar kuppan wrote:
>> Hi All,
>>
>> Extending on what Jim had mentioned in his earlier mail I have a
>> proposal
>> for ESAPI Java and .NET.
>> To provide anti-HPP(HTTP Parameter Pollution) support to ESAPI.
>> HTTP Parameter Pollution depends on multiple request parameters having
>> the
>> same name.
>>
>> Its effect varies based on the platform:
>> 1) Java:
>>     Override other parameters and subsequently application logic
>>     Refer slides 20,21,23,24 on
>> http://www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf
>> 2) .NET:
>>     Bypass Web Application firewalls
>>     Refer http://lavakumar.com/modsecurity_hpp.txt
>>     http://lavakumar.com/Split_and_Join.pdf
>>
>> Multiple parameters of the same name is supported by the web platform to
>> accept multi-select input lists.
>> But this feature is always turned on and even when a particular
>> parameter is
>> not using a 'multi-select input list' the web technology always treats
>> it as
>> one.
>> This 'enabled by default' approach open up possibilities for abuse like
>> the
>> ones listed above.
>
> While certainly we can and possibly even should handle this in ESAPI, I
> think the probably place to handle this is to push the problem back
> upstream.
> E.g., for Java, it should get pushed back to the Java Servlet container
> and API spec. Made them aware of it and require that they specify some
> correct and safe behavior rather than leaving to to those developing
> Java servlet containers and J2EE apps, etc. Anyone know if this is being
> done or have any contacts in that space?
>
> I would think a similar thing could be done in the .NET space.
>
> -kevin
>
> --
> Kevin W. Wall
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME
> _______________________________________________
> OWASP-ESAPI mailing list
> OWASP-ESAPI at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>




More information about the OWASP-ESAPI mailing list