[OWASP-ESAPI] Suggestions for the Java Servlet Spec

Jeff Williams jeff.williams at owasp.org
Thu Aug 27 13:38:14 EDT 2009


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/c6286d6f/attachment.html 


More information about the OWASP-ESAPI mailing list