JavaScript-Code: praktische Angriffsbeispiele

Achtung, AngularJS
Kommentare

AngularJS – völlig harmlos! Was kann da schon groß passieren? Viel, wenn man nicht aufpasst. Und Cyberkriminelle verzeihen keine Fehler, sondern nutzen sie aus. Im Fall von JavaScript fällt ihnen das im Zweifel besonders leicht, da sie dabei Zugriff auf Sourcecode und Business Logic haben alles vom Webserver frei Haus geliefert.

Angriffe auf und über den Webclient waren ja schon des Öfteren Thema im Windows Developer. Unabhängig davon, ob es dabei um mögliche Angriffe [1] oder Schwachstellen [2] ging oder wie im aktuellsten Artikel um praktische Beispiele für Angriffe [3] – immer wurden JavaScript-Funktionen missbraucht und/oder Schwachstellen in den Clientimplementierungen ausgenutzt. AngularJS ist ebenfalls einfach „nur“ JavaScript-Code, kann also missbraucht werden bzw. mögliche Schwachstellen enthalten, alles bereits Geschriebene gilt also auch dafür.
Und damit kann dieser Artikel enden. Es gibt nichts mehr zu sehen, bitte blättern Sie weiter. Nein, tut mir leid, so einfach ist es leider nicht. Denn natürlich enthält AngularJS seine eigenen Fallstricke, ganz unabhängig von allen sonstigen Möglichkeiten, die JavaScript einem Angreifer bietet. Und so wie jede andere Software auch ist natürlich auch AngularJS nicht frei von Fehlern, und wie immer und überall sind darunter eben auch ausnutzbare Schwachstellen. Aber es gibt nicht nur Fallstricke und Schwachstellen, auch Positives in Sachen Sicherheit ist zu vermelden. Aber fangen wir mit den Schwachstellen an.

Schwachstellen in AngularJS

Wenn man im Internet nach bekannten Schwachstellen in AngularJS sucht, stößt man schnell auf eine von Mathias Karlsson entdeckte Möglichkeit zum Ausbruch aus der AngularJS-Sandbox. Die wiederum führte zur Entdeckung einer weiteren Ausbruchsmöglichkeit durch Gábor Molnár.

Die an die AngularJS-Entwickler gemeldeten Schwachstellen wurden recht zügig behoben. Da die Schwachstellen erst nach der Korrektur veröffentlicht wurden, sind Anwendungen, die die jeweils aktuellste Version von AngularJS verwenden, im Allgemeinen keiner Gefahr ausgesetzt. Zumindest, sofern nicht Cyberkriminelle die Schwachstellen ebenfalls entdecken und vor ihrer Korrektur ausnutzen. Aber diese Gefahr besteht immer und überall und hat nichts mit AngularJS oder auch nur JavaScript zu tun. Microsoft musste schon öfter die Erfahrung machen, dass eine vertraulich gemeldete Schwachstelle von Angreifern ausgenutzt wurde, bevor der Patch fertig war und veröffentlicht werden konnte.

Anders sieht es bei Angriffen auf veraltete Versionen mit bekannten Schwachstellen aus. Im Fall von AngularJS gibt es ein sehr schönes Beispiel für einen Angriff über eine veraltete Version: Die Infrastructure-as-a-Service-Plattform Eucalyptus nutzt AngularJS für die Managementkonsole, und über die von Mathias Karlsson entdeckte Möglichkeit zum Ausbruch aus der Sandbox konnte darin Code eingeschleust werden. Zum Glück wurde die Schwachstelle von Sicherheitsforschern entdeckt und den Entwicklern gemeldet.

Ein Überblick über die Sicherheit

