Cross-Site-Scriting
Cross-Site Scripting beruht in aller Regel auf der Anzeige von Fremddaten. Die generelle Empfehlung, durch Benutzern übergebenen Daten nicht zu vertrauen kann von daher nicht oft genug wiederholt werden. Zu den Fremddaten muss dabei alles gerechnet werden, was der Browser ausliefert und aus fremden Quellen/Eingaben stammt.
Die Gefahr liegt dabei wohlgemerkt weniger im Vertrauen sondern vielmehr in der fehlenden/fehlerhaften Validierung der Daten - die Benutzer vertrauen auf die Seite und Cross-Site Scripting mißbraucht dieses Vertrauen.
Für Cross-site Scripting (auch als HTML-, JavaScript- und User-Agent Injektion bekannt) gibt es bei PHP drei verschiedene Varianten: reflected, persistent und DOM Injektion.
- Reflected:
Der Angreifer nutzt z.B. einen entsprechend präparierten Link der innerhalb der Applikation die aktiven Inhalte zur Ausführung bringt.
- Persistent:
Der Angreifer speichert entsprechende Inhalte direkt in der Datenbank bzw. dem Filesystem der Präsenz ab, die aktiven Inhalte werden danach bei allen Besuchern des entsprechenden Bereiches zur Ausführung gebracht.
- DOM:
Der Angreifer benutzt direkt Schwachstellen innerhalb der JavaScript DOM um reflected Cross-Site Scripting auszuführen.
Für einen Cross-Site-Scripting-Angriff benötigt der Angreifer also in aller Regel eine Anwendung, die Eingaben nicht ausreichend prüft, bevor sie sie als Bestandteil einer dynamischen Webseite an den Benutzer zurückgibt.
Um Cross-Site Scripting zu verhindern gibt es einige Grundregeln:- Fremddaten validieren
Die wahrscheinlich wichtigste Regel: alle Daten die von extern übermittelt werden, müssen vor der weiteren Verwendung und Anzeige geprüft werden. - PHP-Funktionen strip_tags(), htmlspecialchars(), htmlentities() nutzen
Während strip_tags() versucht, alle HTML-Tags zu löschen, wandeln htmlspecialchars() und htmlentities() bestimmte oder alle Zeichen in die entsprechenden Entitäten um. Aus den Zeichen '<' und '>' zur Kennzeichnung von HTML-Tags werden so die entsprechenden HTML-Entitäten '<' und '>'. - nur sichere Inhalte erlauben
Inhalte immer gegen eine Whitelist abgleichen, Blacklisting ist im Hinblick auf die Vielzahl der XSS-Möglichkeiten nahezu aussichtslos.
Cross-Site Request Forgeries
Cross-Site Request Forgeries (CSRF) sind gewissermassen das Gegenstück zu XSS. Während Cross-Site Scripting wie oben beschrieben auf das Vertrauen des Nutzers in die Seite setzt, wird bei CSRF veruscht, das Vertrauen der Webseite in den Benutzer auszunutzen.
Da CSRF auf geänderten HTTP-Anforderung beruht zuerst ein kurzer Überblick darüber: Das Web beruht auf der Server-Client Umgebung; Benutzer fordern bei Webservern Daten über das sog. HTTP-Protokoll an. Innerhalb der Protokoll-Anforderungen war es lange Zeit möglich, 'versteckte' Optionen einzuschmuggeln. Während XSS also z.B. versucht, Cookies zu stehlen wird bei CSRF beispielsweise versucht den Cookie zu mißbrauchen um ungewollte Aktionen auszuführen.
Schutzmaßnahmen gegen CSRF
- POST Formulare benutzen
Parameter-Übergaben in Formularen sind zwar ebenfalls nicht 100% sicher, machen in aller Regel aber Mißbrauchsversuche wesentlich deutlicher - $_POST anstelle von $_REQUEST (und natürlich erst recht register_globals)
Bei der Übernahme von Variablen sollte immer nur die erwartete Quelle ($_POST, $_GET, $_COOKIE) ausgewertet werden - Komplexe Aktionen in Einzelbestandteile zerlegen
Es ist wesentlich schwieriger mehrere aufeinanderfolgende POST-Formulare via CSRF anzugreifen als nur ein einziges - Herkunft von Formulardaten überprüfen
Wenn bei der Anzeige eines Formulars ein zusätzlicher Hash.Wert generiert wird der bei der Auswertung überprüft wird kann das Risiko auf externe Ausnutzung verringert werden
