[Owasp-leaders] Generating Passwords Hopw

Stephen de Vries stephen at twisteddelight.org
Fri Jan 23 04:35:37 EST 2009


On Jan 23, 2009, at 10:10 AM, Jim Manico wrote:
>
> I feel that what Jeff did in talking to the Servlet team is one of  
> the most powerful ways we can spend time as OWASP - convincing the  
> next generation of frameworks to include "baked in" security  
> measures that address the OWASP Top 10 and the like in ways that  
> make it easier for developers to get it right!

Jim,

I have the greatest respect for the work that both you and Jeff have  
done in getting these security controls baked in to the servlet spec.   
It's one thing to sit in one's underwear typing speculative emails  
about what should be done, and quite another to actually get involved  
with real-world projects and make change happen!  I hope my  
knitpicking is seen in this context :)

Stephen

> -- 
> Jim Manico, Senior Application Security Engineer
> jim.manico at aspectsecurity.com
> (301) 604-4882 (work)
> (808) 652-3805 (cell)
>
> Aspect Security
> Securing your applications at the source
> http://www.aspectsecurity.com
>
> From: owasp-leaders-bounces at lists.owasp.org on behalf of Jeff Williams
> Sent: Wed 1/21/2009 8:28 PM
> To: owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Generating Passwords Hopw
>
> Hi Stephen,
>
> I'm pretty surprised by your response. The Servlet spec is a  
> framework of
> sorts actually. I think figuring out what level(s) to focus on is a  
> good
> discussion for the leaders list. 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.
>
> --Jeff
>
>
> -----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
>
> _______________________________________________
> 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