Im Wiki „mustache-security“ von Cure53 wird eine Reihe von Sicherheitstipps zu Schwachstellen in JavaScript-MVC-Frameworks und Template-Engines zusammengefasst, darunter auch für AngularJS. Das Sicherheitslevel eines Frameworks wird dabei anhand einiger Anforderungen geprüft:

  1. Werden Template-Ausdrücke ohne die Verwendung von eval() oder Function() ausgeführt?
  2. Ist der Ausführungs-Scope gut isoliert oder in eine Sandbox eingeschlossen?
  3. Können nur Skriptelemente als Templatecontainer dienen?
  4. Erlaubt, ermutigt oder erzwingt das Framework die Trennung von Code und Inhalten?
  5. Haben die Framework-Maintainer ein Security-Response-Programm?
  6. Erlaubt oder ermutigt das Framework den Einsatz sicherer Content-Security-Policy-Regeln?

Idealerweise sollte jede Frage mit Ja beantwortet werden können. Für AngularJS sehen die Antworten wie in Tabelle 1 aufgeführt aus.

Tabelle 1: Die Anforderungen an ein sicheres Framework

Tabelle 1: Die Anforderungen an ein sicheres Framework

Von den aufgeführten Schwachstellen wurde ein Großteil in AngularJS 1.2.x behoben, andere sind nicht unumstritten. Teilweise sind Angriffe nur möglich, wenn ein Angreifer das Template auf dem Server ändern kann. Und wenn der Angreifer das kann, sind Angriffe auf den Client wohl das kleinste Problem der Websitebetreiber. Denn dann hat der Angreifer sehr wahrscheinlich die gesamte Kontrolle über den Server.

Ein generelles Problem bleibt aber: AngularJS verwendet teilweise Blacklists, zum Beispiel, um die Verwendung von javascript: und anderen kritischen URL-Schemata für bestimmte Attribute zu verhindern. Diese sind bekanntlich unsicherer als Whitelists, sodass immer die Gefahr besteht, dass ein Angreifer eine Möglichkeit findet, die Blacklist zu umgehen.

Sicherheit mit AngularJS

Betrachten wir nun die Schutzmaßnahmen und Sicherheitsfunktionen von AngularJS. Die sehen auf den ersten Blick gar nicht mal so schlecht aus.  Auf den zweiten stellt sich zumindest das Sicherheitsfeature als missverständlich dar. Oder wie soll man es sonst nennen, wenn es zwar Sandboxing gibt, das aber gar nicht der Sicherheit dient?

Eine Sandbox, die gar keine ist

Für die Ausdrücke gilt in AngularJS Folgendes: „AngularJS’s expressions are sandboxed not for security reasons, but instead to maintain a proper separation of application responsibilities.“ Zum Glück ist das aber nicht ganz so schlimm, wie es auf den ersten Blick erscheint: „However, this sandbox is not intended to stop attackers who can edit the template before it’s processed by Angular. It may be possible to run arbitrary JavaScript inside double-curly bindings if an attacker can modify them.“ Denn ein Angreifer, der ein Template modifizieren kann, hat es gar nicht mehr nötig, aus der Sandbox auszubrechen.

Handelt es sich um ein serverseitiges Template, hat ein Angreifer, der das Template ändern kann, wie bereits erwähnt Zugriff auf den Server und kann dort viel mehr Schaden anrichten, als er es auf dem Client allein tun könnte. Falls er den Client angreifen will, kann er einfach seinen eigenen Schadcode als script-Tag ins Template schreiben; die Sandbox interessiert dabei gar nicht.

Bei einem clientseitigen Template sieht es ähnlich aus: Wer das Template manipulieren kann, kann auch ein script-Tag mit Schadcode einfügen und muss sich gar nicht erst die Mühe machen, vorhandenen Code zu manipulieren und danach aus der Sandbox auszubrechen.

In diesem Fall stört mich auch eher die falsche Nutzung des Begriffs als die möglichen Folgen eines Angriffs. Denn allgemein geht man doch davon aus, dass eine Sandbox dazu dient, einen Angriff auf den Bereich der Sandbox zu beschränken und Zugriffe aus der Sandbox heraus zu verhindern. Und wenn das dann im Developer Guide von AngularJS auch noch im Kapitel „Security“ zusammen mit anderen „Security Features“ beschrieben wird, ist die Irreführung perfekt. Vor allem, wenn es in diesem Kapitel gar keine weiteren Security Features gibt, sondern nur unter „See also“ Verweise darauf aufgeführt werden.

