[OWASP-ESAPI] Suggestions for the Java Servlet Spec

Neil Matatall nmatatal at uci.edu
Thu Aug 27 14:21:05 EDT 2009


Jeff,

This is something I'm certainly interested in.  However, I'll be busy 
for a while.

> For example, to my surprise they pushed back very hard on number 1. 
> Even with extensive explanations about the evils of header injection. 
I haven't followed up on this, but the last time I checked the Apache 
group still refuses to allow a mechanism to change web server banners 
(eg Apache 2.1 running php 5, mod_jk 2.1) because they felt it didn't 
add any security. I beg to differ...although yes, a determined hacker 
would only be moderately slowed down. 

Neil

Jeff Williams wrote:
>
> Hi,
>
>  
>
> Over a year ago, I started having discussions with the Sun Servlet 
> Spec team.  I decided to pick a few key issues that were simple to fix 
> and significant from a security perspective.  Here's what I chose.
>
>  
>
> 1)      Disallow CR and LF in all HTTP headers
>
> 2)      Disallow unlisted http-methods in security-constraints
>
> 3)      Provide support for a cross-site request forgery (CSRF) token
>
> 4)      Enable HttpOnly flag on JSESSIONID
>
> 5)      Remove URL Session rewriting support
>
> 6)      Provide a full set of escaping methods for HTML
>
>  
>
> I spent a lot of time with them via emails and teleconferences. For 
> example, to my surprise they pushed back very hard on number 1. Even 
> with extensive explanations about the evils of header injection.  They 
> suggested there would be a performance impact.  I set up a test 
> framework to see and found that the impact is not detectable and even 
> might make things faster. Even showing them the spec saying characters 
> < 0x20 should not be allowed wasn't enough. That's just one example.
>
>  
>
> So, while I would love to see more security by default in Java EE, I 
> think we're going to need additional libraries for a quite a long 
> time. I don't blame the Servlet team for this, they have lots of 
> competing concerns and there is not widespread consensus on exactly 
> how to deal with all of these problems.
>
>  
>
> At this point, I'm not sure where these items ended up, although I did 
> see that HttpOnly support did make it into Servlet 3.0. Anyone willing 
> to get a Servlet 3.0 implementation (glassfish?) and test whether any 
> of these things are implemented right?  Then I think we should put 
> together another list and present them to the team again.
>
>  
>
> --Jeff
>
>  
>
>  
>
> > -----Original Message-----
>
> > From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-
>
> > bounces at lists.owasp.org] On Behalf Of Jim Manico
>
> > Sent: Wednesday, August 26, 2009 10:57 PM
>
> > To: Neil Matatall
>
> > Cc: owasp-esapi at lists.owasp.org
>
> > Subject: Re: [OWASP-ESAPI] Making ESAPI HPP proof
>
> >
>
> > 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
>
> > _______________________________________________
>
> > 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/20090827/4eb7afc6/attachment-0001.html 


More information about the OWASP-ESAPI mailing list