Posted:
Heutzutage basiert die Mehrheit der Websites auf Webapplikationen, um ihren Usern einen guten Service anzubieten. Vor allem Content-Management-Systeme (CMSs) sind sehr verbreitet, um Content zu erstellen, zu editieren und zu verwalten. Aufgrund der interaktiven Natur dieser Systeme, die sich grundlegend auf Usereingaben stützen, ist es wichtig über Sicherheitsaspekte nachzudenken, um die Systeme vor schädlichen Zugriffen Dritter zu schützen und die beste Usererfahrung zu sichern.

Einige Hacking-Methoden und wie man sie verhindern kann

Es gibt viele verschiedene Arten von Hacking-Angriffen, um eine Website teilweise oder vollständig unter Kontrolle zu bekommen. Die beiden häufigsten und auch gefährlichsten Methoden sind SQL-Injection (SQL-Einschleusung) und Cross-Site-Scripting (XSS).

SQL-Injection ist eine Technik, mit der man schädlichen Code in eine Webanwendung einfügen kann und eine Sicherheitslücke auf Datenbankebene ausnutzt, um ihr Verhalten zu beeinflussen. Es ist eine sehr wirkungsvolle Methode, wenn man in Betracht zieht, dass damit sowohl URLs (Suchstrings) als auch Formulare (Suchformulare, Logins, E-Mail-Registrierungen) manipuliert werden können, um schädlichen Code einzuschleusen. Einige Beispiele von SQL-Injections könnt ihr auf der Site des Web Application Security Consortiums finden.