Generell sollte man server- und clientseitige Templates nicht gemeinsam nutzen, da dabei die Gefahr besteht, sich XSS-Schwachstellen einzuhandeln. Also immer daran denken: Alles, was vom Client kommt, kann von einem Angreifer manipuliert worden sein. Wenn vom Client geliefertes HTML von AngularJS verarbeitet wird, könnte ein Angreifer darüber JavaScript-Code einschleusen.

Die Content Security Policy und AngularJS

Kommen wir nun zu einem Punkt, der unter Security als „ferner liefen“ aufgeführt wird (unter „See also“, um genau zu sein): die Content Security Policy (CSP) [2]. Die CSP verhindert unter anderem die Verwendung von eval() und über Function() erzeugte Funktionen. AngularJS verwendet mit Function() erzeugte Funktionen zur Geschwindigkeitsoptimierung. AngularJS enthält einen CSP-Kompatibilitätsmodus, in dem diese Optimierungen unterbleiben. Dadurch werden Ausdrücke langsamer ausgewertet, dafür aber auch die CSP-Regeln nicht verletzt.

Außerdem ist es bei Nutzung der CSP nicht möglich, über JavaScript Style-Sheet-Regeln ins Dokument einzufügen. Normalerweise bindet AngularJS einige CSS-Regeln wie zum Beispiel ngCloak automatisch ein. Im CSP-Kompatibilitätsmodus funktioniert das nicht, sodass angular-csp.css manuell eingebunden werden muss.

AngularJS erkennt, wenn die CSP aktiv ist, und aktiviert den Kompatibilitätsmodus automatisch. Diese automatische Erkennung führt aber zum Eintrag eines (harmlosen) Fehlers in der Console. Wenn Sie sich den Eintrag ersparen wollen, aktivieren Sie den CSP-Kompatibilitätsmodus durch Setzen der ngCSP-Direktive im root-Element der Anwendung oder dem angular.js-Script-Tag (je nachdem, was zuerst im HTML-Dokument auftaucht).

Unter AngularJS 1.0.8 und 1.1.5 kann die CSP mithilfe von AngularJS-Funktionalitäten umgangen werden. Diese Schwachstelle wurde in AngularJS 1.2.x behoben. das ist ein weiterer Grund, um immer die aktuellste Version zu verwenden.

Strict Contextual Escaping

Im ab AngularJS 1.2 per Default eingeschalteten Strict Contextual Escaping (SCE) Mode erfordert AngularJS für Bindings in bestimmten Kontexten ein Ergebnis, das zur Verwendung in diesem Kontext als „safe to use“ markiert ist. So ein Kontext wird als privilegiert oder SCE-Kontext bezeichnet. Ein gutes Beispiel ist das Binden vom Benutzer gelieferter HTMLs über ng-bind-html. Das kann zum Beispiel so aussehen:

<input ng-model="userHtml" aria-label="User input">
<div ng-bind-html="userHtml"></div>

Damit ist ng-bind-html an das vom Benutzer gelieferte userHtml gebunden. Ohne SCE kann der Benutzer beliebigen HTML-Code im div-Tag rendern. Im Fall von HTML kann die Eingabe auf Client oder Server zum Beispiel mithilfe einer Library oder $sanitize auf Zulässigkeit geprüft und/oder unerwünschte Teile ausgefiltert werden, bevor sie im Dokument ausgegeben wird.

