InhaltsverzeichnisArtikel
Unerwünschte Werbung in E-Mails, Foren oder Gästebüchern sind ein aktuelles Thema. In diesem Abschnitt wird erläutert, was man darunter versteht und es werden einige Methoden erläutert, mit denen Dritte "Spamming" oder "Flooding" betreiben. Anschließend wird gezeigt, auf welche Weise in diesem Framework versucht wird, diesen Bedrohungen zu begegnen.
Zwischen "Spam" und "Floods" gibt es trotz oberflächlicher Ähnlichkeiten einen feinen Unterschied, welcher im Folgenden dargelegt wird.
Unter "Spam" versteht man die mehrmalige, unaufgeforderte Übermittlung von medialen Inhalten an eine Person oder eine Gruppe von Personen. Beispielsweise das unaufgeforderte Versenden von E-Mails mit Werbeinhalten an Dritte. Aber auch massenhafte, unaufgeforderte Anrufe sind eine Form von "Spam". Der Versand von Spam ist in vielen Ländern (darunter Europa und die USA) illegal und wird strafrechtlich verfolgt.
Die Webseite "spamhaus.org" definiert "Spam" wie folgt.
The word " Spam " as applied to Email means Unsolicited Bulk Email ("UBE").
A message is Spam only if it is both Unsolicited and Bulk.
Unter " Flooding " versteht man das mutwillige, unaufgeforderte "überfluten" eines Mediums mit Inhalten. Floods zielen darauf ab, den normalen Betrieb eines Mediums zu stören. Beispielsweise das massenhafte Veröffentlichen sinnfreier Texte in einem öffentlichen Forum. Aber auch eine Person, welche eine öffentliche Veranstaltung durch permanente Zwischenrufe stört, betreibt dem Grunde nach eine Form von Flooding. Flooding kann in einigen Fällen illegal sein. Beispielsweise dann, wenn ein wirtschaftlicher Schaden entsteht.
In der Regel wird "Spam" mit der Intention erstellt, Werbebotschaften zu vermitteln. Wohingegen "Floods" meist eher eine Form von Vandalismus darstellen.
Ein zunehmendes Problem stellt der Spam in Foren und Gästebüchern dar. Aber auch Blogs und Wikis sind betroffen. Meist werden solche Einträge zwar schnell aufgespürt und wieder entfernt, aber die Beseitigung unerwünschter Einträge dieser Art kostet Zeit und Geld. Im Folgenden Abschnitt wird beschrieben, auf welche Weise ein Angreifer dabei vorgehen könnte und es werden Mittel und Wege aufgezeigt, dem angemessen zu begegnen.
Der Angreifer geht dabei wie folgt vor. Zunächst sucht er ein anfälliges Skript eines Gästebuches oder Forums, welches eine ausreichend große Verbreitung im Internet besitzt. Er untersucht die Formulare zum Erstellen neuer Einträge und notiert die Bezeichnungen der erforderlichen Formularfelder. Der Angreifer späht bestimmte typische Texte innerhalb der Anwendung aus. Unter Verwendung dieser Texte als Suchbegriffe, findet er bei Suchdiensten Webseiten, auf denen das Skript installiert ist.
Der Angreifer erstellt eine Liste der URLs dieser Seiten, welche er in einer Datei ablegt. Mit Hilfe eines kurzen Programms trägt er, beispielsweise über einen anonymen Proxyserver, asynchron in einer einfachen Schleife Werbebotschaften in alle Formulare der Liste ein.
Wenn der Angreifer Glück hat, indexieren obendrein Suchmaschinen wie Google diese Seiten bevor der zuständige Administrator die Werbung entfernt. Auf diese Weise erhöhen in die Werbebotschaft eingebettete Hyperlinks obendrein den PageRank der so beworbenen Internetangebote, was dazu führen kann, dass diese bei Suchmaschinen leichter auf den vorderen Plätzen landen.
Es gibt mehrere Methoden solche Angriffe abzuwehren.
Die einfachste Möglichkeit besteht darin, schlicht und ergreifend die URL zu ändern. Üblicherweise arbeiten die Skripte der meisten Angreifer asynchron. Es fällt dem Angreifer somit in der Regel nicht sofort auf, wenn eine Webseite nicht mehr erreichbar ist. Es ist davon auszugehen, dass der Angreifer um die URL zu korrigieren entweder auf das Update der Suchmaschine wartet, was durchaus 8 Wochen dauern kann, oder die Webseite selbst erneut besuchen und den neuen Link von Hand extrahieren muss. In beiden Fällen sollte das Opfer vorübergehend Ruhe vor dem Angreifer haben.
Für das Framework ist das Ändern der URL ohne Schwierigkeiten möglich. Das ist deshalb so einfach, weil das Framework beliebig viele durch eine ID-Kennung identifizierte Instanzen der installierten Anwendungen beziehungsweise Plugins in Form von "Konfigurationsprofilen" verwalten kann. Welche Profile aktiv sind und welche nicht, erschließt sich jedoch nur für den Webmaster selbst und nicht für den außenstehenden Nutzer.
Um die URL einer Anwendung zu ändern muss folglich lediglich das betroffene Profil umbenannt und neu verlinkt werden. Dies ist eine Frage von wenigen Minuten. Der positive Nebeneffekt besteht darin, dass der Angreifer selbst bei synchroner Übertragung, oder bei Prüfung der URL über ein automatisches Programm keinen Fehler 404 (Seite nicht gefunden) vom Server erhält. Selbst bei einer manuellen Prüfung bemerkt er durch einen direkten Aufruf der URL nicht, dass er ein inaktives Profil vor sich hat. Er wird je nach Konfiguration des Frameworks weiterhin Formulare aufrufen und (sofern das Profil nicht schreibgeschützt ist) Beiträge schreiben können.
Aus persönlicher Erfahrung kann ich berichten, dass sich Angreifer auf diese einfache Weise leicht monatelang in die Irre führen lassen, ohne ihren Fehler zu bemerken.
Eine weitere Maßnahme ist das Sperren von IPs oder IP-Blöcken. Das ist vor allem dann hilfreich, wenn der Angreifer stets die gleichen Proxyserver für seine Angriffe verwendet. Leider ist dies nicht häufig der Fall. Nichtsdestotrotz wurde diese Möglichkeit für das Framework berücksichtigt und eine entsprechende optionale Funktion eingebaut. Diese Funktion kann zudem auch dazu verwendet werden, bei Anwendungen in einem lokalen Netzwerk mit Zugang zum Internet den Zugriff auf die Anwendung auf das lokale Netzwerk zu beschränken und Zugriffe aus dem Internet zu untersagen.
Um von vorn herein zu verhindern, dass ein Angreifer mit einem automatischen Programm Einträge verfassen kann, gibt es die Möglichkeit in potentiell gefährdete Formulare Grafiken mit kombinierten Zahlen- und Buchstaben-Codes einzubauen. Um einen Eintrag schreiben zu können, muss der Besucher den eingeblendeten Code abtippen. Was für einen menschlichen Betrachter eine leichte Übung ist, gestaltet sich für ein automatisches Programm deutlich schwieriger.
Die Probleme welche sich für den Angreifer daraus ergeben sind vielfältig. Sein Programm muss zunächst erst einmal den aktuellen Code vom Server holen – selbst wenn es gelingt den Code zu extrahieren kostet dies in jedem Fall Zeit. Eine asynchrone Kommunikation ist daher nicht mehr möglich: die Anfrage muss gesendet und der Code muss empfangen werden. Dadurch besteht aber auch das Risiko, dass das Programm möglicherweise durch einen langsamen oder absichtlich modifizierten Server verlangsamt wird. Außerdem ist es mit deutlich größerem programmiertechnischen Aufwand verbunden.
Es ist davon auszugehen, dass ein Angreifer aus den zuvor genannten Gründen eine so geschütztes Webanwendung meiden wird.
Das Framework implementiert eine solche Codeabfrage. Die Standardbibliothek hält zu diesem Zweck die Aktionen "security_get_image" und "security_check_image" bereit, welche mit Hilfe der PHP GD-Bibliothek eine Grafik im PNG-Format erzeugen können und eine interne Codetabelle zum Vergleich der vom Nutzer eingegebenen Daten verwalten. Diese Tabelle wird durch eine ".htaccess" -Datei vor öffentlichen Zugriffen geschützt und in regelmäßigen Zeitabständen automatisch erneuert.
Flooding kann sowohl unbeabsichtigt als auch beabsichtigt sein.
Unbeabsichtigt kann dies beispielsweise dann leicht geschehen, wenn der Server vorübergehend stark belastet ist. In diesem Fall kann es passieren, dass ein einzelner Nutzer, der gerade einen Schreibzugriff auf die Datenbank in Auftrag gegeben hat, ungewohnt lange auf die Antwort des Servers warten muss. Aus Ungeduld kann es vorkommen, dass der Nutzer die Refresh-Funktion des Browser benutzt und somit die Daten ein zweites Mal an den Server sendet, was dazu führt, dass unbeabsichtigt zwei identische Einträge erstellt werden. Selbst wenn die Webseite selbst nur wenig besucht ist, kann dies dennoch recht häufig vorkommen, wenn die Webseite auf einem "shared server" gespeichert ist. Das heißt: wenn sich die Webseite, auf welcher das Framework installiert ist, einen Host mit anderen Kunden teilt. Es ist nicht unüblich, dass sich je nach Preiskategorie und Anbieter ohne Weiteres 1000 oder sogar 10000 verschiedene Kunden den gleichen Server und damit die gleichen Ressourcen teilen müssen.
Beabsichtigtes Flooding ist meist eine Form von "Vandalismus". Ziele des Angreifers ist es, die normale Nutzung der Seite zu stören beziehungsweise zu erschweren.
Sowohl beabsichtigtes als auch unbeabsichtigtes Flooding kann durch automatisierte Maßnahmen vermindert werden.
Es sollen zwei Methoden betrachtet werden, mit denen Nutzer den Betrieb der Anwendung versuchen könnten zu stören. Erstens: durch die Reihung überlanger Zeichenketten ohne Zeilenumbruch, Reihung einer überlangen Kette von Zeilenumbrüchen, überlangen Texten allgemein, oder übergroßer Grafiken, kann das Layout der Anwendung gestört werden. Dies bewirkt eventuell, dass Teile des grafischen Layouts nicht mehr so dargestellt werden, wie vom Entwickler beabsichtigt. Außerdem könnte es dazu führen, dass andere Nutzer umständlich scrollen müssen, weil die Darstellung anderer Beiträge dadurch beeinträchtigt wird.
Die zweite Methode ist das massenhafte Absetzen von irrelevanten Beiträgen. Dadurch wird es anderen Nutzern erschwert, wichtige Nachrichten zu erkennen und deren Inhalte zu nutzen. Der Angreifer sendet dazu mehrere identische, oder inhaltlich ähnliche Beiträge nacheinander an den Server.
Für die zweite Methode sieht das Framework folgende Lösung vor. Wenn zwei Beiträge nacheinander zur Speicherung vorgesehen werden, wird überprüft ob die Beiträge abgesehen vom Zeitindex den gleichen Inhalt haben. Ist dem so, dann wird der zweite Eintrag nicht gespeichert. Dies verhindert insbesondere unabsichtliches Flooding des Mediums, erschwert jedoch auch eventuelle Angriffe.
Zusätzlich gibt es eine Option, welche es erlaubt festzulegen, wie viele Einträge ein Nutzer prinzipiell nacheinander schreiben darf. Der Nutzer wird anhand der IP identifiziert. Ist die Option gesetzt und schreibt der Nutzer nacheinander mehr Einträge als vorgesehen, ohne dass ein anderer Nutzer in der Zwischenzeit auf einen der Beiträge geantwortet hat, dann wird dem Nutzer das Speichern weiterer Beiträge verweigert.
Für die Abwendung der ersten Methode sorgt eine Reihe von Filtern. Diese Filter beschränken die Textlänge, begrenzen die Größe für die Darstellung von Grafiken auf Maximalwerte, entfernen auffällige Wiederholungen und erzeugen zwangsweise Zeilenumbrüche, wenn eine Zeichenkette von mehr als 80 aufeinander folgenden Zeichen ohne Vorkommen eines Whitespace-Zeichen gefunden wird.
Diese Methoden erschweren einem Angreifer die Störung des normalen Betriebs, können aber dies nicht grundsätzlich verhindern. Dies wäre auch nicht unbedingt sinnvoll. Dies liegt an einem bekannten Dilemma. Verengt man den Trefferbereich der Filter, dann reduziert sich die Zahl der Falschmeldungen ("false-positives") von Einträgen, welche als Flood-Versuch erkannt werden, aber gar keine sind. Gleichzeitig schlüpfen jedoch auch eine höhere Anzahl echter Angriffe durch das Netz der Filter. Umgekehrt: erweitert man den Trefferbereich der Filter, fängt man mehr Angriffe ab. Allerdings erhöht sich auch die Zahl der "false-positives" dementsprechend. Im Endeffekt wird man somit stets einen "Trade-off" zwischen ausreichender Sicherheit und ausreichender Vermeidung von Falschmeldungen suchen.
Thomas Meyer, www.yanaframework.net
Alternativen zu SML