Sicherheit in Angular-Anwendungen

Sicherheit in Angular-Anwendungen

0:00 Die gute Nachricht zuerst: Angular schützt zuverlässig. Sie müssen dafür nichts einschalten und nichts konfigurieren — es ist der Normalzustand. Die schlechte: Der Schutz lässt sich ausdrücklich abschalten, und genau das ist in fast jeder gewachsenen Anwendung irgendwo passiert. Meistens mit guter Absicht, oft vor Jahren, und niemand weiß mehr warum.

0:20 In diesem Modul suchen wir solche Stellen, bewerten sie und entscheiden — und schauen uns an, wo die Grenzen der Zuständigkeit verlaufen.

Rendering, Performance und Sicherheit

0:29 Das ist das letzte Modul des fünften Tages. Nach Auslieferung und Performance jetzt das dritte Thema, bei dem Annahmen gefährlich sind — und bei dem eine falsche Annahme deutlich teurer werden kann als bei den anderen beiden.

Der eingebaute Schutz bei Template-Werten

0:42 Fangen wir mit dem an, was Angular für Sie tut. Denn um das zu würdigen, muss man wissen, wie viel Arbeit es ist, wenn man es selbst macht. Angular behandelt jeden Wert als nicht vertrauenswürdig und bereinigt ihn je nach Kontext — HTML, Style, URL und Ressourcen-URL werden unterschiedlich behandelt. Interpolierte Werte werden immer maskiert und nie als HTML gedeutet. Bei einer Bindung an den HTML-Inhalt entfernt Angular gefährliche Elemente und behält unbedenkliche.

1:10 Und eine Einschränkung, die man kennen muss: Ressourcen-URLs lassen sich nicht bereinigen, weil sie beliebigen Code laden können. Da hilft nur, sie nicht aus fremden Quellen zu nehmen. Die Gegenüberstellung ist einfach und die Konsequenz wichtig. Links die Interpolation: immer maskiert, zeigt Markup als Text, ohne Risiko — der Normalfall.

1:32 Rechts die Bindung an den HTML-Inhalt: wird als HTML gedeutet, Angular entfernt das Gefährliche, ein Restrisiko bleibt. Die letzte Zeile ist die Empfehlung: Normalfall links, Ausnahme mit Begründung rechts. Und die Betonung liegt auf „mit Begründung" — nicht, weil rechts verboten wäre, sondern weil es eine Entscheidung ist und keine Gewohnheit.

1:54 Der erste Punkt ist der, der gut gemeint ist und schadet: Eine eigene Bereinigung ersetzt die eingebaute und ist schwächer. Diese Funktionen sehen einfach aus und sind es nicht — es gibt sehr viele Wege, etwas als HTML zu schmuggeln. Der zweite ist Bequemlichkeit: Die HTML-Bindung wird verwendet, wo Interpolation genügt hätte.

2:14 Und der dritte ist ein Irrtum mit Folgen: Eine Ressourcen-URL wird als bereinigbar angenommen. Wird sie nicht, und die Fehlermeldung sagt das auch.

Vertrauensausnahmen prüfen

2:23 Jetzt zum Kern dieses Moduls: die Stellen, an denen jemand den Schutz bewusst abgeschaltet hat. Es gibt fünf Funktionen, mit denen sich der Schutz umgehen lässt — für HTML, Skripte, Styles, URLs und Ressourcen-URLs. Die Angular-Dokumentation kennzeichnet sie ausdrücklich als Sicherheitsrisiko und formuliert ungewöhnlich deutlich: Wer einem möglicherweise bösartigen Wert vertraut, führt eine Schwachstelle ein.

2:48 Das ist keine Warnung im Kleingedruckten, das ist der Hinweis im Fettdruck. Jede solche Stelle gehört bis zur Quelle des Werts zurückverfolgt — und zwar bis zum Ursprung, nicht bis zur nächsten Funktion. Fünf Schritte, und Schritt drei ist die Frage, die alles entscheidet: Kann ein Benutzer den Wert beeinflussen? Wenn ja, ist die Ausnahme eine Schwachstelle, egal wie gut sie gemeint war. Dann bleiben zwei Möglichkeiten: entfernen oder die Eingabe eng begrenzen.

