Cross Site Scripting with Durandal

[mlde...@gmail.com]

I've been working with Durandal for a while and have a high-level understanding of how the framework takes a url hash, resolves that to a  viewmodel js file based on convention and router maps, and then utilizes require.js to GET the file by dynamically adding a script tag to the DOM.  All very high level.  I would like to know if its possible to construct a hash in some way that would trick the framework into requesting a js file from another domain.  What precautions are in place to prevent this?  Is it even possible?    Is there user-code I can add somewhere for additional checking, maybe some sort of white-list or custom parser that checks for hex codes or other malicious patterns in the url?   

thanks

[Bart Breen]

I'm pretty sure you can just reference the js file in your Require Config (with the other domain as part of the path) and then require it as per normal, and it will grab it fine.

HTML is another story.

As is ViewModels, but i'm sure you could follow the process above and then write a simple VM that wraps the external script.

[mlde...@gmail.com]

 I wan't clear in the original title.  I want to PREVENT XSS, where someone creates a malicious URL that will enable the framework to pull a js file (viewmodel) from another server.

[Kevin McGee]

Interesting thought, but not actually DURANDAL-specific.

I'm not trying to be mean, but I think your query would be valid in any setting where a webapp used RequireJS to load code.

Consider reposting your question on StackOverflow, reframing it to be more about RequireJS than any particular app that takes RequireJS as a dependency.

That may generate more response.

Regards.

[mlde...@gmail.com]

I agree it's somewhat related to require, but since Durnadal sits on top of require I was wondering if theres anything in Durandal that adds additional protection.  I imagine require will GET anything you tell it to. Also, if I wanted to add my own custom code to keep malicious requests from getting to require, where in the Durandal framework could I most easily plug that in?   Maybe I'm over-thinking the potential for abuse.  I was hoping someone like Rob would chime in, or someone else that has very in-depth knowledge of the framework. 

thanks for your advice about posting more general question on SO. 

On Wednesday, December 10, 2014 5:04:58 PM UTC-5, mlde...@gmail.com wrote:

[Robert Greyling]

There may be some dragons hidden deep below the surface where vulnerabilities can hide, as is the case with anything, but when it comes to this question, it comes down to how you've deployed your app, I think you've got a far bigger attack footprint when it comes to your own code than being vulnerable via Durandal or Require.

Firstly, the most common approach for deployment of Durandal apps is to get rid of Require entirely anyway, by using something like Almond as part of your build and deploy. This action takes Require out of the loop, and Almond (AFAIK) only supports "requiring" local resources and cannot reach out over the network anyway. Hence when you use something like Gulp/Grunt/Weyland to mush everything together into one script, you can be 100% sure that the only objects Durandal will ever get hold of in your app are the local ones compiled into your script. Unless an attacker can actually modify your main script (on the server), they don't stand a chance of exploiting framework code in the way you are asking about - and if they're on your server, you've got bigger problems :)

Now of course you can break out of this paradigm and go ahead and deploy the entire thing with Require fully enabled, which again opens the door for your question, so it still has merit. The way Druandal loads (discovers) views and viewmodels as far as I can tell is by various opinionated pattern matching strings/objects and the code it uses to do this can be overridden by your own code to bring your own view loading strategies for example. The default ones that come with Durandal are pretty benign and don't seem exploitable to me on the surface, but I suppose anything is possible given enough brainpower.

What's way more likely though, is that you allow some data entry in your own code to go unescaped/unsanitized which comes back to the browser generating a XXS attack. The potential attacker could spend ages looking for a vulnerability in compressed/uglified framework code, be it Require or Durandal, and of course they could easily exploit their own session by Requiring a malicious script forced through Chrome dev tools or something to test a POC on your code, but that same attacker getting another user on your site to Require that same malicious script without having access to their session would be incredibly difficult if not impossible. They first have to get in on the victim user session, things that open the door to that kind of the thing are your code, especially how you sanitize your data capture etc. The low hanging fruit so to speak. I can't see them getting value wading through reams of uglified framework code unless there was a big reward in it for them and a chance of success.

Maybe Rob would have a better idea and shed more light, but for me this is how I see the current landscape of attack vectors.

So the question is - how are you deploying your stuff? All squished up in a single script, or with full Require calling all the pieces to the party over http requests? While the first is likely safer due to less variables in the mix, I still feel the second is much less prone to attack than your own actual code and functionality on the site itself - especially if you take user input in any form. I would focus on locking that down first.

Hope that helps,

Cheers,

Rob G

--
You received this message because you are subscribed to the Google Groups "DurandalJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to durandaljs+...@googlegroups.com.
Visit this group at http://groups.google.com/group/durandaljs.

To view this discussion on the web visit https://groups.google.com/d/msgid/durandaljs/541d0b0a-baf5-44e4-bfa0-6c0a7602ba67%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[mlde...@gmail.com]

Robert, thanks for your response.  I agree that sanitizing input and encoding\escaping output are the low hanging fruit, and are all on me as a developer.  I've got those as part of my design so I feel good there.  As far as deployment goes, I think I can do more, and maybe thats a separate post.  The only thing in my deployment plan (which is not complete) is to use Visual studio Publish and take advantage of the .net Bundles of css/js.  I would like to also minify/uglify framework code and my own vw's but have not researched which tools to use or how to setup. If you have any links on what plugs in nicely with Durandal, especially Almond,  that would be appreciated.   Thanks again.

On Wednesday, December 10, 2014 5:04:58 PM UTC-5, mlde...@gmail.com wrote:

[Kevin McGee]

Hey there,

FYI, @RobG is referring to this:

https://github.com/jrburke/almond

Almond is a project by James Burke, the project owner of RequireJS.

Best, KJM

[mlde...@gmail.com]

the first restriction listed for best use is:

• optimize all the modules into one file -- no dynamic code loading.

Does that mean all my views (html) and viewmodels (js) will be bundled together into 1 file download?
So if I have an app with 50 screens and the user only visits 2, code for all 50 will have been requested at startup in a single file request?


thanks.

[Robert Greyling]

Hey mldev100,

Take a look at this thread George P kindly shared. I'm currently working towards hivng this work with gulp on one of my projects and will feedback there, but looks like a good way to go to avoid the issue you are concerned about.

https://groups.google.com/forum/#!topic/durandaljs/iN_UpDS7kPo

Cheers,

Rob G

--

You received this message because you are subscribed to the Google Groups "DurandalJS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to durandaljs+...@googlegroups.com.
Visit this group at http://groups.google.com/group/durandaljs.

To view this discussion on the web visit https://groups.google.com/d/msgid/durandaljs/aef4c4d1-e0c7-486a-94ba-338ffd8e2c2c%40googlegroups.com.