[Esapi-user] [SC-L] Recommending ESAPI?

Jim Manico jim.manico at owasp.org
Mon Jan 11 18:22:24 EST 2010


Impressive, James.This is good information - someone needs to convert
this into a case study! :)

Thanks for using ESAPI - we love to hear about what works - and what
does NOT work so we can make it better.

Aloha,
Jim

> I wouldn't say we are enlightened, merely looking for the cheapest way
> to make reports clean. While we leverage static analysis, it hasn't
> been adopted by all of our applications. We have gotten more serious
> about doing web vulnerability scanning before applications are
> released to production and therefore developers are incentivized to
> make sure that all scans come up clean. They have figured out that
> ESAPI is a lot faster method for accomplishing this goal over using
> static analysis.
>  
> We have had to wrap not just because of security/isolation procedures,
> but because we had to do some workarounds to support various versions
> of the JDK we have floating around. ESAPI has been really good at
> reducing the thousands of errors we would find via scan down to
> something a developer can address quickly.
>  
> Of course, we believe that things such as input validation are design
> issues that shouldn't be remediated solely via ESAPI, we do however
> acknowledge that our velocity of remediating using static analysis
> isn't quite what we hoped. The numbers are larger than most vendors
> ever talk about in public settings.
>
> ------------------------------------------------------------------------
> *From:* Jim Manico [mailto:jim at manico.net]
> *Sent:* Monday, January 11, 2010 1:43 PM
> *To:* McGovern, James F. (eBusiness); ESAPI-Developers;
> esapi-user at lists.owasp.org
> *Subject:* Re: [SC-L] [Esapi-user] Recommending ESAPI?
>
> James,
>
> Please don't take my comments wrong - I love ESAPI! In my projects, I
> hard code ESAPI directly into my apps. In other large projects where
> ESAPI is being added late in the game, I'm seeing it wrapped around
> existing security libraries.
>
> So you are using ESAPI directly in your code? That means you're
> enlightened. Good job. :) I would hate to see folks re-write all these
> great controls from scratch. It's an epic waste of time and money.
>
> If you can share, I'd love to hear HOW you are using ESAPI in more
> detail.
>
> Compared to projects of similar complexity (like say, Hibernate) ESAPI
> has a ways to go. But I've used almost every aspect of ESAPI with
> great success.
>
> - Jim
>
> PS:  And frankly, wrapping ANY 3rd party library is good practice.
> Easier said than done.
>
>> FYI. My company uses ESAPI in several of their Internet-facing
>> applications, so you can say you know of at least one :-)
>>
>> ------------------------------------------------------------------------
>> *From:* sc-l-bounces at securecoding.org
>> [mailto:sc-l-bounces at securecoding.org] *On Behalf Of *Jim Manico
>> *Sent:* Sunday, January 10, 2010 2:46 PM
>> *To:* Stephen de Vries
>> *Cc:* esapi-user at lists.owasp.org; Secure Code Mailing List
>> *Subject:* Re: [SC-L] [Esapi-user] Recommending ESAPI?
>>
>> Stephen,
>>
>> I think this is very important and sage advice.
>>
>> Philosophically, we do not want to bring developers to ESAPI, we want
>> to bring ESAPI to developers. And that means working with where THEY
>> are at and moving form there.
>>
>> I have not seen a large company use ESAPI directly in their code
>> (although others may have). Due to the maturity level of ESAPI, I
>> recommend that companies integrate ESAPI into their own corporate
>> library to fill in the gaps (wrap it!). Everyone has a different
>> nomenclature for function names, and I'm a fan of calling
>> ESAPI.encodeForHTML() instead of ESAPI.encoder().encodeForHTML()
>> which is what every "wrapper" has done so far,  from what I've seen.
>>
>> >  For the overlapping functions, I think that existing frameworks
>> already do an acceptable job of _*providing authentication*_
>>
>> I agree 100%. I do not see a big use case for ESAPI authentication in
>> most large organizations - they usually have something like SSO or at
>> least standard auth in place already. We need more maturity in this area.
>> _*
>> > , access control,*_
>>
>> I think most frameworks get this wrong - in particular, I feel role
>> based access control is basically a design (or even security)
>> anti-pattern - and we need to move towards contextual/activity based
>> access control. I am not saying that ESAPI is there yet either, but
>> Access Control is an area that merits a great deal more research.
>> _*
>> > data validation*_
>>
>> I mostly agree - but keep in mind that most frameworks do NOT do
>> canonicalization, a crucial validation step. ESAPI does this better
>> than the average bear.
>>
>> _*> and logging,
>> *_
>> ESAPI provides something that log4j and others do not - security
>> specific logging. It's not groundbreaking - it's quite simple. But
>> very crucial, IMO.
>>
>> logger.error(Logger.SECURITY_FAILURE, "Attempt to add unsafe data to
>> cookie (skip mode). Skipping cookie and continuing.");
>> *
>> > so unless there's a compelling feature that the application needs
>> from ESAPI, I'd advise them to stick with their investment in their
>> existing frameworks.*
>>
>> I'd like to rephrase that a little  "Stick with your frameworks, but
>> use ESAPI to fill in the gaps"
>>
>> Thanks for your thoughts, Stephen. I "get" where you are coming from,
>> and I think your head is in the right place. (About this topic, at
>> least ;)
>>
>> Regards,
>> - Jim
>>
>>> On Jan 10, 2010, at 5:38 AM, Kevin W. Wall wrote:
>>>   
>>>> IMO, I think the ideal situation would be if we could get the Spring and Struts,
>>>> etc. development communities to integrate their frameworks so that they could
>>>> be used with the ESAPI interfaces. (In many of these cases, these
>>>> implementations would replace the ESAPI reference implementation.) However,
>>>> that is obviously going to take some time. I don't think that the ESAPI
>>>> dev team can do it all.
>>>>     
>>> I think this is overestimating ESAPI's place in the pecking order.  Spring and J2E already have well established APIs for important security functions with a _lot_ of developers already invested in these APIs.  A better approach would be for ESAPI to adapt its API to suit Spring and the other frameworks.
>>>
>>> To touch on one of Dinis' questions, my advise would be for developers to use the features from their existing frameworks and only use ESAPI for the gaps.
>>>
>>> I confess to not having used ESAPI (just scanned the API), but from what I know of other frameworks some of the gaps that ESAPI might plug would be:
>>>
>>> - Output encoding in funky places, like JavaScript and CSS (Some apps never need this)
>>> - CSRF protection (Sometimes the pageflow/workflow features of a framework will already give you CSRF protection, if not, then ESAPI)
>>> - Intrusion detection (if the level of assurance demanded by the application requires it)
>>> - Some methods from the HttpUtilities class could be useful (e.g. setNoCacheHeaders, setSafeContentType)
>>>
>>> For the overlapping functions, I think that existing frameworks already do an acceptable job of providing authentication, access control, data validation and logging, so unless there's a compelling feature that the application needs from ESAPI, I'd advise them to stick with their investment in their existing frameworks.
>>>  
>>>
>>> Stephen
>>> _______________________________________________
>>> Secure Coding mailing list (SC-L) SC-L at securecoding.org
>>> List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
>>> List charter available at - http://www.securecoding.org/list/charter.php
>>> SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
>>> as a free, non-commercial service to the software security community.
>>> _______________________________________________
>>>   
>>
>> ************************************************************
>> 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.
>> ************************************************************
>>   
>
> ************************************************************
> 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.
> ************************************************************
>   


-- 
Jim Manico
OWASP Podcast Host/Producer
http://www.manico.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/esapi-user/attachments/20100111/8bdafbd7/attachment.html 


More information about the Esapi-user mailing list