[OWASP-ESAPI] OWASP-ESAPI Digest, Vol 26, Issue 37

John Steven jsteven at cigital.com
Mon Nov 9 14:20:40 EST 2009


Jeff,

(Pertinent thread included) The misgivings and demand for a Javascript  
(in more general, RIA) ESAPI is an important question to consider,  
IMO. I think there is value to a Javascript (RIA in general) ESAPI.  
Here's why:

I worry that the ESAPI team is too fixated on creating a silver  
bullet. More realistically, it will create a cadre of security  
controls that will help as part of someone's secure implementation.  
Not only will ESAPI not address some of what I'd consider design flaws  
and it's important to understand that ESAPI can not, not even within  
in Java EE persona, solve all the implementation issues a developer  
faces.

Alternative security activities become important having realized this.  
I'd like to see threat modeling for each persona. As I say in my  
talks, threat modeling is as much an agreed "rules of engagement"  
between development and security as it is a security planning  
exercise. Does a Javascript threat-model have attack vectors that an  
ESAPI implementation could address? Of course. Can one mitigate all of  
the threats that a n-tier or RIA application faces in Javascript? No.  
But, just as ESAPI's inability to address all security bugs doesn't  
preclude its usefulness as an API/impl., a propsed Javascript's (ES) 
API incompleteness relative to the threat model shouldn't preclude its  
development.

I'd suggest a brief planning exercise through which the scope of such  
a Javascript ESAPI is determined and proceed from there. This kind of  
exercise, had it been done with Java EE's ESAPI, would have clarified  
the roles of java.lang.String and PlainText bunches, IMO.

Such an exercise would also provide value as a case study in truly  
"building security in".

----
John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.



On Nov 9, 2009, at 12:00 PM, <owasp-esapi-request at lists.owasp.org>  
wrote:

> On Nov 8, 2009, at 6:42 PM, "Jeff Williams" <jeff.williams at owasp.org>
> wrote:
>
>> Hi Ed,
>>
>> This is interesting.  Are you thinking that JavaScript developers  
>> need
>> security functions too and that this could be the start of a library
>> to help
>> them?
>>
>> I'm all for a JavaScript ESAPI, although I think wee need to do a
>> little
>> thinking about what's appropriate for security on the client-side.
>> I'm so
>> biased by thinking about server applications that it's effort for me
>> to
>> think that sometimes you trust the client more than the server.
>>
>> With the pendulum swinging back towards the client, I think it would
>> be
>> great to have strong security libraries for developers in
>> JavaScript, Flash,
>> Flex, AIR, Silverlight, JFX, etc...
>>
>> --Jeff
>>
>>
>>> -----Original Message-----
>>> From: owasp-esapi-bounces at lists.owasp.org [mailto:owasp-esapi-
>>> bounces at lists.owasp.org] On Behalf Of Ed Schaller
>>> Sent: Friday, November 06, 2009 6:47 PM
>>> To: OWASP-ESAPI
>>> Subject: [OWASP-ESAPI] JavaScript ESAPI HTML encoding and some
>>> framework
>>>
>>> I am not very familiar with JavaScript and certainly not OOP in
>>> JavaScript. That being said, attached is a JavaScript
>>> implementation of
>>> HTMLEntitiyCodec and some framework. There is a test.html file to  
>>> try
>>> it in your browser and a test.rhino to try it with rhino.
>>>
>>> If you include all the right pieces, you can actually do:
>>>
>>> ESAPI.encoder().encodeForHTML(...);
>>>
>>> This also includes my checks (and notes) on validating unicode
>>> characters that might be worth adding to the normal ESAPI at some
>>> point.
>>>
>>> Anyhows, I would be very interested in thoughts, ideas, criticizm,
>>> help, etc
>>>
>>> Thanks
>>>
>>>>>> ------>
>>
>> _______________________________________________
>> OWASP-ESAPI mailing list
>> OWASP-ESAPI at lists.owasp.org
>> https://lists.owasp.org/mailman/listinfo/owasp-esapi
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 9 Nov 2009 08:09:01 -0600
> From: 'Ed Schaller' <schallee at darkmist.net>
> Subject: Re: [OWASP-ESAPI] JavaScript ESAPI HTML encoding and some
>        framework
> To: Jeff Williams <jeff.williams at owasp.org>
> Cc: 'OWASP-ESAPI' <owasp-esapi at lists.owasp.org>
> Message-ID: <20091109140901.GA4063 at darkmist.net>
> Content-Type: text/plain; charset="us-ascii"
>
>> This is interesting.  Are you thinking that JavaScript developers  
>> need
>> security functions too and that this could be the start of a  
>> library to help
>> them?
>
> Yes. My main concern and reason for writing what I have is DOM based
> XSS. I was asked to put together a XSS training for our developers.  
> The
> Java ESAPI provides the tools on the server side that developers
> need. Client side is another issue and I have found nothing to provide
> encoding functions that isn't part of an entire framework.
>
>> I'm all for a JavaScript ESAPI, although I think wee need to do a  
>> little
>> thinking about what's appropriate for security on the client-side.   
>> I'm so
>> biased by thinking about server applications that it's effort for  
>> me to
>> think that sometimes you trust the client more than the server.
>
> In general I am in the same boat on the bias. Client side is becoming
> more and more important though. I believe that the need is there for
> security tools. Sadly, no matter how well encoded html from the server
> is one document.write can still produce a XSS vulnerability.
>
> I'm not hugely knowledgeable with JavaScript but document.write and  
> such
> generally seem like a bad idea (I had to switch my content-type from  
> xhtml
> to html just to get them to work in an example). Inserting nodes via  
> DOM
> seems like a better way to do it in general. Still, at least being  
> able
> to provide tools to make document.write and friends more secure  
> against
> XSS is a good idea. Even if it's just to ease retrofitting old code  
> that
> doesn't use DOM.
>
> I modeled the encoder methods after ESAPI and put them in a ESAPI name
> space as there seemed to be a desire for a start in such a  
> direction. I
> am not able myself to push forward with a whole ESAPI like library
> for the client side but I thought that perhaps it could be used as a
> starting point.
>
> The framework I tried to put them in generally needs some
> redesign/cleanup/refactoring by someone who knows more about packaging
> JavaScript libraries than myself. I will probably just add  
> encodeForHTML
> and encodeForHTMLAttribute to String.prototype for the developers at  
> work.
>
> I would in general appreciate any input folks have into my  
> implementation
> as I'm rather green at JavaScript. There are probably better ways to
> implement such then the way I have.
>
> Thanks!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4359 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-esapi/attachments/20091109/cb475182/attachment.bin 


More information about the OWASP-ESAPI mailing list