3:16 Wenn nein — etwa bei einer festen Zeichenkette im Code — dokumentieren Sie sie mit Begründung und Datum. Die Fußzeile sagt, warum das nötig ist: Eine Ausnahme ohne dokumentierten Grund ist beim nächsten Review nicht mehr bewertbar. Dann fängt jemand wieder von vorn an. Vier Herkünfte, und nur die letzte ist harmlos. Aus einem Feld, das ein Benutzer ausfüllt — beeinflussbar.

3:39 Aus einer Schnittstelle, die selbst Benutzereingaben weiterreicht — beeinflussbar, und das übersieht man leicht, weil die Schnittstelle ja intern ist. Aus einer Konfiguration, die jemand ändern kann — beeinflussbar. Und aus einer festen Zeichenkette im Code: der einzige Fall, in dem eine Ausnahme unbedenklich ist. Wenn Sie die Kette zurückverfolgen und bei einem Eingabefeld landen, ist die Bewertung fertig.

4:05 Der erste Punkt ist der häufigste Entstehungsweg: Die Ausnahme wird für einen Testfall eingebaut und bleibt stehen. Jemand wollte schnell etwas ausprobieren, es funktionierte, und es ging in Produktion. Der zweite ist die Argumentation, die ich am häufigsten höre und die nicht trägt: Die Quelle gilt als vertrauenswürdig, weil sie intern ist.

4:24 Und der dritte ist ein technischer: Trusted Types sind aktiv, und die Ausnahme fällt erst im Betrieb auf — im Entwicklungsmodus lief alles.

Authentifizierung und Autorisierung einordnen

4:33 Kommen wir zu der Grenze, die ich in Modul neun schon angesprochen habe und die hier ihren eigentlichen Platz hat. Alles, was im Browser läuft, lässt sich dort ändern. Guards und ausgeblendete Knöpfe steuern den Bedienfluss und ersetzen keine Prüfung auf dem Server. Was Angular Ihnen dagegen wirklich abnimmt: Der Datenzugriff schützt mutierende Anfragen gegen Cross-Site Request Forgery — er liest das entsprechende Cookie und setzt den passenden Kopf.

4:59 Für lesende Anfragen ist das nicht nötig, weil sie keinen Zustand ändern. Das läuft ohne Zutun, solange Ihr Server die üblichen Namen verwendet. Drei Zeilen, und lesen Sie die Spaltenüberschriften als Zuständigkeiten. Der Browser zeigt an, blendet aus, stellt dar. Der Server prüft, entscheidet, liefert nur Erlaubtes. Die dritte Zeile ist die, die am häufigsten verletzt wird: Welche Daten sichtbar sind, entscheidet der Server, indem er nur die erlaubten liefert.

5:28 Nicht der Browser, indem er Felder ausblendet. Ein ausgeblendetes Feld steht trotzdem in der Antwort, und die kann jeder ansehen, der die Entwicklerwerkzeuge öffnet. Der erste Punkt ist der, der als Sicherheitslücke durchgeht: Der ausgeblendete Knopf gilt als Schutz der Aktion. Er ist eine Bequemlichkeit für den Benutzer, sonst nichts.

5:49 Der zweite ist die Variante davon eine Ebene tiefer: Rollen stehen im Browser und werden dort ausgewertet. Und der dritte ist genau die dritte Tabellenzeile: Die Schnittstelle liefert mehr Felder, als die Rolle sehen darf. Das ist besonders unangenehm, weil es keine Lücke ist, die jemand ausnutzen müsste — die Daten sind einfach da.

Sensible Daten an Systemgrenzen

6:09 Zum Abschluss der Blick auf die Stellen, an denen Daten austreten, ohne dass es jemand beabsichtigt hat. Alles, was der Build ausliefert, ist lesbar — das hatten wir in Modul zwei. Schlüssel und Geheimnisse gehören auf den Server. Fehlermeldungen sollen dem Benutzer helfen, ohne interne Details preiszugeben. Und in Ansichten und Ausgaben gilt Datensparsamkeit: Was nicht gebraucht wird, wird nicht geladen und nicht angezeigt.