Realisiert wird das alles, indem im privilegierten Kontext Direktiven und Code nicht direkt an den Wert, sondern an das Ergebnis von $sce.getTrusted(context, value) gebunden werden. Die Direktiven $sce.parseAs werden anstelle von $parse zur Bearbeitung von Attribut-Bindings verwendet. Die folgenden Trusted Context Types stehen zur Verfügung (für Beispiele siehe hier):

  • $sce.HTML für HTML, das ohne Gefahr in die Anwendung eingefügt werden kann. Wird ein unsicherer Wert erkannt, wird das $sanitize-Modul (sofern vorhanden) verwendet, um unsichere Teile auszufiltern.
  • $sce.CSS wird zurzeit nicht verwendet und soll analog zu $sce.HTML für sichere CSS sorgen.
  • $sce.URL für URL, denen gefahrlos als Links gefolgt werden kann. Dieser Type wird zurzeit ebenfalls nicht verwendet. Die URLs in <a href=… und <img src=… werden gefiltert und stellen keinen SCE-Kontext dar.
  • $sce.RESOURCE_URL wird für URLs verwendet, deren Inhalte sich ohne Gefahr in die Anwendung einfügen lassen. Der Kontext wird zum Beispiel für ng-include und src/ngSrc Bindings für andere Tags als img (also zum Beispiel iframe, object …) verwendet.
  • $sce.JS für JavaScript-Code, der gefahrlos im Kontext der Anwendung ausgeführt werden kann. Auch dieser Kontext wird von AngularJS bisher nicht benutzt.

HTML-Sanitizer „$sanitize“

Das Modul $sanitize ist ein sehr guter HTML-Sanitizer. Der eingegebene HTML-Code wird zuerst in Tokens geparst. Alle auf einer Whitelist enthaltenen sicheren Tokens werden danach in einen korrekt escapeten HTML-String serialisiert. Unerwünschte Teile der Eingabe werden dadurch ausgefiltert. Da dieser Parser sich strenger als ein typischer Browserparser an die Regeln hält, werden mitunter auch Eingaben ausgefiltert, die ein Browser als gültiges HTML akzeptiert und ausgegeben hätte. Das ist aber notwendig, da manche XSS-Angriffe die Nachlässigkeit der Browserparser ausnutzen, um Schadcode an Filtern vorbeizuschleusen. Wenn Sie also vom Benutzer geliefertes HTML in Ihrer Anwendung verarbeiten, können Sie durch den Einsatz von $sanitize XSS-Angriffe verhindern.

AngularJS und sein CSRF-Schutz

Cross-Site Request Forgery (CSRF) verhindert man, indem jeder Request ein nicht vorhersagbares Token (also im einfachsten Fall einen Zufallswert) enthält, der vor der Ausführung der durch den Request ausgelösten Aktion überprüft wird. Nur wenn das Anti-CSRF-Token korrekt ist, wird die Aktion ausgeführt. AngularJS kommt dem User dabei entgegen: Gibt es einen über JavaScript lesbaren Cookie mit dem Namen XSRF-Token, wird dessen Wert in allen Requests an die eigene Domain als HTTP-Header X-CSRF-TOKEN mitgeschickt. Da nur JavaScript von Ihrer Domain auf den Cookie zugreifen kann, können Sie sicher sein, dass der Request von JavaScript von Ihrer Domain geschickt wurde.

Um den CSRF-Schutz nutzen zu können, muss nach der Authentifizierung des Benutzers ein über JavaScript lesbarer Cookie mit dem Namen XSRF-Token gesetzt werden. Bei späteren Requests kann der Server prüfen, ob der von ihm gesetzte Cookiewert mit dem Wert im vom Client mitgeschickten HTTP-Header übereinstimmt.

Um in Umgebungen mit mehreren AngularJS-Anwendungen unter der gleichen (Sub-)Domain Kollisionen zu verhindern, sollte jede Anwendung einen eindeutigen Cookienamen verwenden. Der Name von Header und Cookie kann über die Property xsrfHeaderName bzw. xsrfCookieName von entweder $httpProvider.defaults (bei der Konfiguration), $http.defaults (zur Laufzeit) oder dem config-Objekt per Request gesetzt werden.

Das Ganze hat auf den ersten Blick einen Schönheitsfehler: Normalerweise setzt man für Cookies das HttpOnly-Flag, um ein Ausspähen durch über XSS eingeschleusten JavaScript-Code zu verhindern. Auf den ungeschützten XSRF-Token-Cookie kann so eingeschleuster Schadcode jedoch zugreifen. Das ist jedoch kein wirkliches Problem, denn jeder CSRF-Schutz kann unterlaufen werden, wenn die Webanwendung eine XSS-Schwachstelle hat. Und außerdem: XSS-Schwachstellen wollen Sie ja sowieso prinzipiell nicht haben, auf einen Grund mehr oder weniger kommt es dann auch nicht mehr an.

AngularJS-JSON-Hijacking-Schutz

Um das Ausspähen von JSON-Daten zu verhindern, wird ihnen meist der String „)]}‘,\n“ als Präfix vorangestellt. AngularJS entfernt diesen String automatisch, bevor die JSON-Daten verarbeitet werden.

AngularJS und die OWASP Top 10

In den OWASP Top 10 werden die zehn gefährlichsten Schwachstellenklassen in Webanwendungen erfasst. Welche Besonderheiten gibt es dabei im Zusammenhang mit AngularJS?

OWASP Top 10 for AngularJS Applications

 

Kevin Hakanson hat mehrfach einen Vortrag mit dem Titel „ng-owasp: OWASP Top 10 for AngularJS Applications“ gehalten. In den Videosdes Vortrags sowie in den zugehörigen Präsentationen finden Sie weitergehende Informationen sowie Codebeispiele.

A1 ‑ Injection

Bei Injection-Schwachstellen kann der Angreifer allgemein bösartige Befehle an einen Interpreter schicken. Die bekanntesten Beispiele für solche Schwachstellen sind SQL Injection und Command Injection. Auch Content Spoofing (Content Injection) gehört in diese Klasse von Schwachstellen. Dabei manipuliert der Angreifer die an den Benutzer ausgegebene Website im Gegensatz zum XSS (A3) über andere Wege als eingeschleusten JavaScript-Code.

Vor Content-Injection-Angriffen schützt der Einsatz des oben schon beschriebenen Strict Contextual Escaping (SCE) und die Verwendung des ebenfalls schon vorgestellten HTML-Sanitizers $sanitize. Außerdem sollten < und > in ihre HTML-Entities &lt; und &gt; umgewandelt sowie alle Start- und End-Marker für die Interpolation escapt werden.

A2 ‑ Broken Authentication and Session Management

In diese Kategorie von Schwachstellen fallen zum Beispiel alle Möglichkeiten, die Authentifizierung zu umgehen, sowie Zugangsdaten oder Session-Identifier auszuspähen. Auf dem Client sind dabei nur wenige Punkte zu beachten:

  • Die Session muss bei Bedarf am Leben erhalten werden, zum Beispiel durch Pinging.
  • Ein Session-Time-out muss erkannt und korrekt behandelt werden.
  • OAuth-Tokens müssen sicher verwaltet werden.
  • Beim Beenden der Session müssen alle nicht persistenten Daten gelöscht werden. Verlassen Sie sich nicht darauf, dass zum Beispiel der Session-Storage automatisch vom Browser gelöscht wird. Das muss nicht immer funktionieren, denn Sie wissen ja: Murphy sorgt schon dafür, dass das im ungünstigsten Fall nicht passiert.

A3 ‑ Cross-Site Scripting (XSS)

Beim Cross-Site Scripting schleust der Angreifer JavaScript-Code in die Webanwendung ein. Schutz vor XSS bietet zum einen die Content Security Policy (siehe oben), zum anderen die bereits zur Abwehr von Content Injection aufgeführten Möglichkeiten.

A4 ‑ Insecure Direct Object References

Eine direkte Objektreferenz entsteht, wenn die Anwendung einen direkten Verweis auf ein Objekt (Datei, Verzeichnis, Datenbankschlüssel etc.) enthält. Gibt es keine oder keine ausreichende Zugriffskontrolle, kann ein Angreifer unbefugt auf das Objekt zugreifen. Da es sich hierbei um eine serverseitige Schwachstelle handelt, kann sie auch nur dort korrigiert werden.

Unter AngularJS kann ein Angreifer durch die Art der Verwendung von $resource Informationen über RESTful-Datenquellen erhalten, die den Angriff darauf erleichtern. Das gilt aber ganz allgemein für alle entsprechenden Implementierungen auf dem Client. Wenn JavaScript-Code im Browser auf irgendetwas auf dem Server zugreifen soll, muss der Code notgedrungen wissen, wo das zu finden ist und wie er sich authentifizieren muss. Und diese Informationen kann ein Angreifer dann eben ausspähen.

A5 ‑ Security Misconfiguration

Konfigurationsfehler können zu kritischen Schwachstellen führen. Eigentlich sollten alle Anwendungen heutzutage so ausgeliefert werden, dass die Default-Installation so sicher wie möglich ist. Achten Sie also in Ihrer Webanwendung darauf, keine unsicheren Default-Einstellungen zu verwenden. Denn diese werden nur sehr selten geändert. Ebenfalls in die Kategorie „Konfigurationsfehler“ fällt die Verwendung unsicherer Programmversionen mit bekannten Schwachstellen.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

A6 ‑ Sensitive Data Exposure

In diese Kategorie fallen alle nicht oder nicht ausreichend geschützten sensitiven Daten wie zum Beispiel Kreditkartendaten, Zugangsdaten etc. Zum Schutz der Daten sollten sie sowohl beim Transport als auch bei der Speicherung verschlüsselt und möglichst nicht in den URL übertragen werden. Außerdem müssen nicht mehr benötigte Daten auf dem Client gelöscht werden.

Unter AngularJS 2.0 wird für die sichere Speicherung von Daten auf dem Client das Modul ngStore zur Verfügung stehen, das auch die verschlüsselte Speicherung der Daten erlauben wird.

A7 ‑ Missing Function Level Access Control

Erfolgt auf dem Server vor der Ausführung einer Funktion keine Prüfung, ob der Benutzer überhaupt zu deren Nutzung berechtigt ist, kann ein Angreifer unbefugt Funktionen nutzen. Das passiert zum Beispiel, wenn auf dem Client nur die dem Benutzer erlaubten Funktionen angezeigt werden und der Entwickler sich darauf verlässt, dass keine anderen Funktionen aufgerufen werden. Allerdings kann nichts einen Angreifer davon abhalten, einen gefälschten Request an den Server zu schicken und ihm eigentlich nicht zugängliche Funktionen aufzurufen. Diese ist ebenso wie A4 (Insecure Direct Object References) eine serverseitige Schwachstelle, die auch nur dort behoben werden kann.

A8 ‑ Cross-Site Request Forgery (CSRF)

Bei einem CSRF-Angriff wird der Browser eines Benutzers dazu gebracht, in dessen Namen einen gefälschten Request an den Server zu senden. Da der automatisch auch den Session-Cookie und andere automatisch hinzugefügten Informationen enthält, führt eine verwundbare Webanwendung den Request im Namen des Benutzers aus. Wie Sie CSRF-Angriffe mit AngularJS abwehren, wurde oben bereits beschrieben.

A9 ‑ Using Components with Known Vulnerabilities

Enthält eine Webanwendung Komponenten, die bekannte Schwachstellen aufweisen, ist das genau so, als würde die Anwendung selbst die entsprechenden Schwachstellen enthalten. Lesen Sie dazu auch das Beispiel mit der veralteten AngularJS-Version vom Anfang. Und was macht man dagegen? Natürlich immer die aktuellsten Versionen verwenden. Im Fall von JavaScript hilft Retire.js dabei, nach veralteten JavaScript-Bibliotheken zu suchen.

A10 ‑ Unvalidated Redirects and Forwards

Wenn die Webanwendung den Benutzer zum Beispiel nach erfolgreicher Authentifizierung zu einer anderen Seite weiterleitet und dabei das Weiterleitungsziel nicht prüft, kann ein Angreifer sein Opfer darüber auf eine beliebige, auch externe Seite, schicken. Der Angreifer ändert dazu beispielsweise den URL von https://www.beispiel.example/login?returnUrl=/accountinfo zu https://www.beispiel.example/login?returnUrl=http://www.angreifer.example/phishing. Mit AngularJS kann eine Weiterleitung zum Beispiel so implementiert werden:

 var returnUrl = decodeURIComponent($route.current.params.returnUrl);
$location.url(returnUrl);