Es gibt definitiv einige Vorsichtsmaßnahmen, die ihr treffen könnt, um diese Art von Angriff zu vermeiden. Beispielsweise ist es ein guter Ansatz, eine Ebene zwischen dem Formular im Frontend und der Datenbank im Bankend einzufügen. In PHP wird die PDO-Extension oft verwendet, um mit Parametern (manchmal auch Platzhalter oder Bindevariablen genannt) zu arbeiten, anstatt Usereingaben in den Ausdruck einzubinden. Eine andere sehr einfache Methode besteht darin, Zeichen zu maskieren (escapen), so dass alle gefährlichen Zeichen, die einen direkten Einfluss auf die Datenbankstruktur haben können, durch die Maskierung neutralisiert werden. Beispielsweise muss jedes Auftauchen eines einfachen Anführungszeichens ['] in einem Parameter durch zwei Anführungszeichen [''] ersetzt werden, um einen gültigen SQL-String-Literal zu bilden. Dies sind nur zwei der verbreitetsten Maßnahmen, die ihr treffen könnt, um die Sicherheit eurer Site zu erhöhen und SQL-Injection zu vermeiden. Online könnt ihr viele andere Quellen zu speziellen Themen finden, wie etwa Programmiersprachen, besondere Webapplikationen etc.

Die andere Technik, die wir hier vorstellen möchten, ist Cross-Site-Scripting (XSS). XSS ist eine Technik, die gerne verwendet wird, um schädlichen Code in eine Webpage einzufügen, wobei Sicherheitslücken in der Webapplikation ausgenutzt werden. Diese Art von Angriff wird dann ermöglicht, wenn die Webapplikation Daten verarbeitet, die sie von Usern erhält und diese ohne weitere Überprüfung oder Validierung an den Enduser ausgibt. Einige Beispiele von Cross-Site-Scripting könnt ihr im Web Application Security Consortium finden.

Es gibt viele Möglichkeiten, um eine Webapplikation gegen diese Technik zu sichern. Einige einfache Maßnahmen wären beispielsweise:
  • Beschränkt die Eingaben für ein Formular (beispielsweise mit der strip tags-Funktion in PHP).
  • Verwendet Datenenkodierung, um direkte Einschleusung von potentiell schädlichem Code zu verhindern (seht dazu z. B. die htmlspecialchars-Funktion in PHP).
  • Fügt eine Ebene zwischen Dateneingabe und dem Backend ein, um eine direkte Einschleusung von Code in die Applikation zu vermeiden.

Einige Quellen zum Thema CMS-Sicherheit

SQL-Injection und Cross-Site-Scripting sind nur zwei von vielen Methoden, die von Hackern verwendet werden, um unschuldige Sites anzugreifen und auszunutzen. Als eine generelle Sicherheitsrichtlinie gilt, dass ihr stets über die aktuellsten Sicherheitsrisiken informiert sein solltet und, sofern ihr Software von Drittanbietern verwendet, sicherstellt, dass ihr immer die aktuellste Version installiert habt. Viele Webapplikationen haben eine große Community und bieten kontinuierlichen Support und Updates an.
Um ein paar Beispiele zu nennen: Vier der größten Communities von Open Source Content-Management-Systemen — Joomla, WordPress, PHP-Nuke und Drupal — bieten nützliche Sicherheitstipps auf ihrer Site an; zudem gibt es dort große Foren mit einer aktiven Community, in denen User ihre Probleme schildern und um Hilfe fragen können. Beispielsweise bietet die Website von WordPress im Abschnitt Hardening WordPress eine umfassende Dokumentation dazu an, wie ihr die Sicherheit des WordPress-CMS gewährleisten könnt. Auch Joomla bietet viele Quellen zum Thema Sicherheit an, darunter vor allem auch eine umfassende Sicherheits-Checkliste mit Maßnahmen, die Webmaster treffen können, um die Sicherheit einer auf Joomla basierten Website zu erhöhen. Auf Drupals Site erhaltet ihr im Abschnitt über Sicherheit gezielte Informationen zu diesem Thema. Ihr könnt euch auch auf der Sicherheits-Mailingliste einschreiben, um regelmäßig über Neuigkeiten auf dem Laufenden zu sein. PHP-Nuke bietet einiges an Dokumentation zum Thema Sicherheit im Kapitel 23 ihres "How to"-Abschnittes an, welches sich gezielt mit dem Systemmanagement dieser CMS-Plattform befasst. In dem Abschnitt Hacked - Now what? bieten sie Tipps zum Umgang mit Hacking-Problemen an.

Einige Möglichkeiten, um festzustellen, ob eure Site gehackt wurde

Wie oben bereits erwähnt, gibt es verschiedene Arten von Angriffen, die Hacker auf Sites verüben, um unschuldige Sites für ihre Zwecke zu missbrauchen. Wenn es Hackern gelingt, die vollständige Kontrolle über eine Site zu gewinnen, können sie die Site komplett entstellen (indem sie Homepage ändern), den gesamten Content löschen (indem sie die Tabellen aus eurer Datenbank löschen), oder Malware bzw. Scripte zum Auslesen der Cookies einschleusen. Sie können eine Site auch zum Spammen missbrauchen, indem sie Links auf ihr verstecken, die wiederum auf andere Spamquellen verweisen, oder indem sie Seiten erstellen, die zu Malware-Sites umleiten. Wenn ihr diese Veränderungen in eurer Applikation bemerkt (wie etwa "Defacing", d. h. die Entstellunge eurer Homepage), dann könnt ihr mit Sicherheit davon ausgehen, dass ihr gehackt wurdet; für andere Arten von Missbrauch jedoch, insbesondere für die mit Spamabsicht, ist dies nicht so eindeutig festzustellen. Google bietet Webmastern durch einige seiner Produkte einfache Wege an, um zu erkennen, ob eine Site gehackt oder von dritter Seite ohne Zustimmung verändert wurde. Beispielsweise könnt ihr typische Schlüsselwörter, die von Hackern in eure Site eingefügt wurden, durch eine Google-Suche erkennen und die betroffenen Seiten identifizieren. Geht einfach zu google.de und macht eine site: Suchanfrage für eure Website, kombiniert mit kommerziellen Schlüsselwörtern, die Hacker gewöhnlich für ihre Spamaktivitäten verwenden (wie etwa viagra, mp3, cialis, etc.):

[site:example.com viagra]

Falls ihr noch nicht mit dem site: Suchoperator vertraut seid - er bietet euch die Möglichkeit, eine Google-Suchanfrage auf eine bestimmte Site zu beschränken. So gibt euch beispielsweise die Suche site:googleblog.blogspot.com nur Ergebnisse des Official Google Blogs aus. Wenn ihr spammige Schlüsselbegriffe zu dieser Art von Suchanfrage hinzufügt, dann wird Google euch alle indexierten Seiten eurer Site ausgeben, die diese Begriffe enthalten und demnach mit hoher Wahrscheinlichkeit gehackt sind. Um die verdächtigen Seiten zu überprüfen, öffnet einfach die Cache-Version, die Google euch anbietet, und ihr werdet den Hacking-Content gegebenenfalls schnell erkennen. Ihr könnt daraufhin die betroffenen Seiten von dem Hacking-Content befreien; zudem könnt ihr auch die Konfigurationsdateien auf eurem Server nach Anomalien untersuchen (beispielsweise die des Apache Web-Servers: .htaccess und httpd.conf).
Falls eure Site nicht mehr in den Google-Suchergebnissen auftaucht, dann könnte das bedeuten, dass Google die schädlichen Hacking-Aktivitäten auf eurer Site bereits bemerkt und diese vorübergehend aus unserem Index entfernt hat, da sie aufgrund des gehackten Contents gegen unserere Richtlinien für Webmaster verstößt.

Um stets ein Auge auf eure Website zu haben und verdächtige Schlüsselbegriffe schnell zu entdecken, könnt ihr auch Google Alerts zur Überwachung bestimmter Suchanfragen verwenden, wie etwa:

site:example.com viagra|casino|porn|ringtones

Ihr erhaltet dann eine Benachrichtigung, sobald diese Schlüsselbegriffe auf eurer Website gefunden werden.

Ihr könnt zudem auch unsere Webmaster-Tools verwenden, um Hacking-Aktivitäten auf eurer Site zu entdecken. Die Webmaster-Tools stellen euch Statistiken über die Top-Suchanfragen für eure Site zur Verfügung. Diese Daten können euch dabei helfen, einen Überblick über eure Site zu behalten und zu erkennen, falls eure Site für verdächtige, themenfremde Suchbegriffe rankt. Diese 'Was Googlebot sieht'-Daten sind zudem auch nützlich, weil ihr so erkennt, ob Google ungewöhnliche Schlüsselbegriffe auf eurer Site entdeckt, unabhängig davon, ob ihr dafür rankt oder nicht.

Wenn ihr ein Konto in den Webmaster-Tools habt und Google annimmt, dass eure Site gehackt wurde, dann werdet ihr gewöhnlich darüber benachrichtigt und auch über die Art der Sicherheitsverletzung informiert:
  • Falls eine böswillige dritte Partei eure Site für Spamaktivitäten ausnutzt (wie etwa das Verstecken von Links zu verstecken oder die Erstellung von Spamseiten zu erstellen) und dies von unseren Crawlern erkannt wurde, dann könnt ihr gewöhnlich im Nachrichten-Center detailliertere Informationen darüber finden (wie etwa eine Auswahl der gehackten URLs oder Linktext der versteckten Links).
  • Falls eure Site dazu missbraucht wird, schädliche Software wie etwa Malware zu verbreiten, dann werdet ihr eine Malware-Warnung auf der Übersichtsseite eures Webmaster-Tools-Kontos finden.

Alle Spuren des Hacker-Angriffs entfernt, was jetzt?

Eure Site ist gehackt worden oder sie verbreitet Malware? Befreit eure Site zunächst einmal von der Malware und dann macht das Folgende:
  • Wenn eure Site zu Spamzwecken gehackt wurde, dann besucht bitte unsere Seite Antrag auf erneute Überprüfung in den Webmaster-Tools, um einen Antrag auf erneute Überprüfung für eure Site zu stellen.
  • Wenn eure Site Malware verbreitet, dann reicht bitte eine Malware-Überprüfung auf der Übersichtsseite der Webmaster-Tools ein.

Wir hoffen, dass ihr diese Tipps hilfreich findet. Falls ihr eure eigenen Tipps und Erfahrungen mitteilen möchtet, dann hinterlasst gerne einen Kommentar zu diesem Blogpost. Vielen Dank!

Best practices against hacking (English version)

Post von Paolo Petrolini & Iris Mariano, Search Quality (Übersetzung von Claudia Pfalzer, Search Quality)

Posted:
Im dritten Teil unserer Reihe von Video-Tutorials geht es um das Erstellen und Einreichen von Sitemaps. Welche Arten von Sitemaps gibt es? Wie können sie in den Webmaster-Tools hinzugefügt werden?

Weitere Informationen zu Sitemaps findet ihr außerdem in unserem letzten Post zu diesem Thema: Sitemaps einreichen leicht gemacht.




In Teil 1 ging es um die Registrierung und Verifizierung eurer Site in den Webmaster-Tools.
Wie ihr Präferenzen zu Crawling und Indexierung sowie zum Geo-Targeting einstellt, zeigt euch das 2. Video.

Und hier noch eine Vorschau auf die kommenden Videos dieser Reihe:
Video 4: Entfernen eures Contents aus dem Index
Video 5: Die Bereiche Diagnose, Statistiken und Links
Video 6: Wie ihr mit Google kommunizieren könnt

Post von Sven Naumann, Search Quality

Posted:
Duplicate Content-Sorgen ade: Wir unterstützen jetzt ein Format, das es euch erlaubt, die bevorzugte Version eurer URLs bekanntzugeben. Falls eure Site gleichen oder sehr ähnlichen Content über verschiedene URLs verfügbar macht, bekommt ihr mit diesem Format eine größere Kontrolle darüber, welche URL in den Suchergebnissen angezeigt wird. Außerdem hilft dieses Format dabei, dass verschiedene Eigenschaften, wie z. B. die Linkpopularität, auf eure bevorzugte Version zusammengefasst werden.

Hier haben wir unser altes Beispiel einer Site, die schwedische Süßigkeiten verkauft. Stellt euch vor, dass eure bevorzugte Version der URL so aussieht:

http://www.example.com/product.php?item=swedish-fish

Eure User (und Googlebot) können die Seite jedoch über mehrere verschiedene (und nicht so simple) URLs erreichen. Selbst wenn die wesentlichen Informationen hinter diesen URLs die gleichen sind wie in eurer bevorzugten Version, kann es bei diesen anderen Versionen kleine Abweichungen im Content geben, die beispielsweise durch Sortierungsparameter oder die Kategorienavigation bedingt sind:

http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
Oder es liegt gänzlich identischer Content vor, der aber verschiedene URLs aufgrund von Tracking-Parametern oder Session-IDs besitzt:

http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678

Jetzt könnt ihr einfach einen <link>-Tag hinzufügen, um eure bevorzugte Version zu kennzeichnen:

<link rel="canonical" href="http://www.example.com/product.php?item=swedish-fish" />

Fügt dies in den <head>-Abschnitt eurer URLs mit dem Duplicate Content ein:
http://www.example.com/product.php?item=swedish-fish&category=gummy-candy
http://www.example.com/product.php?item=swedish-fish&trackingid=1234&sessionid=5678


Google wird nun erkennen, dass sich die Duplikate alle auf eine kanonische URL beziehen: http://www.example.com/product.php?item=swedish-fish. Alle weiteren URL-Eigenschaften, wie z. B. PageRank oder ähnliche Signale, werden ebenfalls auf die kanonische URL übertragen.

Dieser Standard kann von jeder Suchmaschine übernommen werden, die eure Site crawlt und indexiert.

Natürlich habt ihr vielleicht noch weitere Fragen. Joachim Kupke, Software-Ingenieur in unserem Indexing-Team, kann euch schon mal einige Antworten geben:

Ist rel="canonical" ein Hinweis oder eine Anweisung?
Es ist ein Hinweis, den wir sehr streng befolgen. In Verbindung mit weiteren Signalen werden wir eure bevorzugte Version in Betracht ziehen, wenn wir die relevanteste Seite zu einer bestimmten Suchanfrage ermitteln.

Kann ich einen relativen Pfad verwenden, um meine kanonische URL zu kennzeichnen, wie z. B. <link rel="canonical" href="product.php?item=swedish-fish" />?
Ja, relative Pfade werden erwartungsgemäß mit dem <link>-Tag unterstützt. Falls ihr einen <base>-Link in eurem Dokument aufgenommen habt, werden alle relativen Pfade anhand der <base>-URL aufgelöst.

Ist es in Ordnung, wenn die kanonische URL keine 100%-ige Kopie der Duplicate Content-URLs ist?
Wir tolerieren gewisse geringe Unterschiede - wenn z. B. die Sortierreihenfolge in einer Tabelle mit Produkten verschieden ist. Ebenso wissen wir, dass wir die kanonische URL und die Duplikate möglicherweise zu verschiedenen Zeitpunkten crawlen, so dass sich der Inhalt gegebenenfalls geringfügig unterscheidet. Dies ist vollkommen in Ordnung.

Was passiert, falls die rel="canonical"-URL einen 404-Fehler liefert?
Wir werden damit fortfahren euren Content zu indexieren und eine Heuristik anwenden, um die kanonische URL zu ermitteln. Wir empfehlen jedoch, für die kanonische URL eine tatsächlich existierende URL zu wählen.

Was passiert, falls die ref="canonical"-URL noch nicht indexiert wurde?
Wie mit allem öffentlich zugänglichem Content sind wir bemüht, eine benannte kanonische URL möglichst schnell zu finden und zu crawlen. Sobald diese indexiert wurde, werden wir den rel="canonical"-Hinweis unmittelbar in Betracht ziehen.

Kann es sich bei der rel="canonical"-URL um eine Weiterleitung handeln?
Ja, ihr könnt eine URL mit Weiterleitung als kanonische URL angeben. Wir werden die Weiterleitung dann wie gewöhnlich verarbeiten und versuchen, die URL zu indexieren.

Was passiert, wenn ich widersprüchliche rel="canonical"-Angaben mache?
Unser Algorithmus ist nachsichtig: Wir können Ketten von kanoischen Angaben folgen, jedoch empfehlen wir, dass ihr eure Links dahingehend updated, dass sie auf eine eindeutige kanonische URL verweisen, um die besten Ergebnisse zu gewährleisten.

Kann dieser Link-Tag dazu verwendet werden, um eine kanonische URL auf einer vollkommen verschiedenen Domain zu benennen?
Nein, um auf eine vollkommen verschiedene Domain zu verweisen, solltet ihr permanente Weiterleitungen (301) verwenden. Wir berücksichtigen momentan Angaben zur kanonischen URL auf Subdomains (also innerhalb einer Domain), aber nicht über verschiedene Domains hinweg. Ihr könnt also z. B. www.example.com vs. example.com vs. help.example.com verwenden, nicht jedoch example.com vs. example-widgets.com.

Klingt super - gibt's schon Beispiele?
Ja - wikia.com hat uns bei unseren Tests unterstützt. So könnt ihr beispielsweise im Quelltext der URL http://starwars.wikia.com/wiki/Nelvana_Limited erkennen, dass eine rel="canonical"-URL angegeben wurde: http://starwars.wikia.com/wiki/Nelvana.

Beide URLs sind fast identisch, mit der Ausnahme, dass die erste URL (also "Nelvana_Limited") eine kurze Nachricht im oberen Bereich enthält. Das ist ein gutes Beispiel für dieses neue Feature. Mittels rel="canonical" wurden die Eigenschaften der beiden URLs konsolidiert und in den Suchergebnissen taucht die von wikia.com bevorzugte Version auf.

Falls ihr weitere Fragen habt, könnt ihr diese gern als Kommentar hinterlassen. Und falls es euch nicht möglich ist, eine kanonische URL in eure Seiten einzubauen: Keine Sorge - davon unabhängig bemühen uns, eure bevorzuge Version im Fall von Duplicate Content zu ermitteln und alle Link-Eigenschaften entsprechend zu übertragen. So, wie wir das schon früher gemacht haben.

Post von Joachim Kupke, Senior Software Engineer, und Maile Ohye, Developer Programs Tech Lead (Übersetzung von Sven, Search Quality)

Posted:
Niemand will, dass sich Malware oder Spam-URLs auf der eigenen Domain einnisten. Darum ist man in der Regel bemüht, Ratschläge zur Sicherheit zu beachten. Aber was, wenn die Spammer dennoch einen Weg finden, eure Site zu manipulieren - ohne jemals einen virtuellen Fuß auf euren Server zu setzen?

Es gibt dazu eine Möglichkeit, und zwar durch den Missbrauch von Open-Redirect-URLs.

Webmaster sehen sich mit einer Reihe von Situationen konfrontiert, in denen es sinnvoll ist, Benutzer zu einer anderen Seite weiterzuleiten. Unglücklicherweise können Links, die an einen beliebigen Zielort weiterleiten, missbraucht werden. Dies ist eine besonders lästige Form von Missbrauch, weil hier die Funktionalität der Website ausgenutzt wird und nicht bloß ein Bug oder eine Sicherheitslücke. Spammer hoffen, eure Domain als zeitweilige "Landing-Page" zu verwenden, um E-Mail- und Websuche-Benutzer sowie Suchmaschinen auszutricksen und sie dazu zu bringen, Links zu folgen, die zwar scheinbar auf eure Website führen, tatsächlich aber zu Spam-Websites weiterleiten.

Wir bei Google arbeiten hart daran, missbrauchte URLs nicht in den Index aufzunehmen. Es ist auch wichtig für euch, dass eure Website nicht derart zweckentfremdet wird. Es ist ziemlich wahrscheinlich, dass ihr kein Interesse daran habt, Benutzern eurer Domain URLs zu bieten, die sie zu unerwünschten Sexseiten, hinterhältigen Viren, Malware oder Phishing-Versuchen führen. Spammer werden versuchen, Links zu eurer Website zu erstellen, damit die Redirects in den Suchresultaten erscheinen. Diese Links kommen häufig aus einer schlechten Nachbarschaft, mit der ihr höchstwahrscheinlich nicht in Zusammenhang gebracht werden wollt.

Diese Form von Missbrauch hat sich in letzter Zeit ziemlich ausgebreitet und deshalb wollen wir euch darüber informieren. Nachfolgend findet ihr hier zuerst einige Beispiele für Redirects, die aktiv missbraucht werden, dann geht es darum, wie ihr rausfinden könnt, ob eure Website ausgenutzt wird und was ihr dagegen tun könnt.

Redirects, die von Spammern missbraucht werden

Wir haben festgestellt, dass Spammer auf eine große Bandbreite von Websites abzielen - egal ob sie großen, weltbekannten Unternehmen oder kleinen, lokalen Institutionen gehören. Die folgende Liste führt Beispiele von Redirects an, die uns bereits begegnet sind. Sie alle haben gemeinsam, dass es sich um vollkommen legitime Techniken handelt, aber falls sie auf eurer Website eingesetzt werden, solltet ihr überprüfen, ob sie missbraucht werden.
  • Scripts, die User zu einer Datei auf dem Server weiterleiten - etwa zu einer pdf-Datei -, können mitunter angreifbar sein. Falls ihr ein Content-Management-System (CMS) einsetzt, das Datei-Uploads erlaubt, solltet ihr sicherstellen, dass der Link direkt zur Datei führt und nicht den Umweg über einen Redirect nimmt. Das beinhaltet auch alle Redirects, die ihr im Download-Bereich eurer Website setzt. Überprüft Links wie die folgenden:
example.com/go.php?url=
example.com/ie/ie40/download/?


  • Seiten mit internen Suchergebnissen enthalten manchmal automatische Redirect-Optionen, die angreifbar sein könnten. Achtet auf Patterns wie dieses, wo User automatisch zu jeder beliebigen Seite weitergeleitet werden, die hinter dem "url="-Parameter angeführt wird.
example.com/search?q=user+search+keywords&url=

  • Systeme, die Klicks für Affiliate- oder Werbeprogramme sowie für Websitestatistiken tracken, können ebenfalls offen sein. Einige Beispiel-URLs findet ihr hier:
example.com/coupon.jsp?code=ABCDEF&url=
example.com/cs.html?url=

  • Proxy-Websites - obwohl nicht immer Redirects im technischen Sinn - zielen darauf ab, Benutzer durch andere Websites zu schicken und sind folglich empfindlich für diese Form von Missbrauch. Dabei sind auch jene, die von Schulen und Bibliotheken verwendet werden, betroffen. Beispielsweise:
proxy.example.com/?url=

  • In machen Fällen leiten Login-Pages Benutzer zurück zu der Seite, die sie ursprünglich erreichen wollten. Achtet auf URL-Parameter wie den folgenden:
example.com/login?url=

  • Scripts, die eine Übergangsseite anzeigen, wenn Benutzer die Website verlassen, können ebenfalls missbraucht werden. Viele Websites aus dem Bereich Bildung, Verwaltung oder Websites von großen Unternehmen tun dies, um den Benutzer darauf hinzuweisen, dass die Informationen auf den nachfolgenden Seiten nicht von ihnen stammen. Achtet auf URLs mit Patterns wie diesen:
example.com/redirect/
example.com/out?
example.com/cgi-bin/redirect.cgi?



Wird meine Website missbraucht?

Selbst wenn euch keines der aufgezählten Patterns bekannt ist, könnte eure Website Open Redirects enthalten, auf die ihr achten solltet. Es gibt eine ganze Reihe von Möglichkeiten festzustellen, ob ihr angreifbar seid, auch wenn ihr nicht selbst die Website entwickelt.
  • Schaut euch an, ob missbrauchte URLs bei Google angezeigt werden. Versucht eine site: search für eure Website, um festzustellen, ob unbekannte Ergebnisse in den Google-Resultaten auftauchen. Ihr könnt Worte, die kaum dem Content eurer Website entsprechen, der Suche hinzufügen. Falls die Suchanfrage [site:example.com viagra] keine Ergebnisse für eure Website liefern dürfte, dies aber dennoch tut, könnte das auf ein Problem hinweisen. Ihr könnt solche Anfragen sogar mit Google Alerts automatisieren.
  • Ihr könnt außerdem nach seltsamen Ergebnissen im Bereich Die häufigsten Suchanfragen in den Webmaster-Tools Ausschau halten. Falls eure Website sich mit Ahnenforschung beschäftigt und ein großer Anteil der Suchanfragen von Pornos, Pillen oder Casinos handelt, ist das ein guter Warnhinweis. Andererseits wird eine Website mit Informationen über Medikamente eher selten Promi-Namen in den häufigsten Suchanfragen enthalten. Behaltet das Nachrichten-Center in den Webmaster-Tools im Auge, um Benachrichtigungen von Google nicht zu übersehen.
  • Überprüft eure Server-Logs oder Web-Analyse-Tools auf ungewöhnliche URL-Parameter (wie "=http:" oder "=//") oder Spikes im Traffic in Bezug auf weiterleitende URLs auf eurer Website. Ihr könnt Seiten mit externen Links auch in den Webmaster-Tools überprüfen.
  • Achtet auf Benutzerbeschwerden über Inhalte oder Malware, von denen ihr sicher seid, dass sie nicht auf eurer Website vorhanden sind. Eure Benutzer könnten eure Domain in der URL erkannt haben, bevor sie weitergeleitet wurden, und danach annehmen, dass sie noch immer auf eurer Website sind.

Was ihr unternehmen könnt

Unglücklicherweise gibt es keinen simplen Trick, um zu garantieren, dass eure Redirects nicht missbraucht werden. Ein offener Redirect ist an und für sich kein Bug und keine Sicherheitslücke. Für manche Verwendungszwecke müssen sie eben ziemlich offen bleiben. Aber es gibt doch einige Dinge, die ihr tun könnt, um zu verhindern, dass eure Redirects missbraucht werden, und um sicherzustellen, dass sie zumindest kein attraktives Ziel abgeben. Einige dieser Maßnahmen sind recht aufwendig: es könnte notwendig werden, maßgeschneiderten Code zu schreiben oder den Hersteller um einen Patch zu bitten.
  • Ändert den Redirection-Code, um den Referer zu überprüfen, da in den meisten Fällen jeder, der euer Redirection-Script rechtmäßig verwendet, von eurer Site und nicht von einer Suchmaschine oder von woanders kommt. Wahrscheinlich solltet ihr eine gewisse Toleranz beibehalten, da der Browser mancher Benutzer einen Referer eventuell nicht meldet. Falls ihr aber wisst, dass Benutzer von einer externen Website kommt, könnt ihr sie stoppen oder warnen.
  • Falls euer Script die Benutzer ohnehin nur zu internen Seiten oder Dateien (beispielsweise zu einer Seite für Downloads) führt, solltet ihr Redirects zu externen Websiten explizit ausschließen.
  • Erwägt den Einsatz einer Whitelist von sicheren Zielen. In diesem Falll würdet ihr alle externen Links auflisten und die Zielwebsite vor der Weiterleitung abgleichen, um sicherzustellen, dass es sich um ein legitimes Ziel handelt.
  • Erwägt das Verschlüsseln eures Redirects mit einer Signatur. Falls eure Website tatsächlich URL-Redirects benötigt, könnt ihr die Ziel-URL mit einem Hash-Code versehen und dann die kryptographische Signatur dem Redirect als einen weiteren Parameter hinzufügen. Auf diese Weise könnt ihr URL-Redirects auf eurer Site verwenden, ohne diese Möglichkeit für die Allgemeinheit zu öffnen.
  • Falls Weiterleitungen auf eurer Website ohnehin nicht verwendet werden, schaltet die Redirects ab oder entfernt sie. Wir konnten feststellen, dass eine große Anzahl von Websites existiert, bei denen nur die Spammer die Redirects benutzen - wahrscheinlich ist diese Funktion einfach standardmäßig eingeschaltet.
  • Verwendet robots.txt, um Suchmaschinen davon abzuhalten, die Redirect-Scripts eurer Website zu lesen. Das schafft zwar das Problem nicht vollständig aus der Welt, weil Spammer immer noch eure Domain für E-Mail-Spam missbrauchen könnten, doch eure Website wird weniger attraktiv für Angreifer, und Benutzer werden nicht durch Suchergebnisse reingelegt. Falls eure Redirection-Scripts in einem Unterverzeichnis untergebracht sind - gemeinsam mit anderen Scripts, die nicht in den Suchresultaten erscheinen müssen - könnte es das Ausklammern des ganzen Unterverzeichnisses für Spammer noch schwerer machen, das Redirection-Script überhaupt erst zu finden.

Der Missbrauch von Open Redirects ist im Moment ein großes Problem, aber je mehr Webmaster davon wissen, umso schwieriger wird es für dubiose Gestalten, ungeschützte Websites auszunutzen. Falls ihr Tipps habt, postet doch einen Kommentar oder beteiligt euch an der Diskussion in unserem Forum für Webmaster!

Open redirect URLs: Is your site being abused? (English version)

Post von Jason Morrison, Search Quality Team (Übersetzung von Jörg, Search Quality)

Posted:
Falls ihr am vergangenen Samstag (31.01.) zwischen 15:30 und 16:25 eine Google-Suche gemacht habt, ist euch wahrscheinlich die Meldung "Diese Website kann Ihren Computer beschädigen" bei jedem Suchergebnis aufgefallen. Dabei handelte es sich um einen Fehler und wir möchten uns für daraus entstandene Unannehmlichkeiten entschuldigen.

Was war passiert? Einfach ausgedrückt: Menschliches Versagen. Google kennzeichnet Sites mit der Meldung "Diese Website kann Ihren Computer beschädigen", wenn diese dafür bekannt sind, Malware zu verbreiten oder wenn sie anderweitig Risiken für User bergen. Wir tun dies, um unsere User davor zu schützen, potentiell gefährliche Sites zu besuchen. Wir pflegen eine Liste solcher Sites mittels manueller und automatisierter Verfahren. Dabei arbeiten wir mit einer gemeinnützigen Organisation (StopBadware.org) zusammen, um Kriterien für die Zusammenstellung dieser Liste zu sammeln und Webmastern einfache Methoden anzubieten, ihre Website aus dieser Liste zu entfernen.

Wir aktualisieren diese Liste in regelmäßigen Abständen und haben ein solches Update am letzten Samstag veröffentlicht. Unglücklicherweise (und da liegt das menschliche Versagen) wurde dabei die URL "/" mit in die Liste aufgenommen, was einem Platzhalter für alle URLs entspricht. Erfreulicherweise konnte unser Team für Ausfallsicherheit das Problem schnell erkennen und das Update rückgängig machen. Da wir derartige Updates gestaffelt und schrittweise durchführen, traten die ersten Fehler zwischen 15:27 und 15:40 auf und begannen dann zwischen 16:10 und 16:25 wieder zu verschwinden, so dass das Problem für die meisten unserer User ca. 40 Minuten lang sichtbar war.

Vielen Dank an unser Team für ihre schnelle Arbeit bei der Fehlerbehebung. Wir möchten uns nochmals für die Beeinträchtigungen der Google-Suche entschuldigen - ebenso bei allen Webmastern, deren Sites fälschlicherweise mit unserem Warnhinweis gekennzeichnet waren. Wir werden den Vorfall genau untersuchen und sicherstellen, dass zukünftig umfassendere Prüfungen durchgeführt werden, um solche Vorfälle zu verhindern.

Vielen Dank für euer Verständnis.

"This site may harm your computer" on every search result?!?! (English version)

Post von Marissa Mayer, VP, Search Products & User Experience (Übersetzung von Sven, Search Quality)