3

There has been a long Debate on CSP modelling, I have a Web application and I use JQuery in it, For that i use JQuery main site http://code.jquery.com/jquery-x.yy.z.min.js to Host it on my Site to work, I know that CDN's can be useful in cases like this, i could also put this in my script tags https://ajax.googleapis.com/ajax/libs/jquery/x.yy.z/jquery.min.js to work-out the Same process. As far as the loading time is concerned Google hosted JQuery is faster than code.jquery.com.

Now, let's say i use the second one i.e ajax.googleapis.com part to Host my JQuery site on my Website. Now, to place Defense-in-depth Mechanism to avoid XSS i use CSP (Content-Security-Policy) headers, Now first thing that i do is to White-List by script-src 'self' ajax.googleapis.com . Now, let's say i have a Portion on my Website where Input is getting reflected without filtering which can cause XSS. Now, inline scripts like <script>alert(/xss/)</script> would get Blocked and Provide me protection. But there is a Negative afterwards, as i have white-listed the ajax.googleapis.com , any attacker can use Angular JS 1.1.3 from the same and cause XSS just like "><script src="//ajax.googleapis.com/ajax/libs/angularjs/1.1.3/angular.min.js"></script><div ng-app ng-csp id=p ng-click=$event.view.alert(1337)><script async src=//ajax.googleapis.com/jsapi?callback=p.click></script>

This will result in XSS attack, Now the point is How could i Modify my CSP Rule so that it block every other End-point of the Whitelisted site i have Or if It's not Possible than I guess than Google API CDN is surely not a better choice than code.jquery.com. Any Explanation on how to workout?

Because even if i use code.jquery.com and Whitelist it, than Attacker may use older version of Jquery from same CDN and can mis-use it's vulnerability to cause XSS. So what is the Most safest Bet i can put here? Explain

Improve this question
6
  • 1
    This is what Subresource Integrity is for. Use CDNs with SRI and fall back to self-hosted if that fails.
    – grc
    Jul 22, 2016 at 8:21
  • In addition to subresource integrity, if you're using CSP, make sure to only whitelist specific files within a CDN, not the whole CDN, to avoid this
    – paj28
    Jul 22, 2016 at 12:18
  • Yes @paj28 , That was what i was thinking, But in some cases, when you Try to Whitelist path+domain it sometimes causes problem as what happens is the Whitelisted path or File could fetch internally other Files from different path who are not whitelisted which may cause an error. and whitelisting every file may exceed HTTP header total length ! CSP isn't a panacea but still is do-able . I would prefer running JQuery locally by creating a Sub-directory and putting it's file and call like <script src= js/jquery.js></script> .. Do you suggest any Other better option than this?
    – Gerorge Timber
    Jul 22, 2016 at 12:53
  • Try to use bundles that don't load other files. You can reference directories on CDNs, just make sure it doesn't contain an old vulnerable version. Other than that - JQuery locally is fine, if that's what you want.
    – paj28
    Jul 22, 2016 at 13:12
  • 1
    @dandavis I have protection in Input Filtering, But i have to make sure by placing defense in depth CSP for additional protection in case, someone broke out of my Filter :)
    – Gerorge Timber
    Jul 23, 2016 at 6:48

3 Answers 3

Reset to default
0

You may want to take a look at the "Making CSP Great Again" presentation from AppSec Europe, which discusses some nuances of deploying effective CSPs.

The comment by user grc mentioning Sub Resource Integrity is another way to help ensure that only scripts you have explicitly whitelisted (based on the hash contents) can be loaded. This means that you can avoid an attacker being able to inject a vulnerable version of Angular (it will fail the SRI check), however you will need to monitor for new releases of Angular / keep that up-to-date. Also note that attacker injected script will likely not have an SRI hash included (and so any library can be loaded) unless they are only able to influence the 'src' of a script tag that you applied the hash to.

The only way you can really block other vulnerable endpoints is to whitelist specific .js paths in your CSP, however I would highly recommend testing this across multiple browsers (and/or having some kind of regression test) to ensure they don't fall back to whitelisting the entire source origin.

As an alternative, you may prefer to use a nonce-based CSP: https://blogs.dropbox.com/tech/2015/09/unsafe-inline-and-nonce-deployment/

The idea being, even if the attacker can insert another script element, they won't be able to determine the nonce, and you should be able to prohibit unwanted scripts that live on the same origin with that technique as long as users can't influence the contents of the 'src' attribute for script tags you bless with the nonce.

Note, though, that this still doesn't protect the integrity of the content (if your CDN gets owned, everyone who pulls JS from there will pull the malicious content). For that, SRI is necessary.

Improve this answer
3
  • Thanks, I would like to know one more thing @phil-ames , If let's say i whitelist an Endpoint of googlemaps API and in Real scenario, google maps API endpoint fetches different stuffs from other js endpoint. So in that case, if i whitelist only One JS, than other dependencies won't run as they are not whitelisted. Now, if i keep whitelisting each and every js than my Header size would exceed the Maximum. In this case, what should be correct CSP header format according to you.. :)
    – Gerorge Timber
    Jul 23, 2016 at 6:51
  • 2
    This is a great followup question, and there actually was a new feature added to CSP to help support use cases like this called 'strict-dynamic', a feature in CSP3: w3c.github.io/webappsec-csp/#strict-dynamic-usage Browser support may be spotty for this as it was just released in Chrome stable, but it should help address that problem
    – Phil Ames
    Jul 23, 2016 at 16:17
  • Oh, I should also note that one other way similar to SRI to restrict the scripts that you load is to use hash based CSP. There's some discussion about this here if you're interested: github.com/w3c/webappsec/issues/363
    – Phil Ames
    Jul 23, 2016 at 16:21
0

my understanding is its not possible to specify individual JS files. instead the principle is you trust the CDN provider in this case you trust google. I think it would be a nice extension to the CSP if you are allowed whitelist the domain and JS resource.

Improve this answer
4
  • Yes absolutely @darragh , If CSP allowed to Whitelist the domain origin as well as the JS Resource than CSP would be more effective in protection, But as currently that is not proposed, do you know any other Ways to workout for this, because this is a Open-LiveWire kind of situation
    – Gerorge Timber
    Jul 22, 2016 at 8:50
  • CSP can whitelist domain + path. Have a look at the CSP for npmjs.com - it whitelists a couple of specific files on CDNs.
    – paj28
    Jul 22, 2016 at 12:39
  • @paj28 can you direct me to where this is defined I. the specification. from my previous reading it was not possible has the specification been updated ?
    – Darragh
    Jul 23, 2016 at 12:46
  • Not just now, but check you're looking at latest spec - think it's v2
    – paj28
    Jul 23, 2016 at 16:41
0

If you really want to secure the javascript used on your site, just copy on your own server the jQuery part that you use and serve it directly from there. CDN are extremely useful for large contents like video file. But javascript is not that heavy and can normally be cached by client browsers, so they load it only once for a whole session.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .