Im Rahmen einer Forschungsarbeit sind wir über eine neue Angriffsmöglichkeit auf Webseiten gestossen. Diese stellen Seiten bereit, die durch Besucher aufgerufen und angezeigt werden können. Um den Zugriff auf die Webserver und die durch sie bereitgestellten Dokumente zu erleichtern, werden Suchmaschinen eingesetzt. Klassische Suchmaschinen benutzen Crawler oder Bots, um die jeweiligen Dokumente aufzusuchen, zu indizieren und damit durchsuchbar zu machen.

Das Problem von Duplicate Content

Mit der Einführung von Webtechnologien, die dynamische Inhalte ermöglichen (z.B. CGI, PHP und ASP), stieg das Risiko von sogenanntem Duplicate Content. Hierbei handelt es sich um Inhalte, die in mehrfacher Weise, oftmals unter verschiedenen URLs, bereitgestellt werden. Ein klassisches Beispiel sind Webadressen, die durch das geringfügige Ändern der Parameter die Reihenfolge der immerwährend gleichen Inhalte durchführen:

http://www.example.com/products.php?show=all&sort=asc

http://www.example.com/products.php?show=all&sort=desc

Dies ist ein ernsthaftes Problem für Index-Suchmaschinen, denn diese müssen diese redundanten Inhalte unnötigerweise weiterverarbeiten. Aber auch für Benutzer von Suchmaschinen sind derlei Doubletten unerwünscht. Denn durch das Aufblähen der Suchresultate wird es schwieriger, die richtigen Quellen für die gewünschten Informationen zu sondieren.

Die Angriffstechnik

Aus diesen Gründen pflegen moderne Suchmaschinen doppelte Inhalte und die dafür verantwortlichen seitenbetreiber zu bestrafen, indem den Seiten weniger Gewicht beigemessen und sie damit auf hintere Plätze in den Resultaten verwiesen werden. Im Rahmen der Suchmaschinenoptimierung (SEO) ist es für Seitenbetreiber natürlich kontraproduktiv, aufgrund doppelter Inhalte benachteiligt zu werden. Entsprechend sind sie darum bemüht, durch Anpassungen und Verbesserungen der Seiten Sanktionen dieser Art zu verhindern.

Eine sogenannte Search Engines Duplicate Content Caulk Attack ist darum bemüht, durch das Ausnutzen der Schwäche des Design einer Webseite, genau diesen Effekt herbeizuführen. Viele Webseiten weisen Designfehler auf, die doppelte Inhalte generieren können. Da diese Unterseiten jedoch so nie durch Suchmaschinen gefunden und indexiert werden, blieben Effekte bisher aus. Durch das absichtliche Einspeisen dieser fehlbaren URLs sollen die Sanktionen der Suchmaschinen provoziert werden.

IP-Adressen anstatt Hostnamen

Im Regelfall ist eine Webseite sowohl über einen regulären Hostnamen als auch über dessen IP-Adresse erreichbar. Durch das Einspeisen beider Varianten für eine Ressource, kann doppelter Inhalt erzeugt werden:

http://www.example.com/products.php?show=all&sort=asc

http://192.168.0.100/products.php?show=all&sort=asc

Durch eine Rewrite-Condition für Direktaufrufe der IP-Adresse und eine Weiterleitung zur Seite, basierend auf dem Hostnamen, kann dieser Effekt verhindert werden:

RewriteCond %{HTTP_HOST} ^192\.168\.0\.100$ [NC]
RewriteRule .* http://www.example.com/$1 [R=301,L]

Mehrere Hostnamen

Manche Webseiten sind über mehrere Hostnamen erreichbar, die durch die IP-Adresse zu Duplicate Content führen können. Meistens werden mehrere Subdomains verwendet und dadurch die gleichen Inhalte ansteuerbar. Manchmal werden sogar Subdomain-Wildcards unterstützt, wodurch beliebige Subdomains verwendet werden können:

http://example.com/

http://www.example.com/

http://foo.example.com/

