[OWASP-ESAPI] Making ESAPI HPP proof

lavakumar kuppan lavakumar.in at gmail.com
Wed Aug 26 09:55:27 EDT 2009


You are right. That would be the right place for it to be.
Though I dont know if this has been taken up with them, what I can guess is
that they would be in no big hurry to implement it, especially since these
are heavily used functions/properties.

ESAPI is the right place where the effects of doing something like this can
be checked and then moved up to the platform itself, where it belongs.

Ideally a lot of features from the SafeRequest and HttpUtilities classes
should be part of the framework itself I think. But they are not.

Cheers,
Lava
http://www.lavakumar.com


On Wed, Aug 26, 2009 at 6:32 PM, 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
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-esapi/attachments/20090826/76828778/attachment-0001.html 


More information about the OWASP-ESAPI mailing list