Websecurity mal anders Marc Ruef | 07.01.2013 Viele Leute können sich nicht vorstellen, wie eine Sicherheitsüberprüfung (http://www.scip.ch/?dienstleistungen.auditing) angegangen wird. Am ehesten kann man noch nachvollziehen, wie eine solche auf ein vernetztes System angewendet wird. Da werden offene Ports gesucht, Anwendungen identifiziert und mögliche Manipulationen angestrebt. Dieses Vorgehen ist weitestgehend bekannt und in unzähligen Fachpulikationen diskutiert worden. Ein bisschen schwieriger wird es jedoch, wenn ein Objekt getestet werden soll, das nicht in dieses klassische Schema fällt. Zum Beispiel dann, wenn der sichere Internet-Zugriff eines Arbeitsplatzrechners untersucht werden soll. Offene Ports interessieren da weniger, da diese mittels Firewalling und NAT nur durch Angreifer im internen LAN erreichbar sind. Und von Netzwerksystemen bekannte Server-Anwendungen werden auch nicht bereitgestellt, da es sich ja in erster Linie um einen Client handelt. Und dennoch unterscheidet sich das Vorgehen in seinen Grundzügen nicht. Auch hier werden Interaktionsmöglichkeiten, mit denen irgendwie das Verhalten des Clients beeinflusst werden kann, gesucht. Ein Client interagiert mit einem Server. Durch entsprechende Anfragen an diesen werden Antworten erhalten, die wiederum verarbeitet werden. Bei Webzugriffen sind das GET-Anfragen über HTTP, die den Download entsprechender Dokumente zur Folge haben. Der offensichtliche Angriffsvektor in dieser Hinsicht manifestiert sich also serverseitig. Der Server kann versuchen, korrupte Antworten zurückzuschicken und damit die Weiterverarbeitung des Clients zu beeinflussen. Überlange Rückantworten könnten eine Pufferüberlauf-Schwachstelle ausnutzen. Ist der Client um das Ablegen etwaiger Daten in einer Datenbank bemüht, könnte eine SQL-Injection zum Zug kommen. Und werden die Daten in einer Webumgebung dargestellt, steht gar Cross Site Scripting zur Diskussion. Die Clients wollen, abgesehen vom schon genannten Firewalling und NAT, vor solchen Übergriffen geschützt werden. Hierzu können Proxies zum Einsatz kommen, die eine Kanalisierung der Kommunikation und damit eine Entkoppelung des Diensts durchsetzen. HTTP-Verbindungen sind dann beispielsweise nur noch über diesen Proxy und zu dessen Bedingungen möglich. Er könnte überlange Anfragen oder Rückantworten erkennen und diese als potentiell gefährlich verwerfen. Oder es werden Einschränkungen für Zugriffe auf Resourcen (URL oder Dateityp) forciert. Die Angreifbarkeit solcher Sicherheitskomponenten entspricht weitestgehend derjenigen der Clients selbst. Auch hier kann also versucht werden, entweder die Sicherheitssysteme direkt anzugreifen oder deren Prüfungen und Einschränkungen zu umgehen. Sie selbst können genauso von Pufferüberlauf-Schwachstellen betroffen sein. Und der Einsatz von Codierungsmechanismen könnte Filter umgehen lassen. Die Sicherheitsüberprüfung einer Client-Umgebung funktioniert also im Prinzip gleich, wie diejenige einer Server-Installation. Halt nur mit vertauschten Rollen, bei denen nicht der Client, sondern der Server als Angriffswerkzeug eingesetzt wird. Dies erfordert ein gewisses Umdenken sowie das symmetrische Verständnis für Funktionsweise und Schwachstellen der eingesetzten Mechanismen. Websecurity besteht beispielsweise nicht nur aus GET und POST, sondern auch aus "301 Moved Permanently" und "Cache-Control: max-age=600".