6:34 Das klingt nach Selbstverständlichkeit und ist es nicht — die meisten Schnittstellen liefern das ganze Objekt, weil das einfacher war. Vier Stellen, und der zweite ist der, der in unserem Projekt tatsächlich aufgetreten ist: Ein Protokollaufruf schreibt eine vollständige Antwort mit. Der Interceptor sollte beim Debuggen helfen, blieb drin, und schrieb fortan Namen, Kennzeichen und Notizen ins Protokoll.

6:59 Der dritte ist der, den jeder Benutzer schon gesehen hat: Eine Fehlermeldung nennt Tabellennamen und Pfade. Und der vierte ist der stille: Ein Export enthält Felder, die in der Ansicht längst ausgeblendet waren. Der erste Punkt ist der eben beschriebene Protokoll-Fall — und er ist besonders häufig, weil die Protokollierung meistens früh eingebaut und nie wieder angesehen wird.

7:21 Der zweite ist der ungefilterte technische Fehlertext in der Oberfläche, der dem Benutzer nichts sagt und einem Angreifer einiges. Und der dritte ist die halbe Datensparsamkeit: Die Ansicht blendet Felder aus, die Antwort enthält sie weiterhin. Das ist keine Datensparsamkeit, das ist eine Anzeigeeinstellung.

Übung

7:39 Nehmen wir uns eine echte Ausnahme vor — eine, die seit zwei Jahren im Code steht und deren Urheber längst in einem anderen Projekt ist. In Spurweite können Monteure eine Notiz zum Auftrag erfassen. Damit Formatierungen möglich sind, wird die Notiz in der Detailansicht als HTML eingebettet — über eine Vertrauensausnahme, die vor zwei Jahren jemand eingebaut hat.

8:00 Der Text stammt aus einem freien Eingabefeld. Sie haben jetzt alles, was Sie zur Bewertung brauchen, und ich möchte, dass Sie die Kette selbst zurückverfolgen, statt mir zu glauben. Das Lernziel ist das Zurückverfolgen selbst — eine bestehende Ausnahme bis zur Quelle verfolgen und begründet entfernen oder begrenzen. Das Erfolgskriterium hat drei Teile, und der dritte ist der, der die Übung schwer macht: Die Notiz wird weiterhin lesbar dargestellt.

8:26 Sie dürfen also nicht einfach die Funktion streichen und das Ergebnis dem Benutzer zumuten. Wer früh fertig ist, prüft die Fehlermeldungen der Detailansicht auf interne Details — und wird dort vermutlich ebenfalls fündig. Schritt eins und zwei sind Detektivarbeit: die Ausnahme finden und die Quelle verfolgen. Schritt drei ist die Frage, die entscheidet.

8:47 Und Schritt vier ist der, an dem sich zeigt, ob Sie gründlich waren: Prüfen Sie, ob Interpolation den Zweck ebenfalls erfüllt. In den meisten Fällen — und in diesem auch — bestand die Formatierung, um die es ging, aus etwas, das CSS ebenso kann. Dann ist die Entscheidung einfach. Und Schritt fünf hält sie fest, mit Grund und Datum.

9:08 Der erste Punkt ist die Begründung, mit der solche Ausnahmen überleben: Sie bleibt, weil die Formatierung sonst verloren ginge. Prüfen Sie das — oft stimmt es nicht. Der zweite ist die Argumentation von vorhin: Die Quelle gilt als vertrauenswürdig, weil nur Mitarbeitende schreiben. Ein übernommenes Konto reicht. Und der dritte ist der, der die Arbeit in zwei Jahren wiederholen lässt: Die Entscheidung wird umgesetzt, aber nicht dokumentiert.

9:35 Morgen ist der letzte Tag: Modernisierung, KI-gestützte Entwicklung und der Abschluss.