Websicherheit und OWASP — die Fehler, nach denen Angreifer suchen

Jede Webanwendung, die zum Internet hin offen ist, wird rund um die Uhr von automatischen Werkzeugen und neugierigen Menschen abgeklopft. Sicherheit ist deshalb nichts, woran man denkt, wenn die Seite fertig ist — sie ist eine Art, von der ersten Zeile an Code zu schreiben. Eine gute Richtschnur ist OWASP (Open Worldwide Application Security Project), eine Non-Profit-Organisation, die eine breit anerkannte Liste herausgibt, die OWASP Top 10, über die kritischsten Sicherheitsrisiken in Webanwendungen. Sie ist kein Gesetz, aber die gemeinsame Grundlage, von der aus die Branche spricht.

Der rote Faden durch fast alle Web-Schwachstellen ist das Vertrauen in Daten, die von außen kommen. Alles, was vom Browser kommt — Formularfelder, die Adresszeile, Parameter, Cookies, Header —, kann manipuliert sein. Ein Angreifer benutzt nicht unbedingt deine schöne Oberfläche; er schickt die Daten direkt an den Server. Deshalb müssen alle Eingaben auf dem Server validiert und bereinigt werden, bevor sie benutzt, gespeichert oder wieder angezeigt werden. Validierung im Frontend ist eine Hilfe für den ehrlichen Benutzer, kein Schutz gegen den unehrlichen.

Der verbreitetste schwerwiegende Fehler ist, dass die Zugriffskontrolle umgangen werden kann: Ein Benutzer kann etwas sehen oder ändern, was er nicht dürfte. Ein klassisches Beispiel ist, dass man eine ID in der Adresszeile ändern und die Daten eines anderen sehen kann, weil der Server nicht prüft, ob der angemeldete Benutzer sie tatsächlich besitzt. Die Regel lautet: Jede einzelne Aktion muss auf dem Server prüfen, ob der aktuelle Benutzer berechtigt ist — es reicht nicht, eine Schaltfläche in der Oberfläche auszublenden. Geh davon aus, dass alles, was nicht ausdrücklich geprüft wird, offen ist.

Injection entsteht, wenn Daten des Benutzers als Teil eines Befehls statt als reine Daten interpretiert werden. Der klassische Fall ist eine Datenbankabfrage, bei der der Text des Benutzers direkt in die Abfrage eingesetzt wird, sodass ein Angreifer ändern kann, was die Abfrage tut. Die Abwehr besteht darin, Code von Daten zu trennen: Verwende parametrisierte Abfragen (auch Prepared Statements genannt), bei denen die Eingabe des Benutzers immer als Wert und niemals als Befehl behandelt wird. Derselbe Gedanke gilt überall dort, wo Eingaben in einem Befehl landen — du musst das Prinzip verstehen, nicht das einzelne System.

XSS entsteht, wenn der Text eines Angreifers auf der Seite angezeigt und im Browser eines anderen Benutzers als Code ausgeführt wird — zum Beispiel über einen Kommentar, der ein Skript enthält. Das Ergebnis kann sein, dass der Angreifer Sitzungen stiehlt oder im Namen des Opfers handelt. Die Verteidigung besteht darin, jeden Benutzerinhalt bei der Anzeige als Text zu behandeln: maskiere ihn korrekt, sodass Zeichen als Zeichen dargestellt und nicht ausgeführt werden. Nutze die Mechanismen, die dein Framework für sichere Ausgabe bietet, statt rohen Text direkt in die Seite einzusetzen.

Die Liste fasst die wiederkehrenden Risiken in Kategorien zusammen. Du musst sie nicht auswendig können, aber sie sind eine gute Prüfgrundlage, wenn du eine Anwendung durchgehst.

Speichere Passwörter niemals im Klartext. Sie müssen mit einem Algorithmus gehasht werden, der für diesen Zweck gebaut und bewusst langsam ist, und mit Salt, damit gleiche Passwörter nicht denselben Hash ergeben. Sitzungen müssen so geschützt sein, dass sie nicht gestohlen oder erraten werden können, und eine Sitzung muss ablaufen und beim Abmelden beendet werden können. Zugangsschlüssel, API-Schlüssel und andere Geheimnisse gehören niemals in den Frontend-Code oder in die Versionsverwaltung — sie gehören auf den Server, außerhalb dessen, was der Nutzer sehen kann.

Keine einzelne Gewohnheit macht eine Anwendung sicher. Es ist die Summe: Validiere auf dem Server, prüfe die Berechtigung bei jeder Aktion, trenne Code von Daten, zeige Benutzerinhalte als Text an, halte Abhängigkeiten aktuell, schütze Login und Geheimnisse und logge genug, um einen Angriff bemerken zu können. Machst du das zu Rückenmarksreflexen, schließt du die meisten der Lücken, vor denen die Liste der OWASP warnt — lange bevor ein Angreifer sie findet.

“Sichere Webanwendungen entstehen nicht dadurch, dass man Sicherheit zum Schluss hinzufügt, sondern dadurch, dass man jeder Eingabe von der ersten Codezeile an misstraut.”

— Gängige Faustregel in der Web-Sicherheit