[WEB SECURITY] Risky client-side framework?

application.secure application.secure application.secure at gmail.com
Thu Apr 9 03:32:49 EDT 2009


The goal of my post is not to speak about security/insecurity of dojo... I
don't say Dojo is insecure... On the contrary, I advice to use a client-side
framework(like dojo or other) to build a more secure RIA-Ajax application!

My topic is over the fact that using a cleint-side framework like dojo
extends the list of XSS patterns. I don't say the dojo property described in
my post is more dangerous than classical XSS patterns... it's exaclty the
But dojo(and probably other frameworks) extends the standard HTML with new
So it introduces new XSS vectors!
Of course you should validate input, you should output encode input... like
in any other classical applications...

The second topic is about the abstraction layer that a client-side
framework(like dojo or any other) introduces...
Of course it is the goal of such framework: to help developer to build
rapidly an application...
I don't say dojo.storage is insecure! It's not the problem at all.
But client-side storage itself can be insecure (listen the black-hat webcast
about RIA - HTML5, G-Gears, ...)...
and dojo.storage chooses the best way to store client-side data depending on
the browser configuration...
So, I just say that we should be carefull with this kind of "default

2009/4/9 NeZa <neza0x at gmail.com>

> Hi,
> I think these kind of frameworks like dojo are so good specially because
> they help non-experience developers to set up (for instance) AJAX
> applications in 5 minutes, this way the developer can focus more in business
> logic than trying to understand AJAX from scratch.
> My real example, i am preparing a Crawl & Audit tool but i want to
> implement AJAX and Marshall/Unmarshall technology so i just started using
> dojo and Castor to acomplish this easily and then i can focus in my Crawl
> Engine which really matter for me.
> Now, if you think dojo is insecure first it was not designed to be secure
> but helpful. :-)
> At the end of the day a well designed application must not rely on client
> side input validation so this kind of XSS attacks can be easily stopped by
> doing proper input & output encoding in server side by implementing white
> list validation.
> My 2 cents!!!
> On Wed, Apr 8, 2009 at 1:48 AM, application.secure application.secure <
> application.secure at gmail.com> wrote:
>> Hello,
>> Ajax security is very large domain. I've started to study Ajax security at
>> different levels:
>>     - "Ajax concepts and Ajax technologies" VS security
>>     - "Ajax patterns" VS security (and application performances)
>>     - "Ajax frameworks" VS security
>> Now, I'm investigating the use of client-side framework and especially
>> "dojo".
>> As any other development framework, it introduces a layer(libraries) over
>> the "base language": Html/javascript
>> (just as server side frameworks such as Spring, Struts, ... do over Java).
>> It introduces new kind of injection at client side level in using the
>> "dojo language"...
>> Does Cheat Sheet like http://ha.ckers.org/xss.html are obsolete in the
>> context of applications using ajax framework?
>> Consider the dojo control sample:
>> <div dojoType="dijit.Dialog" id="dialog1" title="First Dialog"
>>     execute="alert('submitted w/args:\n' + dojo.toJson(arguments[0],
>> true));">...</div>
>> The "execute" property on div tag is specific to "dojo" and fully
>> understandable by a dojo application.
>> Injecting <div ... execute=""/> is a new vector of XSS into a dojo
>> application...
>> One time again, classical Black-list filtering are obsolete.
>> What about WAF black-list filtering? Are they up to date against
>> client-side framework specific injection?
>> Another concern is about framework libraries.
>> Libraries add a layer over the base language functionalities.
>> The behavior of these libraries is not always under the control of the
>> developer; and that's the developer want!
>> It helps the developer against browser compatibilities with javascript.
>> For example, the dojo.xhrGet(...) will instantiate an XHR object for each
>> browsers and it is transparent for the developer.
>> But what about dojo.storage library. It chooses the type of client-side
>> storage depending on the browser and its configurations.
>> Each client-side storage mechanism has its specific security concerns
>> (listen the black-hat webcast about RIA).
>> Does it mean that my dojo application will be less or more secure
>> depending on the browser's configuration of the user? It seems "yes"...
>> Does it mean that upgrading the version of the framework will change the
>> security of my application? Possibly "yes"...
>> I really think that using client-side framework is good for application
>> security but we need to be carefull...
>> One Base principle: if we want to use client-side framework somewhere in
>> our set of applications, the import of libraries should be restricted  only
>> for these applications!
> --
> NeZa
> Hacker Wanna Be from Nezahualcoyotl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/attachments/20090409/e4618de6/attachment.html>

More information about the websecurity mailing list