[OWASP-ESAPI] Making ESAPI HPP proof

Jim Manico jim.manico at owasp.org
Wed Aug 26 22:57:29 EDT 2009


Jeff spent an extrodinary amount of time working with the latest  
servlet specification team, and I was a Sun contractor as a Java  
engineer for many years in the past. Suffice to say, I'm not holding  
my breath and will never write a Java program without ESAPI, so help  
me Gosling and Boynton.

Jim Manico

On Aug 26, 2009, at 9:02 AM, "Neil Matatall" <nmatatal at uci.edu> wrote:

>> 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
>>
>>
>
>
> _______________________________________________
> 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