Wenn Sie heute eine Website veröffentlichen, vergehen kaum ein paar Minuten, bis sie das erste Mal angegriffen werden. Diese Artikelserie beschäftigt sich mit den OWASP Top 10, den zehn meisten Sicherheitsrisiken, und gibt Tipps, wie sie sich und ihre Produkte schützen können.
Diese Serie besteht aus den folgenden Artikeln:
- Teil 1: Injection
- Teil 2: Fehler in Authentifizierung und Session-Management
- Teil 3: Cross-Site Scripting (XSS) (dieser Artikel)
- Teil 4: Unsichere direkte Objektreferenzen
- Teil 5: Sicherheitsrelevante Fehlkonfiguration
- Teil 6: Verlust der Vertraulichkeit sensibler Daten
- Teil 7: Fehlerhafte Autorisierung auf Anwendungsebene
- Teil 8: Cross-Site Request Forgery (CSRF)
- Teil 9: Nutzung von Komponenten mit bekannten Schwachstellen
- Teil 10: Ungeprüfte Um- und Weiterleitungen
Cross-Site Scripting (XSS)
Auf Platz 3 der OWASP Top 10 ist Cross-Site Scripting (XSS). Unter XSS versteht man das Einschleusen von Javascript in eine Webseite. Das Ziel ist meistens, die Session eines anderen Benutzers zu übernehmen.
Es gibt verschiedene Wege, Javascript in eine Webseite einzuschleusen. Eine sehr einfache Möglichkeit ist das Manipulieren von URLs. Auch
Glücklicherweise kann man sich gegen XSS Attacken wehren. Dazu müssen grundsätzlich sämtliche Benutzereingaben validiert werden. Überall dort, wo ein Benutzer einen Text eingeben kann, muss man mit XSS rechnen. Viele Benutzereingaben können Sie mit einfachen Regulären Ausdrücken validieren. Eingaben für E-Mail Adressen und Geburtstage etc. beinhalten eine sehr überschaubare Anzahl Sonderzeichen. Bei Namen wird es schon etwas komplizierter, aber auch das ist machbar.
Duch Clientseitige Validierung können Sie einem Benutzer sehr schnell ein Feedback geben, ob der Text, den er eingegeben hat, gültig ist. Diese Mechanismen kann man jedoch sehr einfach umgehen. Validieren Sie daher sämtliche Benutzereingaben (auch) auf dem Server.
Wenn Sie nicht explizit mit Quellcode rechnen, sondern nur normalen Texteingaben, encodieren Sie sämtliche Benutzereingaben. Aus einem <script>alert(‘xss!’);</script> wird dann ein harmloses <script>alert(‘xss!’);</script>.
Je nach Verwendung des Textes müssen Sie Benutzereingaben unterschiedlich encodieren. Text in einer URL muss anders encodiert werden wie Text, der in HTML angezeigt wird. Wiederum anders in CSS oder JavaScript. Für gängige Programmiersprachen gibt es haufenweise Bibliotheken, auf die Sie für das Encodieren zurückgreifen können. Für die unterschiedlichen Einsatzzwecke stellen diese Bibliotheken dann jeweils andere Methoden zur Verfügung.
Um zu verhindern, dass ihr Session Cookie durch JavaScript ausgelesen werden kann, setzen Sie das “HTTP only” Flag. Sämtliche Cookies, die dieses Flag gesetzt haben, sind vor dem Auslesen durch JavaScript geschützt.
Ist Ihre Anwendung sicher? Nebst der in diesem Blog beschriebenen Möglichkeiten gibt es viele weitere Strategien, sich gegen Angreifer zu verteidigen. Gerne beraten wir Sie in Sicherheitsfragen oder führen ein Security Review in Ihrem Projekt durch. Kontaktieren Sie mich dazu per E-Mail oder rufen Sie mich unverbindlich an, um Ihre dringlichsten Fragen zu besprechen.
Dieser Beitrag erschien zuerst auf michaelschuler.ch.
