[Owasp-leaders] Generating Passwords Hopw

Stephen de Vries stephen at twisteddelight.org
Thu Jan 22 10:14:18 EST 2009


On Jan 22, 2009, at 3:39 PM, McGovern, James F (HTSC, IT) wrote:

> My understanding is that httpOnly isn't respected in all browsers. If
> this is accurate, then can we assume that the browser crowd from OWASP
> is amplifying this concern?

Jim has already made some progress: http://manicode.blogspot.com/2008/05/httponly-crusade-update.html
(btw. httpOnly is already part of the 3.0 specification)

> In terms of validation, shouldn't the OWASP position be to deploy on  
> all
> tiers? It should be possible to define a validation component that is
> pluggable in many different layers.

It might be _deployed_ on many tiers, but it should only be _defined_  
in one (IMO).  E.g. Jboss Seam does it like this:
You define validation on your entity bean:
@NotNull
@Pattern(regex="^[a-zA-Z.-]+ [a-zA-Z.-]+", message="Need a firstname  
and a lastname")
public String getName() { return name; }

Then in your web layer, you just need to tell it that it should  
validate those values.  But you don't need to tell it how to validate  
again.
<s:validateAll> Your name:<br/> <s:decorate> <h:inputText  
value="#{person.name}"/> </s:decorate>
Even if you forget to add the validate tag in the web layer the app  
will still validate the data when it tries to persist the data (and  
throw a 'orrible error message), and this is as it should be:  
validation protects the data model, irrespective of where it's used.


>
>
> -----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: Thursday, January 22, 2009 3:44 AM
> To: jeff.williams at owasp.org; owasp-leaders at lists.owasp.org
> Subject: Re: [Owasp-leaders] Generating Passwords Hopw
>
>
> 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
>
> _______________________________________________
> OWASP-Leaders mailing list
> OWASP-Leaders at lists.owasp.org
> https://lists.owasp.org/mailman/listinfo/owasp-leaders
> ************************************************************
> 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



More information about the OWASP-Leaders mailing list