Durch eine entsprechende Weiterleitung kann verhindert werden, dass eine unliebsame oder nicht-existente Subdomain verwendet wird. In diesem Beispiel wird in jedem Fall die Subdomain www durchgesetzt:

RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule .* http://www.example.com/$1 [R=301,L]

Alternative Schemes

RFC 3986 spezifizierte das sogenannte URI Scheme, das verwendet wird, um die Zugriffsart einer Ressource zu definieren. Typischerweise wird eine Webseite durch die Adresse http://www.example.com aufgerufen, um den Zugriff über HTTP, das standardmässig auf Port tcp/80 angeboten wird, durchführen zu lassen. Andere populäre Schemes sind https:// für HTTPS/SSL-Kommunikationen, ftp:// für FTP-Zugriffe und telnet:// für Telnet-Zugriffe. Manchmal wird eine Webseite über mehrere Dienste angeboten und kann deshalb durch unterschiedliche Schemes aufgerufen werden:

http://www.example.com/

https://www.example.com/

Durch eine entsprechende Weiterleitung kann verhindert werden, dass der unerwünschte Zugriff (auf bestimmte Ressourcen) über unliebsame Schemes, Ports oder Protokollvarianten durchgeführt wird:

RewriteCond %{HTTPS} =on
RewriteRule .* http://www.example.com/$1 [R=301,L]

Unsichtbare Index-Dateien

Durch Index-Dateien werden Standard-Dateien für Verzeichnisse bereitgestellt. Das direkte Aufrufen dieser ist nicht erforderlich, um die Standardanzeige generieren zu können. In diesem Fall ist es wichtig herauszufinden, welche Webtechnologie eingesetzt und welche Standard-Dateinamen definiert sind (u.a. index.php, index.asp, index.cgi, default.htm):

http://www.example.com/

http://www.example.com/index.php

Durch eine entsprechende Weiterleitung kann verhindert werden, dass eine Index-Datei optional verwendet wird. In diesem Beispiel wird der direkte Aufruf einer Index-Datei immer eine Weiterleitung zur Ressource ohne diese durchgesetzt:

RewriteCond %{QUERY_STRING} .*
RewriteRule index.php /?%1 [R=301,L]

Unnötige GET-Parameter

Viele der bisher gezeigten Beispiele sind auf explizite Konfigurationsfehler der entsprechenden Seitenbetreiber zurückzuführen. Falls sich diese nicht anwenden lassen, dann kann versucht werden, mit optionalen oder unnötigen GET-Parametern zu arbeiten, die einfach an eine legitime URL angehängt werden:

http://www.example.com/products.php?show=all&sort=asc&p1=foo

http://www.example.com/products.php?show=all&sort=asc&p2=foo

http://www.example.com/products.php?show=all&sort=asc&p3=foo

Derlei Angriffsvarianten lassen sich am besten durch eine strikte Eingabeprüfung in der Webapplikation selbst durchsetzen. Dieses Beispiel zeigt auf, wie mit hardcodierten Variablen gearbeitet werden und sich nur auf einzelne Elemente bezogen werden kann. Das Umsetzen dieser spezifischen Beispiel-Lösung erfordert jedoch, dass die genutzte Applikation auch die entsprechende Architektur mitbringt. Gegenmassnahmen gegen zusätzliche GET-Parameter sind sehr individuell umzusetzen.

foreach($HTTP_GET_VARS as $key=>$value){
   switch($key){
      case 'news'   : news($value)   ; break;
      case 'info'   : info($value)   ; break;
      case 'contact': contact($value); break;
   }
}

Effiziente Suchmaschinen-Einspeisung

Um diese Art eines Angriffs erfolgreich umzusetzen, müssen die redundanten Ressourcen in Suchmaschinen eingespiesen werden. Ganz im Gegensatz zur klassischen Methode, bei der einfach Inhalte übernommen und erneut angeboten werden (was Urheberrechtsverletzungen zur Folge haben kann).

