Sichere Programmierung von Web-Anwendungen - Open-Redirection
Zahlreiche erfolgreiche Angriffe auf bekannte Web-Anwendungen finden wöchentlich Einzug in einschlägige Medien. Grund genug bei der Entwicklung eigener Anwendung - egal ob zur rein internen Nutzung oder mit öffentlichem Zugang - sich mit den Hintergründen der "Web Application Security" zu beschäftigen.
Dies ist ein Auszug aus dem Buch "Sicherheit von Web-Anwendungen: Für Software-Entwickler und Software-Projektleiter", auch als eBook erhältlich
Es ist ebenfalls ein zugehöriger Online-Kurs erschienen: Onlinekurs Sicherheit von Web-Anwendungen, auch verfügbar auf Udemy, und als HTML5/SCORM/mit Audiokommentar auf Anfrage
Beschreibung
Web-Anwendungen beinhalten oftmals ein Redirecting-Feature, um HTTP-Redirects auszulösen. Dies kann z.B. sinnvoll sein, um nachdem Abschluss einer Zahlung über einen externen Zahlungsdienstleister wieder in den eigenen Web-Shop zurückzukehren.
Beispiel mit Sicherheitslücke:
Lückenhafte Redirect-URLs sehen oftmals so aus:
https://example.com/action/redirect?value=/newpage.html
oder schlimmer
https://example.com/action/redirect?value=https://example.com/newpage.html
Ist die Verarbeitung des Parameters mit dem Redirect-Ziel ungesichert, kann ein Angreifer seine eigene Seite als Ziel einschleusen:
https://example.com/action/redirect?value=https://xxx.com/newpage.html
Links dieser Art sehen zunächst ungefährlich aus, da sie von der eigentlichen Web-Anwendung kommen.
Durch die Weiterleitung auf maliziöse Seiten, sind einem Angreifer jedoch keine Grenzen gesetzt. Neben dem direkten Weiterleiten auf eine Seite mit Browser-Exploits, ist auch eine Fälschung der ursprünglichen Seite mit dem Ziel der Erbeutung von Nutzerdaten möglich usw.
Um Nutzern der Web-Anwendung derartige Links unterzuschieben, können z.B. zentrale Foren oder auch andere Kanäle wie Phishing-Mails genutzt werden (vgl. Kapitel "Hacking-Anatomie").
Sichere Programmierung:
Redirects sollten soweit möglich statisch programmiert sein.
Insbesondere dürfen keine nutzerbasierten, variablen Eingabedaten für Redirects verwendet werden können.
1) Lokale Redirects
Ein lokaler Redirect ist eine Weiterleitung auf eine Ressource unter der eigenen URL.
a)
Im besten Fall hat dieser keinen Parameter und sieht so aus:
https://example.com/action/redirectContextXY
b)
Eine weitere Ausbaustufe ist die Nutzung von tabellarisch explizit zugeordneten Redirect-Zielen. D.h., über einen Parameter wird - etwa aus einer Datenbank - das Redirect-Ziel serverseitig gesetzt:
Tabelle "REDIRECT"
ID DEST
---------------------
200 success.html
210 error.html
220 cancel.html
Die zugehörige URL würde dann beispielsweise so aussehen:
https://example.com/action/redirect?id=210
c)
Ist eine statische Programmierung nicht möglich, sondern muss ein offener Parameter verwendet werden, so ist per Whitelist-Filterung sicherzustellen, dass
- nur gültige, lokale Pfade angegeben werden
- keine Steuerzeichen (z.B. für eine Header-Injection) im Parameter übergeben werden
2) Externe Redirects
Sollte die Web-Anwendung externe Redirects erfordern, also Weiterleitungen an andere Domains vornehmen müssen, so muss dies entweder statisch (z.B. tabellarisch wie unter 1b) oder per Whitelisting erfolgen! D.h., die Liste der URLs an die weitergeleitet wird, muss explizit definiert und freigegeben sein.
Eine offene Schnittstelle, an die Angreifer ihre eigenen Domains senden können, darf nicht genutzt werden.
Schlagworte
Sicherheitslücke, Open Redirect, Open-Redirection, Secure Code, Secure Coding, Java, PHP, C#, OWASP, Sichere Programmierung, Web-/Anwendungssicherheit, Secure Programming, Web Application Security, Softwarentwicklung, IT-Securitymanagement, Security Awareness
Kategorien: IT-Sicherheit Hintergrundartikel Programmieren/Java
Kommentare
Eigenen Kommentar hinzufügen
Teilen / Weiterempfehlen
Wenn Sie diese Seite gut finden, teilen Sie es doch ihren Kontakten mit:
reddit
Digg
StumbleUpon
XING
WhatsApp
Telegram