Angular Security: The Definitive Guide (Part 3)

June 21, 2023 · VIKTORIIA TARAN & AMINA MURTAZINA & NIKITA HORIUK

In the previous two articles, we discussed the Angular security model and HTML/template injection. Today, we will cover DOM manipulation:

• How improper usage of DOM interfaces can lead to cross-site scripting (XSS) vulnerabilities
• How to work with DOM elements using Angular classes such as ElementRef and Renderer2
• How to avoid security caveats when using jQuery in an Angular project

We will also explore open redirects by misuse of the Document Angular class and observe Location and Router classes for open redirect vulnerabilities.

XSS

DOM interfaces

As previously stated, we can directly access the DOM using the Document interface. If user input is not validated beforehand, it can lead to cross-site scripting (XSS) vulnerabilities.

We used the document.write() and document.createElement() methods in the examples below:

CODE: https://gist.github.com/lsg-vtaran/a78bd5c5adace823123d0ec4bc54c789.js

A list of other possible sinks can be found here.

Angular classes

There are some classes that can be used to work with DOM elements in Angular: ElementRef, Renderer2, Location and Document. A detailed description of the last two classes is given in the Open redirects section. The main difference between the first two is that the Renderer2 API provides a layer of abstraction between the DOM element and the component code, whereas ElementRef just holds a reference to the element. Therefore, according to Angular documentation, ElementRef API should only be used as a last resort when direct access to the DOM is needed.

ElementRef contains the property nativeElement, which can be used to manipulate the DOM elements. However, improper usage of nativeElement can result in an XSS injection vulnerability, as shown below:

CODE: https://gist.github.com/lsg-vtaran/12994df30797522b4921e0ee663bb274.js

Despite the fact that Renderer2 provides an API that can safely be used even when direct access to native elements is not supported, it still has some security flaws.

With Renderer2, it is possible to set attributes on an HTML element using the setAttribute() method, which has no XSS prevention mechanisms.

CODE: https://gist.github.com/lsg-vtaran/ddf24d649cb28421447514496fa636eb.js

• To set the property of a DOM element, you can use the Renderer2.setProperty method and trigger an XSS attack:

CODE: https://gist.github.com/lsg-vtaran/ba81efb9df5dd3393242ca7eb99f464f.js

During our research, we also examined the behavior of other Renderer2 methods, such as setStyle(), createComment(), and setValue(), in relation to XSS and CSS injections. However, we were unable to find any valid attack vectors for these methods due to their functional limitations.

References:

• Angular ElementRef
• Angular Renderer2
• Renderer2 Example: Manipulating DOM in Angular - TekTutorialsHub

jQuery

jQuery is a fast, small, and feature-rich JavaScript library that can be used in the Angular project to help with manipulation the HTML DOM objects. However, as it is known, this library’s methods may be exploited to achieve an XSS vulnerability. In order to discuss how some vulnerable jQuery methods can be exploited in Angular projects, we added this subsection.

• The html() method gets the HTML contents of the first element in the set of matched elements or sets the HTML contents of every matched element. However, by design, any jQuery constructor or method that accepts an HTML string can potentially execute code. This can occur through injection of <script> tags or use of HTML attributes that execute code as shown in the following example.

  CODE: https://gist.github.com/lsg-vtaran/75a6dd09404872d5f99f88385a45cffa.js

• The jQuery.parseHTML method uses native methods to convert the string to a set of DOM nodes, which can then be inserted into the document.

  CODE: https://gist.github.com/lsg-vtaran/a9988f167f304fb813e125389327ab1f.js

  As mentioned before, most jQuery APIs that accept HTML strings will run scripts that are included in the HTML. The jQuery.parseHTML() method does not run scripts in the parsed HTML unless keepScripts is explicitly true. However, it is still possible in most environments to execute scripts indirectly; for example, via the <img onerror> attribute.

  CODE: https://gist.github.com/lsg-vtaran/0dbe919a142ab514bb09038a0950282a.js

References:

• DOM XSS
• jQuery API Documentation
• How To Use jQuery With Angular (When You Absolutely Have To)

Open redirects

DOM interfaces

According to the W3C documentation, the window.location and document.location objects are treated as aliases in modern browsers. That is why they have similar implementation of some methods and properties, which might cause an open redirect and DOM XSS with javascript:// schema as mentioned below.

• window.location.href (and document.location.href)
  The canonical way to get the current DOM location object is using window.location. It can also be used to redirect the browser to a new page. As a result, having control over this object allows us to exploit an open redirect vulnerability.

  CODE: https://gist.github.com/lsg-vtaran/71a73366414efb5c230a27744e618c16.js

  The exploitation process is identical for the following scenarios.

• window.location.assign()(and document.location.assign()) This method causes the window to load and display the document at the URL specified. If we have control over this method, it might be a sink for an open redirect attack.

  CODE: https://gist.github.com/lsg-vtaran/5b85484ff1ca58e7d440a11dc8c41dda.js

• window.location.replace()(and document.location.replace()) This method replaces the current resource with the one at the provided URL.

• window.open() The window.open() method takes a URL and loads the resource it identifies into a new or existing tab or window. Having control over this method might also be an opportunity to trigger an XSS or open redirect vulnerability.

  CODE: https://gist.github.com/lsg-vtaran/8f585345338b0cab9a19057dd0e9e248.js

Also see the DOM XSS page at HackTricks.

Angular classes

1. According to Angular documentation, Angular Document is the same as the DOM document, which means it is possible to use common vectors for the DOM document to exploit client-side vulnerabilities in Angular. Document.location properties and methods might be sinks for successful open redirect attacks, as in the following example:

   CODE: https://gist.github.com/lsg-vtaran/6d57eaa555dcc36ce5abe479dc46c913.js

2. During the research phase, we also reviewed the Angular Location class for open redirect vulnerabilities, but no valid vectors were found. Location is an Angular service that applications can use to interact with a browser’s current URL. This service has several methods to manipulate the given URL - go(), replaceState(), and prepareExternalUrl(). However, we cannot use them for redirection to the external domain. For example:

   CODE: https://gist.github.com/lsg-vtaran/abea7984693766c6f75277fd1558bf3c.js

   Result: http://localhost:4200/http://google.com/about

   Angular Document

   Angular Location

3. The Angular Router class is primarily used for navigating within the same domain and does not introduce any additional vulnerabilities to the application:

   CODE: https://gist.github.com/lsg-vtaran/54d1bfc6033fee87daf828a5d0ef24e0.js

   Result: http://localhost:4200/https:

   The following methods also navigate within the domain’s scope:

   CODE: https://gist.github.com/lsg-vtaran/a4b9f18f74ce5659d2f73f789ff4d9c2.js

   Angular Router

Conclusion

Improper use of DOM interfaces and Angular classes such as ElementRef and Renderer2 can result in XSS vulnerabilities. The use of jQuery in Angular can also introduce security risks. Misuse of DOM interfaces such as window.location and document.location as well as the Document class can lead to open redirect vulnerabilities. However, Angular classes such as Location and Router are not vulnerable to open redirects.

This article concludes our series about Angular. We hope you enjoyed it! However, don’t miss our upcoming Angular security checklist.