Typischerweise bieten Suchmaschinen eine sogenannte Submission an, bei der durch ein Webformular oder eine andere Schnittstelle (z.B. API) neue Seiten mitgeteilt werden können. Dies ist der verlässlichste und einfachste Weg, da er sich mit einem Webbrowser umsetzen lässt.

Ein bisschen raffinierter und effizienter kann das eigene Bereitstellen einer Webseite sein, die auf die doppelten Ressourcen verlinkt. Das Problem hierbei ist, dass man sich zu einem gewissen Grad exponieren muss, indem man selber Inhalte anbietet, die dann womöglich als Quelle des Angriffs identifiziert werden können. Zudem kann durch das Auswerten der Link-Konstruktionen effiziente Gegenmassnahmen angestrebt werden. Im schlechtesten Fall trägt der Angriff gar durch das Verlinken zur Erhöhung des PageRank bei, was dem gegenteiligen Effekt der Attacke entspricht.

Die Zeitspanne des Hinzufügens neuer Seiten durch Anmelden oder Verlinken ist relativ lang. Effizienter gestaltet sich das Auflisten der Links in sogenannten XML-Sitemaps. Diese werden durch Suchmaschinen genutzt, um sehr schnell die Struktur einer Webseite verstehen und auf die einzelnen Ressourcen zugreifen zu können.

Eine eher spezielle aber nicht minder effektive Methode bestand darin, einen RSS-Feed für die einzubindenden Seiten zu erstellen und diese über den Google Reader einlesen zu lassen (ist seit dem 1. Juli 2013 nicht mehr möglich). Google nutzt die Synergien ihrer unterschiedleichen Dienste und bindet über den Reader identifizierte URLs sofort in den Index der Suchmaschine ein. Dies geschah bedeutend schneller, weder wenn die Seite über eine Submission mitgeteilt worden wäre.

Zusammenfassung

Durch die Einführung dynamischer Mechanismen können mehrfache Ausführungen von Inhalten entstehen. Suchmaschinen versuchen diesen Duplicate Content zu erkennen, um ihn in Bezug auf das Ranking zu sanktionieren. Indem verschiedene technische Eigenschaften von Webseiten missbraucht werden, können einer Suchmaschine die gleichen Inhalte mit unterschiedlichen URLs mitgeteilt werden. Dazu gehören IP-Adresse anstelle von Hostnamen, unterschiedliche Hostnamen, alternative Schemes, direkte Links auf Index-Dateien und unnötige GET-Parameter. Das Einspeisen dieser doppelten Adressen kann ebenfalls auf verschiedenen Wegen erfolgen. Klassischerweise wird eine neue Seite mittels einer Submission einer Suchmaschine mitgeteilt oder diese findet die Seite durch eine neue Verlinkung. Durch das Einbringen von XML-Sitemaps und dem Einbinden von RSS-Feeds (z.B. ehemals in Google Reader) kann dieser Prozess jedoch sehr stark beschleunigt werden.

Für Anbieter von Webseiten wird es wichtig, dass sie Duplicate Content erkennen und ihre Seiten entsprechend vorbereiten. Durch Redirects und eine solide Applikationsarchitektur können die verschiedenen Angriffsmechanismen abgewehrt werden.

Danksagung

Vielen Dank an Stefan Friedli (scip AG), Candid Wüest (Symantec) und Yves Torres (BlueMouse GmbH) für umfangreiches Feedback zu diesem Beitrag.

About the Author

Marc Ruef has been working in information security since the late 1990s. He is well-known for his many publications and books. The last one called The Art of Penetration Testing is discussing security testing in detail. He is a lecturer at several faculties, like ETH, HWZ, HSLU and IKF. (ORCID 0000-0002-1328-6357)

Links

• http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule
• http://reader.google.com/
• http://tools.ietf.org/html/rfc3986#section-3.1
• http://twitter.com/stfn42
• http://v3.espacenet.com/textdoc?DB=EPODOC&F=0&IDX=US6285999
• http://www.google.com/addurl/?continue=/addurl
• http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=156184
• http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=66359
• https://www.xing.com/profile/Candid_Wueest
• https://www.xing.com/profile/Yves_Torres