Security in Webanwendungen Teil 2: Programmierung von sicheren Webapplikationen

30.01.2014

Hacker programing in technology enviroment with cyber icons

Im ersten Teil dieser Blogserie beschäftigten wir uns dem Design von sicheren Webanwendungen. In diesem Beitrag geht es darum, wie solche sicheren Webapplikationen programmiert werden können.

Escaping von Metazeichen

Jede Auszeichnungs- oder Abfragesprache hat ihre eigenen Metazeichen, die für die jeweilige Sprache eine spezifische Bedeutung haben und entsprechend interpretiert werden. Durch die Eingabe einer Zeichenkette mit den entsprechenden Metazeichen könnte ein Angreifer beispielsweise dafür sorgen, dass innerhalb der Datenbank Tabellen gelöscht, Benutzerdaten und Passwörter verändert oder sogar ausgegeben werden (Stichwort: SQL-Injection). Durch geschickte Eingaben, die Metazeichen von HTML oder JavaScript enthalten, ist es außerdem möglich, dass anderen Benutzern ungewollte Eingabefelder angezeigt werden. Diese Eingabefelder werden vom arglosen Benutzer höchstwahrscheinlich mit vertraulichen Daten wie Kennwörtern, PINs und Kontonummern versehen, die anschließend an einen Server des Angreifers übertragen werden. Und schon befinden sich die sensiblen Daten außerhalb der eigenen Kontrolle.

Des Weiteren hat der Angreifer die Möglichkeit, die Sitzungsnummer des Benutzers in Erfahrung zu bringen und anschließend Aktionen unter dem Vorspielen einer anderen Identität durchzuführen. Das Manipulieren von Webseiten mit HTML und JavaScript wird in Fachkreisen „Cross-Site-Scripting“ kurz XSS genannt.

Um das Manipulieren von Abfragen und Ausgaben zu verhindern, müssen die entsprechenden Metazeichen bei der Ausgabe an das Zielsystem (Browser, Datenbank) ein passendes Escaping durchlaufen. So werden die Metazeichen nicht mehr als solche erkannt. Das Escaping von solchen Metazeichen kann sehr komplex werden. Darum empfiehlt sich die Nutzung einer Bibliothek, die ausreichend getestet wurde.

Nutzung eines Sicherheitstokens

Um zu verhindern, dass ein Angreifer mithilfe einer per Cross-Site-Scripting erbeuteten Sitzungsnummer im Hintergrund sofort eine Aktion ausführen kann, wird ein sogenannter Page-Token verwendet. Der Page-Token ist eine sehr schwer zu erratende Zeichenkette, die in einem Formularfeld vom Typ „hidden“ in der Webseite ausgeliefert wird. Der Angreifer kann dieses Feld nicht ohne weiteres auslesen. Sendet der Nutzer nun die Antwort an den Server, kann dieser das Token prüfen. Ist das gespeicherte und das empfangene Token identisch, sind die empfangenen Daten vertrauenswürdig. Denn ein Angreifer wäre nicht im Besitz dieses Tokens und könnte auch keine gültige Antwort an den Server senden.

Zugriff auf das Session Cookie beschränken

Damit ein Angreifer die Sitzungsnummer nicht per JavaScript über den Browsers des normalen Benutzers auslesen kann, gibt es die Möglichkeit den Zugriff auf das Sitzungscookie nur auf die HTTP-Ebene zu beschränken. Somit kann es über JavaScript nicht ausgelesen werden.

Um dieses Verhalten in einer Java-Webapplikation umzusetzen, muss innerhalb der Anwendung im Verzeichnis „WebContent/META-INF“ die Datei „context.xml“ angelegt werden und folgenden Inhalt haben:

<Context useHttpOnly="true">
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<Manager pathname="" />
<Valve className="org.apache.catalina.valves.CometConnectionManagerValve" />
</Context>

Im oben dargestellten Inhalt wurde das Attribut “useHttpOnly” im Element „Context“ auf den Wert „true“ gesetzt. Dies stellt sicher, dass das Sitzungscookie nicht über JavaScript ausgelesen werden kann.

Austausch der Sitzung

Viele Webapplikationen besitzen die Möglichkeit sich „einzuloggen“ oder auf eine andere Art und Weise ein höheres Vertrauens- und Sicherheitslevel zu erlangen. Sollte es einem Angreifer gelungen sein die Sitzungsnummer (Session-ID) eines nicht angemeldeten Benutzers zu erlangen, hat er die Gelegenheit über seinen Browser die Webapplikation mit der Sitzung des bestohlenen Nutzers zu verwenden. Wenn nun eine Webapplikation die Sitzung nach dem Anmelden des ahnungslosen Nutzers nicht austauscht, könnte der Angreifer die Webapplikation mit den erweiterten Rechten nutzen und Aktionen im Namen eines anderen durchführen. Der rechtmäßige Nutzer merkt von all dem nichts. Darum müssen die Sitzungen nach dem Erlangen einer anderen Sicherheitsstufe unbedingt ausgetauscht und die alte Sitzung beendet werden.

Durch die beschriebenen Maßnahmen beim programmieren von Webapplikationen kann die Sicherheit maßgeblich erhöht werden. Lesen Sie im nächsten Teil unserer Blogserie kommende Woche, wie ein sicherer Betrieb von Webapplikationen möglich ist.

Hier geht es zum ersten Teil der Blogserie Design von sicheren Webanwendungen.

Zurück zur Übersicht

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*