Workshop: Sicheres Programmieren für Administratoren - Folge 4

Die vorige Folge [1] behandelte bereits das Problem der Programmeingaben, die vorliegende konzentriert sich auf Spezialformen, denen Administratoren besonders häufig begegnen. Der Tenor von Folge 3 behält Gültigkeit: Der Entwickler prüfe alle Eingaben und ihre Zusammenhänge sorgfältig - sie gelten bis zum Beweis des Gegenteils als schuldig. Je komplexer die Eingaben, desto wichtiger ist diese Vorsichtsmaßnahme.

Ebenso tritt Whitelisting (nur bekannt gutartige Eingaben akzeptieren) gegenüber dem Blacklisting (nur als bösartig bekannte Eingaben zurückweisen) in den Vordergrund. Je komplizierter das Format der Eingabe, desto aufwändiger und fehleranfälliger ist das Erstellen einer umfassenden schwarzen Liste.

Bei schwierigen Problemen ist die Versuchung groß, die Eingabekontrolle auf nachgeschaltete Programme abzuwälzen ("Das werden die Jungs in der Entwicklung schon richtig machen!"). Dummerweise denken oft alle Beteiligten so und die Lücke bleibt offen. Jeder Admin und jeder Entwickler sollte sich gelegentlich ins Bewusstsein rufen, dass die eigenen Ausgaben immer Eingaben für andere Programme sind, die im Zweifelsfall genauso fehlerhaft wie die eigenen Werke arbeiten. Lieber eine Fehlerquelle mehrfach ausschließen, als sie zu übersehen (Defense in Depth, [1]).

Falle 1: Cross-Site-Skripting

Webseiten entwickeln zählt nicht unbedingt zu den klassischen Aufgaben von Administratoren. Gerade in kleinen und mittelgroßen Firmen werkeln sie dennoch oft an Intranetanwendungen oder am öffentlichen Netzauftritt und unterschätzen die Gefahren in diesem Umfeld. Dazu gehört die spezielle Form der Eingabe: Texte im HTML-Format (oder anderen Websprachen). Hinter der harmlosen Fassade verbirgt sich manchmal bösartiger Javascript-Code.

Das Besondere daran ist, dass das Ziel eines Angreifers nicht der Webserver ist, der das Dokument speichert, sondern der Browser des Besuchers, der es abruft. Beim Cross-Site-Skripting laufen die Skripte des Angreifers auf dem Rechner seines Opfers, während dessen Browser eine andere Präsenz besucht. Das Skript läuft im Kontext und mit den Rechten der besuchten Seite (Abbildung 1).

Ungastliches Gästebuch

In einem einfachen Gästebuch dürfen die Besucher selbst kurze Beiträge schreiben, die auf der Webseite des Gästebuchs erscheinen. Erlaubt der Betreiber beliebige Eingaben, kann ein Witzbold in seinen Beiträgen ein Skript verstecken, das ein fremdes Fenster im Browser des Besuchers öffnet:

Tolle Seite, weiter so!
<!-- <script>
  window.open("http://debian.org/");
</script> -->

Das klingt noch harmlos, aber je nach Webseite stellt der Angreifer noch ganz andere Dinge damit an:

• Er verfälscht oder sabotiert den restlichen Inhalt einer
  Seite,
• stiehlt Cookies mit Session-IDs und gibt sich für den
  Besitzer aus oder
• bringt mit gefälschten Webseiten fremde Passwörter in
  seinen Besitz.

Besonders riskant ist dies auf Seiten, auf denen es um Geld geht, etwa bei Banken oder Online-Casinos. Das Secure Programming Cookbook [3] widmet der Problematik ein ganzes Kapitel mit zahlreichen Beispielen.

Mangelnde Kontrolle von Benutzereingaben macht Cross-Site-Skripting möglich. Webentwickler übersehen das Problem oft, weil ihr Server gar nicht angegriffen wird. Er ist nur das Medium, das die Attacke an arglose Besucher weiterleitet, ohne selbst Schaden zu nehmen. Ähnlich verhält es sich beim Cross-Site-Authentication-Angriff, den ein Beitrag in der "Know-how"-Rubrik behandelt.

Abbildung 1: Der Angreifer schleust ein Skript in einen Forumsbeitrag ein (1), den der Server speichert (2). Beim Abrufen des Forums (3) setzt der Server den Rumpf der Webseite (4a) und die Einträge der Datenbank (4b) zusammen und liefert die Seite an den Besucher (5). Dessen Browser führt das Skript aus.