[Owasp-leaders] Generating Passwords Hopw

Stephen de Vries stephen at twisteddelight.org
Thu Jan 22 03:44:09 EST 2009


On Jan 22, 2009, at 3:28 AM, Jeff Williams wrote:

> The details below we can take to the Java
> list if you want to go into more detail there.
>
> Here are the items I've been working  on. Let me know if you think  
> these
> should be in Servlet or in a framework.
>
> 1) Disallow CR and LF in all HTTP headers. This will stop all
> response-splitting/tunneling and file download injection attacks.
>
> 2) Disallow unlisted http-methods in security-constraints. This  
> prevents the
> bypass of authentication and access control by using verbs like  
> HEAD, JEFF,
> etc...
>
> 3) Provide support for a cross-site request forgery (CSRF) token.  
> Would
> require a token for any pages with a security-constraint in web.xml.
>
> 4) Enable HttpOnly flag on JSESSIONID. To prevent one bad  
> consequence of
> XSS.
>
> 5) Add a security note to 7.1.3 URL Rewriting. Originally I wanted  
> this
> removed, but they said no way. This method  
> puts ;jessionid=9823429347 on the
> URL.
>
> 6) Encoding/escaping support. To make it easy to properly escape  
> data for
> the appropriate HTML context.

The two biggest issues that sprang to mind when I was thinking about  
"security in servlets" was XSS and XSRF.  But given your specific  
examples above, I'd agree that all of the above, except 3 should be in  
the servlet spec.  Utilities for escaping html should of course be  
provided in servlets, but I think the vast majority of developers  
would be using a web framework instead of servlets directly.   
Targeting tag libraries that still don't encode html characters by  
default would be a big win against XSS imo.

Maybe my objections are a bit too academic, but I think we should  
match security controls to the appropriate application layer.  E.g. I  
still don't believe that putting validation in the web layer is a good  
idea, it should go in the data tier (because validation is about the  
data) and be propagated up to the web tier.  So similarly WRT the  
servlet spec, since it is such a basic building block that can be used  
to build all sorts of HTTP applications (such as some that don't use  
sessions, or use the jsessionid for something other than managing a  
session) - it's appropriate to include controls that apply at the  
basic HTTP layer.

I'm having a house built at the moment, and this situation is similar  
to insulation required in walls.  By law, houses must have a minimum  
level of insulation in the walls.  But this doesn't mean that brick  
manufacturers have to build bricks with built in insulation - it means  
that the architects have to design in external or internal insulation  
for the completed wall.

Stephen


>
>
> -----Original Message-----
> From: owasp-leaders-bounces at lists.owasp.org
> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Stephen  
> de Vries
> Sent: Wednesday, January 21, 2009 10:33 AM
> To: owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Generating Passwords Hopw
>
>
> I think trying to get web security issues addressed in the servlet
> spec is aiming at too low a level.  You might have better luck with
> web frameworks projects instead.  Similarly with Ruby, the language
> itself is too low level, but getting security features added to the
> Rails framework might be more feasible.
>
>
> On Jan 21, 2009, at 3:58 PM, McGovern, James F (HTSC, IT) wrote:
>
>> Is there merit in doing the same type of activity with the Ruby
>> community?
>>
>> -----Original Message-----
>> From: owasp-leaders-bounces at lists.owasp.org
>> [mailto:owasp-leaders-bounces at lists.owasp.org] On Behalf Of Jeff
>> Williams
>> Sent: Tuesday, January 20, 2009 11:39 PM
>> To: owasp-leaders at lists.owasp.org
>> Subject: Re: [Owasp-leaders] Generating Passwords Hopw
>>
>> Hi,
>>
>> I have been working with Sun and the rest of the Servlet team to get
>> some better security into the Java Servlet 3.0 specification for the
>> last year or so. While it has been interesting and somewhat
>> productive,
>> it is *extremely* difficult to get them to acknowledge the idea that
>> their APIs need to change for security. I heard every excuse you can
>> think of (compatibility, performance, usability, complexity,  
>> insanity,
>> etc...). Anyway, while I think the goal is good, I'm not optimistic
>> about the prospects for just "providing feedback."  I'm leaning
>> towards
>> the ESAPI approach of providing safe wrappers or replacements for
>> unsafe
>> methods.
>>
>> --Jeff
>> ************************************************************
>> This communication, including attachments, is for the exclusive use
>> of addressee and may contain proprietary, confidential and/or
>> privileged information.  If you are not the intended recipient, any
>> use, copying, disclosure, dissemination or distribution is strictly
>> prohibited.  If you are not the intended recipient, please notify
>> the sender immediately by return e-mail, delete this communication
>> and destroy all copies.
>> ************************************************************
>>
>> _______________________________________________
>> OWASP-Leaders mailing list
>> OWASP-Leaders at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders



More information about the OWASP-Leaders mailing list