Was passiert dann bei einem Angriff? Der schlägt fehl: $location.url verarbeitet Pfade, keine absoluten URLs. Der Pfad ist in diesem Fall der Teil nach dem Hashbang (#!). Obiger Aufruf leitet also stets zu https://www.beispiel.example/#!returnUrl weiter. Das funktioniert zwar mit https://www.beispiel.example/#!accountinfo, aber nicht mit https://www.beispiel.example/#!http://www.angreifer.example/phishing, da es diesen Pfad auf dem Server nicht gibt.

Für Weiterleitungen zu einem anderen Server dient unter AngularJS $window.location.href, und damit wäre auch der Redirection-Angriff möglich (sofern das Ziel der Weiterleitung nicht geprüft wird, am besten anhand einer Whitelist zulässiger Ziele). Solange für die lokale Weiterleitung aber $location.url verwendet wird, schlägt zumindest die Weiterleitung zu anderen Servern fehl, und das sogar dann, wenn die eigentlich nötige Prüfung des Ziels vergessen wird.

Sie sollten jedoch sicherheitshalber das Ziel trotzdem prüfen. Denn unerwartete Weiterleitungen können auch dann zum Problem werden, wenn sie innerhalb der eigenen Webanwendung bleiben. Zum Beispiel, wenn dadurch eigentlich nötige Schritte in einem Arbeitsablauf übersprungen werden können. Das Standardbeispiel für einen solchen Angriff ist das Folgende: Im Webshop werden Waren in den Warenkorb gelegt, die Lieferadresse eingegeben, die Zahlung übersprungen und dann die Bestellung abgeschlossen. Erfolgt keine weitere Prüfung, freut sich der Angreifer über die kostenlos gelieferten Waren.

Für weitere Beispiele zum Verhindern von „Unvalidated Redirects and Forwards“ siehe hier und hier.

Fazit

Im Hinblick auf die Sicherheit von AngularJS muss man zwei Aspekte unterscheiden. Erstens: Ist AngularJS sicher? Und zweitens: Sind in AngularJS implementierte Webclients sicher? Die Antwort auf die erste Frage fällt zwiespältig aus: Es gibt ein paar Kritikpunkte hier und hier. Aber zumindest zurzeit sind keine wirklich kritischen Schwachstellen in AngularJS bekannt. Ganz streng genommen ist AngularJS also nicht sicher, aber es ist auch nicht wirklich unsicher. Die entscheidende Frage wäre also: Ist AngularJS sicherer oder unsicherer als die möglichen Alternativen? Hinweise dazu gibt es ebenfalls hier, und AngularJS schneidet im Vergleich nicht so schlecht ab.

Was den Webclient betrifft, kommt es immer darauf an, welche Funktionen er umfasst. Immerhin ist es „nur“ der Client, und alle wirklich sicherheitsrelevanten Entscheidungen müssen sowieso auf dem Server getroffen werden. Denn nichts kann einen Angreifer davon abhalten, manipulierte Requests an den Server zu senden – entweder mithilfe eines manipulierten Clients oder ganz unabhängig davon.

Je mehr Anwendungslogik in den Client ausgelagert wird, desto größer ist dessen Angriffsfläche. Aber mit der Unterstützung der CSP, dem Strict Contextual Escaping (SCE), dem HTML-Sanitizer $sanitize und dem CSRF-Schutz stehen einige gute Schutzmaßnahmen zur Verfügung. Es gibt also keinen Grund, warum ein mit AngularJS realisierter Webclient unsicherer sein sollte als einer, der nur auf normalem JavaScript basiert. Ganz im Gegenteil, denn in JavaScript gibt es kein SCE, kein $sanitize und keinen CSRF-Schutz.

Links & Literatur

[1] Eilers, Carsten: „JavaScript in Angreiferhand“, in: Windows Developer 3.2014

[2] Eilers, Carsten: „JavaScript und die Sicherheit“, in: Windows Developer 12.2014

[3] Eilers, Carsten: „Der Browser im Visier – ganz praktisch“, in: Windows Developer 4.2015

Aufmacherbild:caution sign von Shutterstock.com / Urheberrecht: mstanley

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -