2014-10-30 13:48:59 -07:00
|
|
|
@ngdoc overview
|
|
|
|
|
@name Security
|
|
|
|
|
@sortOrder 525
|
|
|
|
|
@description
|
|
|
|
|
|
|
|
|
|
# Security
|
|
|
|
|
|
|
|
|
|
This document explains some of AngularJS's security features and best practices that you should
|
|
|
|
|
keep in mind as you build your application.
|
|
|
|
|
|
|
|
|
|
|
2016-02-24 13:19:05 +00:00
|
|
|
## Reporting a security issue
|
|
|
|
|
|
|
|
|
|
Email us at [security@angularjs.org](mailto:security@angularjs.org) to report any potential
|
|
|
|
|
security issues in AngularJS.
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
Please keep in mind the points below about AngularJS's expression language.
|
2016-02-24 13:19:05 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
## Use the latest AngularJS possible
|
|
|
|
|
|
|
|
|
|
Like any software library, it is critical to keep AngularJS up to date. Please track the
|
|
|
|
|
[CHANGELOG](https://github.com/angular/angular.js/blob/master/CHANGELOG.md) and make sure you are aware
|
|
|
|
|
of upcoming security patches and other updates.
|
|
|
|
|
|
|
|
|
|
Be ready to update rapidly when new security-centric patches are available.
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
Those that stray from AngularJS standards (such as modifying AngularJS's core) may have difficulty updating,
|
2016-02-24 13:19:05 +00:00
|
|
|
so keeping to AngularJS standards is not just a functionality issue, it's also critical in order to
|
|
|
|
|
facilitate rapid security updates.
|
|
|
|
|
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
## AngularJS Templates and Expressions
|
2016-09-06 14:33:23 +01:00
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
**If an attacker has access to control AngularJS templates or expressions, they can exploit an AngularJS application
|
2016-09-06 14:33:23 +01:00
|
|
|
via an XSS attack, regardless of the version.**
|
|
|
|
|
|
|
|
|
|
There are a number of ways that templates and expressions can be controlled:
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
* **Generating AngularJS templates on the server containing user-provided content**. This is the most common pitfall
|
2016-09-06 14:33:23 +01:00
|
|
|
where you are generating HTML via some server-side engine such as PHP, Java or ASP.NET.
|
|
|
|
|
* **Passing an expression generated from user-provided content in calls to the following methods on a {@link scope scope}**:
|
|
|
|
|
* `$watch(userContent, ...)`
|
|
|
|
|
* `$watchGroup(userContent, ...)`
|
|
|
|
|
* `$watchCollection(userContent, ...)`
|
|
|
|
|
* `$eval(userContent)`
|
|
|
|
|
* `$evalAsync(userContent)`
|
|
|
|
|
* `$apply(userContent)`
|
|
|
|
|
* `$applyAsync(userContent)`
|
|
|
|
|
* **Passing an expression generated from user-provided content in calls to services that parse expressions**:
|
|
|
|
|
* `$compile(userContent)`
|
|
|
|
|
* `$parse(userContent)`
|
|
|
|
|
* `$interpolate(userContent)`
|
|
|
|
|
* **Passing an expression generated from user provided content as a predicate to `orderBy` pipe**:
|
|
|
|
|
`{{ value | orderBy : userContent }}`
|
|
|
|
|
|
|
|
|
|
### Sandbox removal
|
2017-01-24 17:23:54 +00:00
|
|
|
Each version of AngularJS 1 up to, but not including 1.6, contained an expression sandbox, which reduced the surface area of
|
|
|
|
|
the vulnerability but never removed it. **In AngularJS 1.6 we removed this sandbox as developers kept relying upon it as a security
|
|
|
|
|
feature even though it was always possible to access arbitrary JavaScript code if one could control the AngularJS templates
|
2016-09-06 14:33:23 +01:00
|
|
|
or expressions of applications.**
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
Control of the AngularJS templates makes applications vulnerable even if there was a completely secure sandbox:
|
2016-09-06 14:33:23 +01:00
|
|
|
* https://ryhanson.com/stealing-session-tokens-on-plunker-with-an-angular-expression-injection/ in this blog post the author shows
|
2017-01-24 17:23:54 +00:00
|
|
|
a (now closed) vulnerability in the Plunker application due to server-side rendering inside an AngularJS template.
|
2016-09-06 14:33:23 +01:00
|
|
|
* https://ryhanson.com/angular-expression-injection-walkthrough/ in this blog post the author describes an attack, which does not
|
|
|
|
|
rely upon an expression sandbox bypass, that can be made because the sample application is rendering a template on the server that
|
|
|
|
|
contains user entered content.
|
|
|
|
|
|
|
|
|
|
**It's best to design your application in such a way that users cannot change client-side templates.**
|
2014-10-30 13:48:59 -07:00
|
|
|
|
|
|
|
|
* Do not mix client and server templates
|
|
|
|
|
* Do not use user input to generate templates dynamically
|
2016-09-06 14:33:23 +01:00
|
|
|
* Do not run user input through `$scope.$eval` (or any of the other expression parsing functions listed above)
|
2014-10-30 13:48:59 -07:00
|
|
|
* Consider using {@link ng.directive:ngCsp CSP} (but don't rely only on CSP)
|
|
|
|
|
|
2016-09-06 14:33:23 +01:00
|
|
|
**You can use suitably sanitized server-side templating to dynamically generate CSS, URLs, etc, but not for generating templates that are
|
2017-01-24 17:23:54 +00:00
|
|
|
bootstrapped/compiled by AngularJS.**
|
2016-02-24 13:19:05 +00:00
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
**If you must continue to allow user-provided content in an AngularJS template then the safest option is to ensure that it is only
|
2016-09-06 14:33:23 +01:00
|
|
|
present in the part of the template that is made inert via the {@link ngNonBindable} directive.**
|
2014-10-30 13:48:59 -07:00
|
|
|
|
|
|
|
|
|
2016-02-24 13:19:05 +00:00
|
|
|
## HTTP Requests
|
2014-10-30 13:48:59 -07:00
|
|
|
|
2016-02-24 13:19:05 +00:00
|
|
|
Whenever your application makes requests to a server there are potential security issues that need
|
|
|
|
|
to be blocked. Both server and the client must cooperate in order to eliminate these threats.
|
2017-01-24 17:23:54 +00:00
|
|
|
AngularJS comes pre-configured with strategies that address these issues, but for this to work backend
|
2016-02-24 13:19:05 +00:00
|
|
|
server cooperation is required.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Cross Site Request Forgery (XSRF/CSRF)
|
|
|
|
|
|
|
|
|
|
Protection from XSRF is provided by using the double-submit cookie defense pattern.
|
|
|
|
|
For more information please visit {@link $http#cross-site-request-forgery-xsrf-protection XSRF protection}.
|
|
|
|
|
|
|
|
|
|
### JSON Hijacking Protection
|
|
|
|
|
|
|
|
|
|
Protection from JSON Hijacking is provided if the server prefixes all JSON requests with following string `")]}',\n"`.
|
2017-01-24 17:23:54 +00:00
|
|
|
AngularJS will automatically strip the prefix before processing it as JSON.
|
2016-02-24 13:19:05 +00:00
|
|
|
For more information please visit {@link $http#json-vulnerability-protection JSON Hijacking Protection}.
|
|
|
|
|
|
2017-07-30 17:53:57 +01:00
|
|
|
Bear in mind that calling `$http.jsonp` gives the remote server (and, if the request is not secured, any Man-in-the-Middle attackers)
|
2016-06-07 13:16:04 +02:00
|
|
|
instant remote code execution in your application: the result of these requests is handed off
|
2018-09-05 23:04:58 +05:30
|
|
|
to the browser as a regular `<script>` tag.
|
2016-02-24 13:19:05 +00:00
|
|
|
|
|
|
|
|
## Strict Contextual Escaping
|
|
|
|
|
|
|
|
|
|
Strict Contextual Escaping (SCE) is a mode in which AngularJS requires bindings in certain contexts to require
|
|
|
|
|
a value that is marked as safe to use for that context.
|
|
|
|
|
|
|
|
|
|
This mode is implemented by the {@link $sce} service and various core directives.
|
|
|
|
|
|
|
|
|
|
One example of such a context is rendering arbitrary content via the {@link ngBindHtml} directive. If the content is
|
|
|
|
|
provided by a user there is a chance of Cross Site Scripting (XSS) attacks. The {@link ngBindHtml} directive will not
|
|
|
|
|
render content that is not marked as safe by {@link $sce}. The {@link ngSanitize} module can be used to clean such
|
|
|
|
|
user provided content and mark the content as safe.
|
|
|
|
|
|
|
|
|
|
**Be aware that marking untrusted data as safe via calls to {@link $sce#trustAsHtml `$sce.trustAsHtml`}, etc is
|
|
|
|
|
dangerous and will lead to Cross Site Scripting exploits.**
|
|
|
|
|
|
|
|
|
|
For more information please visit {@link $sce} and {@link ngSanitize.$sanitize}.
|
|
|
|
|
|
|
|
|
|
## Using Local Caches
|
|
|
|
|
|
2017-01-24 17:23:54 +00:00
|
|
|
There are various places that the browser can store (or cache) data. Within AngularJS there are objects created by
|
2016-02-24 13:19:05 +00:00
|
|
|
the {@link $cacheFactory}. These objects, such as {@link $templateCache} are used to store and retrieve data,
|
|
|
|
|
primarily used by {@link $http} and the {@link script} directive to cache templates and other data.
|
|
|
|
|
|
|
|
|
|
Similarly the browser itself offers `localStorage` and `sessionStorage` objects for caching data.
|
|
|
|
|
|
|
|
|
|
**Attackers with local access can retrieve sensitive data from this cache even when users are not authenticated.**
|
2014-10-30 13:48:59 -07:00
|
|
|
|
2016-02-24 13:19:05 +00:00
|
|
|
For instance in a long running Single Page Application (SPA), one user may "log out", but then another user
|
|
|
|
|
may access the application without refreshing, in which case all the cached data is still available.
|
2014-10-30 13:48:59 -07:00
|
|
|
|
2016-02-24 13:19:05 +00:00
|
|
|
For more information please visit [Web Storage Security](https://www.whitehatsec.com/blog/web-storage-security/).
|
2014-10-30 13:48:59 -07:00
|
|
|
|
|
|
|
|
## See also
|
|
|
|
|
|
|
|
|
|
* {@link ng.directive:ngCsp Content Security Policy}
|
