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

[Jeff Williams]

> (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:

We've been planning to extend ESAPI to client-side environments for a long
time. Andrew put some work into considering what security controls make
sense for a RIA environment. I think this is essentially the threat modeling
activity you were suggesting?

> 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.

I see no evidence of silver bullet thinking, nor anyone making these claims.
I think your description of a "cadre of security controls that will help" is
right on - and matches our stated mission almost exactly. Instead of
reminding the list of your concerns, I think it would be more constructive
to think of practical ways to make it easier for developers to avoid the
kinds of problems you're imagining.

Still, having strong security controls does simplify the
threat/security/architecture modeling exercise considerably. So the
likelihood of coming up with decent solutions to security design problems is
certainly increased.

--Jeff


> 
> 
> 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!