* [ ] Angular wird als Client-seitiges Framework betrachtet und wird nicht erwartet, serverseitigen Schutz zu bieten
* [ ] Sourcemap für Skripte ist in der Projektkonfiguration deaktiviert
* [ ] Nicht vertrauenswürdige Benutzereingaben werden immer interpoliert oder bereinigt, bevor sie in Vorlagen verwendet werden
* [ ] Der Benutzer hat keine Kontrolle über serverseitige oder clientseitige Vorlagen
* [ ] Nicht vertrauenswürdige Benutzereingaben werden vor der Verwendung durch die Anwendung mit einem geeigneten Sicherheitskontext bereinigt
* [ ]`BypassSecurity*`-Methoden werden nicht mit nicht vertrauenswürdigen Eingaben verwendet
* [ ] Nicht vertrauenswürdige Benutzereingaben werden nicht an Angular-Klassen wie `ElementRef`, `Renderer2` und `Document` oder andere JQuery/DOM-Senken übergeben
Angular ist ein **leistungsstarkes** und **Open-Source**-Front-End-Framework, das von **Google** gepflegt wird. Es verwendet **TypeScript**, um die Lesbarkeit und das Debugging des Codes zu verbessern. Mit starken Sicherheitsmechanismen verhindert Angular gängige Client-seitige Sicherheitslücken wie **XSS** und **offene Weiterleitungen**. Es kann auch auf der **Serverseite** verwendet werden, wodurch Sicherheitsüberlegungen von **beiden Seiten** wichtig sind.
Gemäß der Dokumentation hat jede Angular-Anwendung mindestens eine Komponente, die Wurzelkomponente (`AppComponent`), die eine Komponentenhierarchie mit dem DOM verbindet. Jede Komponente definiert eine Klasse, die Anwendungsdaten und -logik enthält und mit einer HTML-Vorlage verknüpft ist, die eine Ansicht definiert, die in einer Zielumgebung angezeigt werden soll. Der `@Component()`-Dekorator kennzeichnet die unmittelbar darunter liegende Klasse als Komponente und stellt die Vorlage und die zugehörigen komponentenspezifischen Metadaten bereit. Die `AppComponent` ist in der Datei `app.component.ts` definiert.
Angular NgModules deklarieren einen Kompilierungskontext für eine Gruppe von Komponenten, die einem Anwendungsbereich, einem Arbeitsablauf oder einem eng verwandten Satz von Funktionen gewidmet sind. Jede Angular-Anwendung hat ein Root-Modul, das konventionell `AppModule` genannt wird und den Bootstrap-Mechanismus bereitstellt, der die Anwendung startet. Eine Anwendung enthält in der Regel viele funktionale Module. Das `AppModule` ist in der Datei `app.module.ts` definiert.
Das Angular `Router` NgModule stellt einen Dienst bereit, mit dem Sie einen Navigationspfad zwischen den verschiedenen Anwendungszuständen und Ansichtshierarchien in Ihrer Anwendung definieren können. Das `RouterModule` ist in der Datei `app-routing.module.ts` definiert.
Für Daten oder Logik, die nicht mit einer bestimmten Ansicht verknüpft sind und die Sie über Komponenten hinweg teilen möchten, erstellen Sie eine Serviceklasse. Die Definition einer Serviceklasse wird unmittelbar vom `@Injectable()`-Dekorator vorangestellt. Der Dekorator stellt Metadaten bereit, die es anderen Providern ermöglichen, als Abhängigkeiten in Ihre Klasse injiziert zu werden. Die Dependency Injection (DI) ermöglicht es Ihnen, Ihre Komponentenklassen schlank und effizient zu halten. Sie rufen keine Daten vom Server ab, validieren keine Benutzereingaben und protokollieren nicht direkt in die Konsole; diese Aufgaben werden an Services delegiert.
Das Angular-Framework übersetzt TypeScript-Dateien in JavaScript-Code, indem es die Optionen der `tsconfig.json` befolgt und dann ein Projekt mit der Konfiguration der `angular.json` erstellt. Beim Betrachten der Datei `angular.json` haben wir eine Option zur Aktivierung oder Deaktivierung einer Sourcemap festgestellt. Gemäß der Angular-Dokumentation ist die Standardkonfiguration für Skripte eine aktivierte Sourcemap-Datei, die standardmäßig nicht ausgeblendet ist:
Generell werden Sourcemap-Dateien zu Debugging-Zwecken verwendet, da sie generierte Dateien ihren Originaldateien zuordnen. Daher wird nicht empfohlen, sie in einer Produktionsumgebung zu verwenden. Wenn Sourcemaps aktiviert sind, verbessert dies die Lesbarkeit und erleichtert die Dateianalyse, indem der ursprüngliche Zustand des Angular-Projekts repliziert wird. Wenn sie jedoch deaktiviert sind, kann ein Überprüfer eine kompilierte JavaScript-Datei immer noch manuell analysieren, indem er nach Anti-Sicherheitsmustern sucht.
Darüber hinaus kann eine kompilierte JavaScript-Datei mit einem Angular-Projekt in den Browser-Entwicklertools → Quellen (oder Debugger und Quellen) → \[id].main.js gefunden werden. Abhängig von den aktivierten Optionen kann diese Datei die folgende Zeile am Ende enthalten `//# sourceMappingURL=[id].main.js.map` oder auch nicht, wenn die **hidden**-Option auf **true** gesetzt ist. Wenn die Sourcemap jedoch für **Skripte** deaktiviert ist, wird das Testen komplexer und wir können die Datei nicht erhalten. Darüber hinaus kann die Sourcemap während des Projektbuilds aktiviert werden, z.B. mit `ng build --source-map`.
Binding bezieht sich auf den Prozess der Kommunikation zwischen einer Komponente und ihrer entsprechenden Ansicht. Es wird verwendet, um Daten zwischen dem Angular-Framework zu übertragen. Daten können auf verschiedene Weise übertragen werden, z.B. durch Ereignisse, Interpolation, Eigenschaften oder durch den Mechanismus der bidirektionalen Bindung. Darüber hinaus können Daten zwischen verwandten Komponenten (Eltern-Kind-Beziehung) und zwischen zwei nicht verwandten Komponenten mithilfe der Service-Funktion geteilt werden.
* Datenquelle zum Ansichtsziel (umfasst _Interpolation_, _Eigenschaften_, _Attribute_, _Klassen_ und _Styles_); kann mit `[]` oder `{{}}` in der Vorlage angewendet werden;
* Ansichtsziel zur Datenquelle (umfasst _Ereignisse_); kann mit `()` in der Vorlage angewendet werden;
* Bidirektional; kann mit `[()]` in der Vorlage angewendet werden.
Das Design von Angular umfasst standardmäßig die Codierung oder Säuberung aller Daten, was es zunehmend schwierig macht, XSS-Sicherheitslücken in Angular-Projekten zu entdecken und auszunutzen. Es gibt zwei verschiedene Szenarien für die Datenverarbeitung:
2. Bindung an Eigenschaften, Attribute, Klassen und Styles oder `[attribute]="user_input"` - führt eine Säuberung basierend auf dem bereitgestellten Sicherheitskontext durch.
Angular führt eine Liste von Methoden ein, um seinen standardmäßigen Säuberungsprozess zu umgehen und anzuzeigen, dass ein Wert sicher in einem bestimmten Kontext verwendet werden kann, wie in den folgenden fünf Beispielen:
3.`bypassSecurityTrustHtml` wird verwendet, um anzugeben, dass der angegebene Wert sicherer HTML-Code ist. Beachten Sie, dass das Einfügen von `script`-Elementen auf diese Weise nicht dazu führt, dass der darin enthaltene JavaScript-Code ausgeführt wird, aufgrund der Art und Weise, wie diese Elemente dem DOM-Baum hinzugefügt werden.
4.`bypassSecurityTrustScript` wird verwendet, um anzugeben, dass der angegebene Wert sicherer JavaScript-Code ist. Wir haben jedoch festgestellt, dass sich das Verhalten dieses Codes unvorhersehbar verhält, da wir keinen JS-Code in Vorlagen ausführen konnten, der diese Methode verwendet.
5.`bypassSecurityTrustStyle` wird verwendet, um anzugeben, dass der angegebene Wert sicherer CSS-Code ist. Das folgende Beispiel veranschaulicht die CSS-Injektion:
Angular bietet eine `sanitize`-Methode, um Daten vor der Anzeige in Ansichten zu säubern. Diese Methode verwendet den bereitgestellten Sicherheitskontext und bereinigt die Eingabe entsprechend. Es ist jedoch wichtig, den richtigen Sicherheitskontext für die spezifischen Daten und den Kontext zu verwenden. Wenn beispielsweise ein Säuberer mit `SecurityContext.URL` auf HTML-Inhalte angewendet wird, bietet dies keinen Schutz gegen gefährliche HTML-Werte. In solchen Szenarien kann ein Missbrauch des Sicherheitskontexts zu XSS-Sicherheitslücken führen.
Diese Schwachstelle tritt auf, wenn Benutzereingaben an eine der drei Eigenschaften gebunden werden: `innerHTML`, `outerHTML` oder `iframe``srcdoc`. Während die Bindung an diese Attribute HTML wie es ist interpretiert, wird die Eingabe mit `SecurityContext.HTML` bereinigt. Daher ist eine HTML-Injektion möglich, aber kein Cross-Site Scripting (XSS).
Angular verwendet Vorlagen, um Seiten dynamisch zu erstellen. Der Ansatz besteht darin, Vorlagenausdrücke, die von Angular ausgewertet werden sollen, in doppelte geschweifte Klammern (`{{}}`) einzuschließen. Auf diese Weise bietet das Framework zusätzliche Funktionalität. Zum Beispiel würde eine Vorlage wie `{{1+1}}` als 2 angezeigt.
Normalerweise maskiert Angular Benutzereingaben, die mit Vorlagenausdrücken verwechselt werden können (z. B. Zeichen wie \`< > ' " \`\`). Das bedeutet, dass zusätzliche Schritte erforderlich sind, um diese Einschränkung zu umgehen, z. B. die Verwendung von Funktionen, die JavaScript-Zeichenkettenobjekte generieren, um gesperrte Zeichen zu vermeiden. Um dies jedoch zu erreichen, müssen wir den Angular-Kontext, seine Eigenschaften und Variablen berücksichtigen. Daher kann ein Angriff auf die Template-Injektion wie folgt aussehen:
Wie oben gezeigt, bezieht sich `constructor` auf den Gültigkeitsbereich der Eigenschaft `constructor` des Objekts, was es uns ermöglicht, den String-Konstruktor aufzurufen und beliebigen Code auszuführen.
Im Gegensatz zu CSR, das im DOM des Browsers stattfindet, ist Angular Universal für das SSR von Vorlagendateien verantwortlich. Diese Dateien werden dann an den Benutzer geliefert. Trotz dieser Unterscheidung wendet Angular Universal die gleichen Säuberungsmechanismen an, die auch bei CSR zur Verbesserung der SSR-Sicherheit verwendet werden. Eine Vorlageneinschleusungsschwachstelle in SSR kann auf die gleiche Weise wie in CSR erkannt werden, da die verwendete Vorlagensprache die gleiche ist.
Natürlich besteht auch die Möglichkeit, neue Vorlageneinschleusungsschwachstellen einzuführen, wenn Drittanbieter-Vorlagenengines wie Pug und Handlebars verwendet werden.
Wie bereits erwähnt, können wir über die _Document_-Schnittstelle direkt auf den DOM zugreifen. Wenn die Benutzereingabe nicht zuvor validiert wird, kann dies zu Cross-Site Scripting (XSS)-Schwachstellen führen.
Es gibt einige Klassen, die in Angular verwendet werden können, um mit DOM-Elementen zu arbeiten: `ElementRef`, `Renderer2`, `Location` und `Document`. Eine detaillierte Beschreibung der letzten beiden Klassen finden Sie im Abschnitt **Open Redirects**. Der Hauptunterschied zwischen den ersten beiden besteht darin, dass die `Renderer2`-API eine Abstraktionsschicht zwischen dem DOM-Element und dem Komponentencode bietet, während `ElementRef` lediglich eine Referenz auf das Element enthält. Daher sollte die `ElementRef`-API gemäß der Angular-Dokumentation nur als letzter Ausweg verwendet werden, wenn direkter Zugriff auf das DOM erforderlich ist.
*`ElementRef` enthält die Eigenschaft `nativeElement`, die verwendet werden kann, um die DOM-Elemente zu manipulieren. Eine unsachgemäße Verwendung von `nativeElement` kann jedoch zu einer XSS-Injektionslücke führen, wie im folgenden Beispiel gezeigt:
```tsx
//app.component.ts
import { Component, ElementRef, ViewChild, AfterViewInit } from '@angular/core';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
...
constructor(private elementRef: ElementRef) {
const s = document.createElement('script');
s.type = 'text/javascript';
s.textContent = 'alert("Hello World")';
this.elementRef.nativeElement.appendChild(s);
}
}
```
* Trotz der Tatsache, dass `Renderer2` eine API bereitstellt, die sicher verwendet werden kann, auch wenn kein direkter Zugriff auf native Elemente unterstützt wird, weist sie dennoch einige Sicherheitslücken auf. Mit `Renderer2` ist es möglich, Attribute an einem HTML-Element mit der Methode `setAttribute()` festzulegen, die keine XSS-Präventionsmechanismen enthält.
```tsx
//app.component.ts
import {Component, Renderer2, ElementRef, ViewChild, AfterViewInit } from '@angular/core';
Während unserer Recherche haben wir auch das Verhalten anderer `Renderer2`-Methoden wie `setStyle()`, `createComment()` und `setValue()` in Bezug auf XSS- und CSS-Injektionen untersucht. Aufgrund ihrer funktionalen Einschränkungen konnten wir jedoch keine gültigen Angriffsvektoren für diese Methoden finden.
jQuery ist eine schnelle, kleine und funktionsreiche JavaScript-Bibliothek, die in Angular-Projekten zur Manipulation von HTML-DOM-Objekten verwendet werden kann. Wie bekannt ist, können die Methoden dieser Bibliothek ausgenutzt werden, um eine XSS-Schwachstelle zu erreichen. Um zu diskutieren, wie einige anfällige jQuery-Methoden in Angular-Projekten ausgenutzt werden können, haben wir diesen Unterabschnitt hinzugefügt.
* Die Methode `html()` gibt den HTML-Inhalt des ersten Elements im Satz der übereinstimmenden Elemente zurück oder legt den HTML-Inhalt jedes übereinstimmenden Elements fest. Jedoch kann jede jQuery-Konstruktor- oder -Methode, die einen HTML-String akzeptiert, potenziell Code ausführen. Dies kann durch das Einfügen von `<script>`-Tags oder die Verwendung von HTML-Attributen, die Code ausführen, wie im Beispiel gezeigt, geschehen.
```tsx
//app.component.ts
import { Component, OnInit } from '@angular/core';
import * as $ from 'jquery';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit
{
ngOnInit()
{
$("button").on("click", function()
{
$("p").html("<script>alert(1)</script>");
});
}
}
//app.component.html
<button>Click me</button>
<p>some text here</p>
```
* Die Methode `jQuery.parseHTML()` verwendet native Methoden, um den String in eine Reihe von DOM-Knoten umzuwandeln, die dann in das Dokument eingefügt werden können.
Wie zuvor erwähnt, werden die meisten jQuery-APIs, die HTML-Strings akzeptieren, Skripte ausführen, die im HTML enthalten sind. Die Methode `jQuery.parseHTML()` führt keine Skripte in dem analysierten HTML aus, es sei denn, `keepScripts` ist explizit `true`. Es ist jedoch immer noch möglich, Skripte indirekt auszuführen, zum Beispiel über das Attribut `<img onerror>`.
```tsx
//app.component.ts
import { Component, OnInit } from '@angular/core';
import * as $ from 'jquery';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent implements OnInit
{
ngOnInit()
{
$("button").on("click", function()
{
var $palias = $("#palias"),
str = "<imgsrc=1onerror=alert(1)>",
html = $.parseHTML(str),
nodeNames = [];
$palias.append(html);
});
}
}
//app.component.html
<button>Click me</button>
<pid="palias">some text</p>
```
### Open Redirects
#### DOM-Schnittstellen
Gemäß der W3C-Dokumentation werden die Objekte `window.location` und `document.location` in modernen Browsern als Aliase behandelt. Aus diesem Grund haben sie eine ähnliche Implementierung einiger Methoden und Eigenschaften, die eine Open-Redirect- und DOM-XSS mit `javascript://`-Schema-Angriffe verursachen können, wie unten beschrieben.
Der kanonische Weg, das aktuelle DOM-Location-Objekt zu erhalten, besteht darin, `window.location` zu verwenden. Es kann auch verwendet werden, um den Browser zu einer neuen Seite umzuleiten. Daher ermöglicht uns die Kontrolle über dieses Objekt, eine Open-Redirect-Schwachstelle auszunutzen.
Diese Methode bewirkt, dass das Fenster das Dokument an der angegebenen URL lädt und anzeigt. Wenn wir die Kontrolle über diese Methode haben, könnte sie ein Angriffsziel für einen Open-Redirect-Angriff sein.
Diese Methode ersetzt die aktuelle Ressource durch diejenige unter der angegebenen URL.
Der Unterschied zur Methode `assign()` besteht darin, dass nach Verwendung von `window.location.replace()` die aktuelle Seite nicht im Sitzungsverlauf gespeichert wird. Es ist jedoch auch möglich, eine Open-Redirect-Schwachstelle auszunutzen, wenn wir die Kontrolle über diese Methode haben.
Die Methode `window.open()` nimmt eine URL entgegen und lädt die Ressource, die sie identifiziert, in einem neuen oder vorhandenen Tab oder Fenster. Die Kontrolle über diese Methode könnte auch eine Möglichkeit sein, eine XSS- oder Open-Redirect-Schwachstelle auszulösen.
```tsx
//app.component.ts
...
export class AppComponent {
goToUrl(): void {
window.open("https://google.com/about", "_blank")
}
}
```
#### Angular-Klassen
* Laut der Angular-Dokumentation ist die Angular-Klasse `Document` dasselbe wie das DOM-Dokument, was bedeutet, dass gängige Vektoren für das DOM-Dokument verwendet werden können, um clientseitige Schwachstellen in Angular auszunutzen. Die Eigenschaften und Methoden von `Document.location` können als Angriffsvektoren für erfolgreiche Open-Redirect-Angriffe dienen, wie im folgenden Beispiel gezeigt:
```tsx
//app.component.ts
import { Component, Inject } from '@angular/core';
* Während der Recherche haben wir auch die Angular-Klasse `Location` auf Open-Redirect-Schwachstellen überprüft, aber es wurden keine gültigen Vektoren gefunden. `Location` ist ein Angular-Service, den Anwendungen verwenden können, um mit der aktuellen URL des Browsers zu interagieren. Dieser Service verfügt über mehrere Methoden zur Manipulation der angegebenen URL - `go()`, `replaceState()` und `prepareExternalUrl()`. Wir können sie jedoch nicht zur Umleitung auf eine externe Domain verwenden. Zum Beispiel:
```tsx
//app.component.ts
import { Component, Inject } from '@angular/core';
import {Location, LocationStrategy, PathLocationStrategy} from '@angular/common';
* Die Angular-Klasse `Router` wird hauptsächlich zum Navigieren innerhalb der gleichen Domäne verwendet und führt keine zusätzlichen Schwachstellen in der Anwendung ein:
* [Angular-Kontext: Einfache Datenbindung für verschachtelte Komponentenbäume und den Router Outlet](https://medium.com/angular-in-depth/angular-context-easy-data-binding-for-nested-component-trees-and-the-router-outlet-a977efacd48)
* [Sanktionierung und Sicherheitskontexte](https://angular.io/guide/security#sanitization-and-security-contexts)
* [Wie man jQuery mit Angular verwendet (wenn es unbedingt erforderlich ist)](https://blog.bitsrc.io/how-to-use-jquery-with-angular-when-you-absolutely-have-to-42c8b6a37ff9)
