Google Hacking – So schützt man Webanwendung vor Angriffen
Kommentare

Google Hacking ist kein Spaß, sondern eine ernst zu nehmende Bedrohung. Darunter versteht man den kreativen Einsatz von Google, um alles Mögliche zu finden – auch Dinge, die lieber verborgen bleiben sollten. Erfahren Sie, wie Sie Ihre Webanwendung besser vor Angriffen schützen. Die wichtigste Grundregel ist: Was nicht veröffentlicht werden soll, hat auf dem Webserver nichts zu suchen.

Sie alle haben bestimmt schon oft „Google Hacking“ genutzt. Meist, ohne es zu bemerken. Nehmen wir mal an, Sie sind bei Google News einem Link zu einer Nachrichtenwebsite gefolgt und haben dort in der Seitenleiste einen weiteren interessanten Artikel entdeckt. Nach dem Klick auf den zugehörigen Link sind Sie jedoch nicht beim Artikel gelandet, sondern die Website hat Ihnen freundlich mitgeteilt, dass es hier kostenlos nicht weiter geht, Sie aber gerne nach Zahlung eines Obolus den Artikel lesen dürfen. Da Sie nicht zahlen wollen, zum Beispiel, weil es ziemlich unsinnig ist, einen Monatsbeitrag für einen einzigen Artikel zu zahlen, klicken Sie auf Ich will nichts kaufen und landen auf einer Übersichtsseite, und an erster Stelle steht der Anreißer zum Sie interessierenden Titel.
Mit Speck fängt man bekanntlich Mäuse. Aber Sie wollen sich nicht ködern lassen. Andere Verlage haben auch schöne Webseiten, also kopieren Sie den interessanten Artikeltitel ins Suchfeld Ihres Browsers und fragen Google um Rat. Und – oh Wunder! – an erster Stelle der Suchergebnisse steht der von Ihnen begehrte Artikel. Und da der Websitebetreiber auf die Google-Benutzer nicht verzichten will, können Sie den vorher nicht erreichbaren Artikel nun per Umweg über Google erreichen.
Das ist schon eine Form von „Google Hacking“, da Sie die Zugriffsbeschränkung der Website so umgehen. Sie müssen jetzt aber kein schlechtes Gewissen haben – der Websitebetreiber hat die Artikel für Besucher, die über Google kommen, ja mit Absicht lesbar gelassen. Wenn er wirklich eine Paywall wollte, könnte er die problemlos so implementieren, dass Google-Bot und Google-Nutzer ausgesperrt werden.
Aber kommen wir zurück zum eigentlichen Google Hacking. Damit verbunden ist der Begriff des „Google Dorks“, und der hat im Laufe der Zeit seine Bedeutung ziemlich geändert.

Google Dorks

Johnny Long, der die Google Hacking Database (GHDB) gegründet hat, erklärt Google Dorks folgendermaßen: We call them „googledorks“: Inept or foolish people as revealed by Google. Whatever you call these fools, you’ve found the center of the Google Hacking Universe! Auf Deutsch also etwa: Wir nennen sie „googledorks“: Unfähige oder dumme Menschen, die von Google aufgedeckt werden. Wie auch immer Sie diese Narren nennen, Sie haben (mit ihnen) das Zentrum des Google-Hacking-Universums gefunden!
Inzwischen werden auch die speziellen Suchanfragen oft als „Google Dork“ bezeichnet, zum Beispiel, wenn sie in Exploits oder Security Advisories zu Schwachstellen angegeben werden.
Die Beschreibung von Johnny Long ist auch etwas sehr hart formuliert. Denn zum Beispiel Suchanfragen nach Webanwendungen mit bekannten Schwachstellen nutzen meist die in den Webseiten enthaltenen Copyright- und Versionsinformationen aus.
Andererseits findet man über Google Hacking auch Dateien, die nach Ansicht ihrer Eigentümer gar nicht zu finden sein sollten. Zum Beispiel, weil vergessen wurde, Verzeichnisse von der Indexierung auszunehmen oder eigentlich nicht mehr benötigte Dateien zu löschen. Dabei kommt natürlich auch Unfähigkeit oder eher Unwissenheit ins Spiel.
In der Google Hacking Database werden die entsprechenden Suchanfragen gesammelt. Anfangs von Johnny Long verwaltet, wird sie nun über die Exploit DB aktualisiert, über die sie auch abgefragt werden kann [2].

Googles Suchoperatoren

Googles Suchfunktion lässt sich durch einige Operatoren beeinflussen. Die werden Sie zum Teil bereits kennen, trotzdem möchte ich die wichtigsten hier kurz zusammenfassen. Ihre Kenntnis erleichtert das Verständnis der später vorgestellten Beispiele ungemein.

„Der gesuchte Satz“ – Es wird genau nach dem zwischen den Anführungszeichen angegebenen String gesucht und nicht nach einem Vorkommen der Wörter in beliebiger Reihenfolge.
intitle:suchbegriff – Der angegebene Begriff muss im Titel der Seite vorkommen.
allintitle: „begriff1 begriff2“ – Alle angegebenen Begriffe müssen im Titel vorkommen.
intext:suchbegriff – Das Gegenteil von intitle: der angegebene Begriff muss im Text der Seite vorkommen.
allintext:“begriff1 begriff2″ – Das Gegenteil von allintitle: alle Begriffe müssen im Text der Seite vorkommen.
inurl:suchbegriff – Der angegebene Begriff muss im URL der Seite vorkommen.
site:website – Es wird nur in den Seiten der angegebenen Website gesucht.
filetype: – Es wird nach einem bestimmten Dateityp gesucht, zum Beispiel PHP oder PDF.
cache:url gibt die von Google gecachte Version des URL aus. Das ist sehr nützlich, wenn eine Seite inzwischen geändert wurde, zum Beispiel, weil jemandem etwas daran nicht gefiel. Da Google den Cache regelmäßig auffrischt, bleiben die Seiten aber meist nicht sehr lange erhalten. Für länger zurückliegende Seitenversionen ist die Wayback Machine des Internet Archive [3] zuständig.
info:url liefert eine Übersicht über alle Informationen, die Google über diesen URL besitzt. Für http://entwickler.de/magazin sieht das wie in Abbildung 1 aus.
• Zu guter Letzt gibt es noch das Minus-Zeichen (-), mit dem Suchbegriffe oder Operatoren aus dem Ergebnis ausgeschlossen werden können. Wenn ich zum Beispiel wissen will, was im Internet über ein bestimmtes Sicherheitsthema geschrieben wird, schließe ich durch Angabe von -site:ceilers-it.de -site:ceilers-news.de meine eigenen Websites aus. Denn was ich geschrieben habe, weiß ich ja.

Abb. 1: Googles Ausgabe für info:http://entwickler.de/magazin

Wer sucht, der findet

Mit Google Hacking kann man so viel anstellen, dass die folgenden Beispiele zwangsweise nur einen kleinen Ausschnitt darstellen können. Aber das reicht auch, denn wenn Sie die Grundkonzepte kennen, können Sie bei Bedarf leicht selbst passende Google-Anfragen für Ihren Zweck formulieren. Oder das Ganze auf eine andere Suchmaschine übertragen, denn natürlich funktioniert das alles auch zum Beispiel mit Bing, ggf. dann eben mit anderen Operatoren. Aber fangen wir an – passend zum Entwickler Magazin mit der Suche nach Webanwendungen mit bekannten Schwachstellen.

Aufmacherbild: Hacker in disguise with virtual lock symbols and icons on blue background von Shutterstock / Urheberrecht: ra2studio

[ header = Seite 2: Die Suche nach angreifbaren Webanwendungen ]

Die Suche nach angreifbaren Webanwendungen

Was braucht ein „Skript-Kiddie“, das einen Exploit für eine Webanwendung herunter geladen hat? Webserver, auf denen dieser Exploit ausprobiert werden kann. Und die liefert Google auf eine passende Anfrage. Wie sie aussehen muss, ist oft bereits im Exploit oder im zugehörigen Advisory angegeben. Bei Bedarf kann sie sich aber jeder auch selbst konstruieren. Üblich sind zwei Ansätze:
Die erste Möglichkeit besteht darin, nach der von der Webanwendung ausgegebenen Copyright-Meldung und der gewünschten Versionsnummer zu suchen. Gibt es keine Copyright-Meldung, tut es auch ein beliebiger anderer String, sofern er für die Webanwendung eindeutig ist. Beispiele für solche Google Dorks sind:

• „Powered By Dew-NewPHPLinks v.2.1b“ zur Suche nach einer Version des Linkverwalters Dew-NewPHPLinks, die eine SQL-Injection-Schwachstelle enthält und deren Administrationsbereich keine Authentifizierung erfordert [4].
• „Welcome to the CyberGuard unit!“ zur Suche nach CyberGuard-Appliances, die sich über die so gefundene Weboberfläche konfigurieren und ausspähen lassen (oder hoffentlich ließen, da dieser Dork schon älter ist) [5].
||Powered by [ClipBucket 2.0.91] zur Suche nach dem Videosharing-Skript ClipBucket, das zum Teil Default-Zugangsdaten für den Administrationsbereich verwendet [6].
intitle:“HtmlAnvView:D7B039C1″ zur Suche nach bestimmten Webcams, deren Default-Zugangsdaten zum Teil nicht geändert werden können, sodass man über die bekannten Zugangsdaten auf die Administrationsoberfläche und damit die Kameraaufnahmen zugreifen kann [7]. Konkret wird nach Seiten gesucht, in deren title-Tag der String „HtmlAnvView:D7B039C1“ vorkommt.
intext:“~~Joomla1.txt“ title:“Index of /“ zur Suche nach Verzeichnissen mit Konfigurationsdateien von Joomla! [8]. Konkret wird nach Verzeichnislisten gesucht, in denen die Datei ~~Joomla1.txt enthalten ist. Gefunden werden dadurch Joomla!-Installationen, bei denen das entsprechende Verzeichnis für den Google-Bot zugänglich ist.
intitle:awen intitle:asp.net zur Suche nach installierten ASP.NET-Webshells [9], wie sie zum Beispiel in der Linux-Live-CD BackTrack enthalten sind [10]. Gesucht wird nach Seiten, die beide Begriffe im title-Tag enthalten.
inurl:“tiki-index.php“ filetype:php „This is TikiWiki 1.9“ zur Suche nach Installationen von TikiWiki 1.9 [11]. Gesucht wird nach allen Seiten, in denen der String „This is TikiWiki 1.9“ vorkommt. Zusätzlich muss der String „tiki-index.php“ im URL der Seite vorkommen und ihr Filetype PHP sein.

Im letzten Beispiel wird also nach PHP-Skripten mit dem Namen „tiki-index.php“ gesucht, die den String enthalten. Alle anderen Seiten, auf denen der String vorkommt, die aber einen anderen Dateinamen oder Type haben, werden von Google nicht ausgegeben. Denn an denen hat der Angreifer ja kein Interesse.

In der Google Hacking Database finden Sie eine Vielzahl von entsprechenden Anfragen und in den Exploits in der Exploit DB [12] viele weitere.

Die Suche nach Fehlermeldungen

Statt nach bekanntermaßen angreifbaren Webanwendungen zu suchen, kann ein Cyberkrimineller auch nach Webanwendungen mit möglichen Schwachstellen suchen. Oder genauer: nach Fehlermeldungen. Denn die verraten häufig (zu) viel über Anwendung und Webserver. Beispiele für solche Suchanfragen sind:

„Unable to jump to row“ „on MySQL result index“ „on line“ [13]
„Warning:“ „failed to open stream: HTTP request failed“ „on line“ [14]
„Warning: Supplied argument is not a valid File-Handle resource in“ [15]
„Warning: mysql_connect(): Access denied for user: ‚*@*“ „on line“ -help -forum [16]

Der Nachteil dieser Anfragen: Auch Diskussionen über diese Fehlermeldungen, zum Beispiel in Foren oder Usenet-Newsgroups, erscheinen im Ergebnis. Im letzten Beispiel werden solche Seiten durch die Angabe von „-help –forum“ ausgefiltert.

Die Suche nach Schwachstellen

Statt nach bekanntermaßen angreifbaren Webanwendungen zu suchen, kann ein Cyberkrimineller auch nach möglichen Schwachstellen im Code von Webanwendungen suchen. Wird zum Beispiel mit der Anfrage select.*from.*request.QUERYSTRING im Code für ASP-Anwendungen gesucht, liefert das Ergebnis mögliche über den ASP-Query-String ausnutzbare SQL-Injection-Schwachstellen. Entsprechende Anfragen sind für beliebige Programmiersprachen und Schwachstellen möglich, sofern es ein typisches Muster für die Schwachstellen gibt.
Die Ergebnisse der Suchmaschinen sind aber mit Vorsicht zu genießen. Nachdem Google das inzwischen eingestellte Google Code Search veröffentlicht hatte, kam es auf Mailinglisten wie Full-Disclosure oder Bugtraq zu einer Welle von Falschmeldungen angeblicher Remote- und Local-File-Inclusion-Schwachstellen in PHP-Skripten. Einige Leute haben damals alles, was irgendwie dem Muster include($parameter); oder include(„/pfad/zum/skript/“.$parameter); entsprach, als Remote bzw. Local File Inclusion gemeldet. In den meisten Fällen wurde der Parameter $parameter aber direkt oder zumindest nur wenige Zeilen über der angeblichen Fundstelle der Schwachstelle geprüft und/oder von möglichen Manipulationen bereinigt. Auf die Idee, ihre angebliche Schwachstelle vor der Veröffentlichung zu prüfen und evtl. sogar zu testen, waren die „Entdecker“ nicht gekommen.
Google Code Search wurde zwar eingestellt, aber es gibt noch einige Alternativen. Google selbst kann im Code von bei Google Code Hosting [17] gehosteten Projekten suchen. Außerdem gibt es weitere auf die Suche im Sourcecode spezialisierte Suchmaschinen wie GrepCode (spezialisiert auf Java-Sourcecode) [18], Ohloh Code Search [19], Krugle Open Search [20] und searchcode [21] – von GitHubs Suchfunktion, die Anfang des Jahres für die Suche im Sourcecode optimiert wurde, ganz zu schweigen. Und mit Githubs optimierter Suche lassen sich bekanntlich interessante Daten finden: Versehentlich hochgeladene Dateien mit sensitiven Informationen wie zum Beispiel privaten Schlüsseln [22]. Aber das ist eine andere Geschichte.

[ header = Seite 3: Webanwendungen schützen ]

Webanwendungen schützen

Eine Webanwendung können Sie im Allgemeinen nicht wirklich vor Google-Hacking-Angriffen verbergen. Denn das würde bedeuten, sie durch entsprechende Konfiguration der robots.txt-Datei (s. u.) aus Googles Index heraus zu halten, was meist dem Ziel, gefunden zu werden, widerspricht. Aber Sie können den Angreifern die Suche nach Opfern zumindest erschweren.
Fangen wir mit der Suche nach bestimmten Versionen einer Webanwendung an. Hier ist die Lösung ganz einfach: Geben Sie im Frontend keine Versionsinformationen aus. Den normalen Benutzer interessieren die sowieso nicht, und für den Administrator können Sie sie ja im Backend ausgeben.
Das Verbergen der Versionsnummer ist streng genommen „Security by Obscurity“, und das funktioniert bekanntlich nicht. Und in der Tat verschwindet eine Schwachstelle ja nicht, nur weil keine Versionsnummer ausgegeben wird. Aber wenn es keine Versionsinformationen gibt, weiß der Angreifer nicht vorab, ob ein Angriff Aussicht auf Erfolg hat oder nicht. Ihm bleibt nur die Möglichkeit, den Exploit auszuprobieren. Er kann sich also nicht schon bei der Durchsicht der Google-Ergebnisse die erfolgversprechenden Ziele rauspicken, was die Angriffe zumindest verlangsamt. Den Namen der Anwendung können Sie übrigens ruhig ausgeben, denn auch ohne den kann die Webanwendung zum Beispiel durch andere typische Strings auf der Seite oder Skript- und Verzeichnisnamen identifiziert werden.
Was die Fehlermeldungen betrifft: Auch die sollten Sie nicht ausgeben. Jedenfalls nicht so ausführlich. Den Benutzer interessieren diese Fehlermeldungen sowieso nicht, ganz im Gegenteil sorgen sie oft nur für Verwirrung. Für den Benutzer ist es wichtig zu erfahren, dass ein Fehler aufgetreten ist und wie er weiter verfahren soll. Welcher Fehler in welcher Zeile welches Skripts aufgetreten ist, ist nur für den Administrator und Entwickler von Belang. Diese Informationen gehören daher ins Logfile und nicht auf die an den Benutzer ausgegebene Seite. Denn da sieht sie der Admin oder Entwickler mit Ausnahme von Fehlern im Backend oder während eines Tests ja gar nicht.
Wie Sie verhindern, dass über Suchmaschinen Schwachstellen in Ihrer Webanwendung gefunden werden, haben Sie sicher schon erraten: Indem Sie keine Schwachstellen haben. Den Sourcecode nicht veröffentlichen oder Den Sourcecode nicht von Suchmaschinen indexieren lassen sind zwar auch mögliche Lösungen des Problems, aber damit verbergen Sie mögliche Schwachstellen nur. Irgendwann werden sie trotzdem entdeckt.

Die Suche nach Hardware

Bisher ging es überwiegend um Webanwendungen – schließlich ist das hier das Entwickler Magazin. Es gibt aber noch viele weitere interessante Dinge, die sich über Google und Suchmaschinen allgemein finden lassen, zum Beispiel mit dem Internet verbundene Hardware wie Router, Drucker oder Webcams:

• Die Weboberfläche von SpeedStream-Routern liefert die Anfrage: intitle:“SpeedStream * Management Interface“ [23]
• Belkin Router findet man zum Beispiel durch die Suche nach: intitle:“Setup Home“ „You will need * log in before * * change * settings“ [24]
• CyberGuard-Appliances lassen sich durch folgende Anfrage entdecken: „Welcome to the CyberGuard unit!“ [25]
• Die Weboberfläche von HP Laserjets findet man über intitle:“hp laserjet“ inurl:info_configuration.htm [26]
• Ihre Kollegen von Samsung liefert die Anfrage allintitle:“SyncThru Web Service“ [27]
• Xerox-Drucker können über die folgende Anfrage gefunden werden: „display printer status“ intitle:“Home“ [28]
• Verschiedene Webcams findet man zum Beispiel über die Anfragen
intitle:“EvoCam“ inurl:“webcam.html“ [29] (EvoCam-Kameras)
allintitle: Axis 2.10 OR 2.12 OR 2.30 OR 2.31 OR 2.32 OR 2.33 OR 2.34 OR 2.40 OR 2.42 OR 2.43 „Network Camera“ [30] (Axis-Kameras)
inurl:/control/userimage.html [31] (MOBOTIX-Kameras)
inurl:cgi-bin/guestimage.html [32] (MOBOTIX-Kameras)

Es gibt auch eine Suchmaschine, die sich auf die Suche nach Servern und Netzwerk-Devices spezialisiert hat: Shodan [33]. Die liefert meist bessere Ergebnisse als Google, da Google diese Geräte nur mehr oder weniger zufällig indexiert hat, weil auf ihnen ein Webserver läuft.

Die Suche nach Zugangsdaten

Benutzernamen und Passwörter können Cyberkriminelle immer brauchen – und mitunter auch über Suchmaschinen finden. Zum Beispiel mit folgenden Anfragen:

• Ganz allgemein Benutzerlisten findet man mit der Anfrage inurl:admin inurl:userlist [34]
• Webalizer-Statistikseite mit Benutzernamen liefert die Anfrage intext:webalizer intext:“total usernames“ intext:“Usage Statistics for“ [35]
• Logfiles des SSH-Clients putty mit Benutzernamen lassen sich mit der folgenden Anfrage finden: filetype:log username  putty [36]
• Exportierte Windows-Registries mit Benutzernamen gibt es mit der Anfrage filetype:reg reg HKEY_CURRENT_USER username [37]
• Und History-Files der Shell Bash, die mitunter auch Benutzernamen enthält, findet man mittels intitle:“Index of“ .bash_history [38]
• Logfiles mit Passwörtern liefern die Anfragen  „your password is“ filetype:log [39] und „admin account info“ filetype:log [40]
• Konfigurationsdateien mit Radius-Passwörtern kann man mit folgender Anfrage finden: filetype:cfg „radius“ (pass|passwd|password) [41]
• Auch der Datenbank-Dump von SQL-Datenbanken enthält mitunter Passwörter, egal ob allgemein filetype:sql „insert into“ (pass|passwd|password) [42]
speziell für MySQL: filetype:sql „MySQL dump“ (pass|password|passwd|pwd) [43]
PostgreSQL: filetype:sql „PostgreSQL database dump“ (pass|password|passwd|pwd) [44]
oder für WordPress-MySQL-Backups: filetype:sql inurl:wp-content/backup-* [45]

Schutzmaßnahmen

Das obige sind nur einige Beispiele. Aber die sollten verdeutlichen, dass Google Hacking nicht unterschätzt werden sollte. Zum Glück gibt es einige Möglichkeiten, den eigenen Server und die eigene Webanwendung zu schützen. Die wichtigste Grundregel ist dabei: Was nicht veröffentlicht werden soll, hat auf dem Webserver nichts zu suchen. Alles, was nur für bestimmte Personenkreise bestimmt ist, muss durch eine Authentifizierung und ggf. Autorisierung geschützt werden. Ansonsten helfen ein paar Grundregeln, Dateien vor den Crawlern der Suchmaschinen zu verbergen.

[ header = Seite 4: Keine Verzeichnislisten ]

Keine Verzeichnislisten!

Ein grundsätzliches Problem sind Verzeichnislisten, die daher im Webserver grundsätzlich ausgeschaltet werden sollten. Je nach Konfiguration geben manche Webserver eine Verzeichnisliste aus, wenn in einem Verzeichnis keine der vorgegebenen Indexdateien wie index.html, index.php oder default.asp vorhanden ist. In jedes Verzeichnis gehört deshalb eine Indexdatei, auch wenn es eine leere Datei ist.

robots.txt sperrt Crawler aus

Die Datei robots.txt dient dazu, die Crawler der Suchmaschinen komplett auszusperren oder von bestimmten Dateien und Verzeichnissen fern zu halten. Sie wird im Webroot-Verzeichnis gespeichert und legt fest, welche Dateien und Verzeichnisse die Crawler nicht beachten sollen. Die Datei enthält Einträge nach dem Muster

User-agent: [Name des Crawlers oder * als Wildcard]
Disallow: [Verbotene Verzeichnisse oder Dateien]

Außerdem sind durch # eingeleitete Kommentarzeilen erlaubt. Um alle Crawler aus dem Webserver auszusperren, genügen die Einträge

User-agent: *
Disallow: /

Feinere Einstellungen sehen Sie in Listing 1.

# Alle Crawler aus bestimmten Verzeichnissen aussperren: 
User-agent: *
Disallow: /bilder/
Disallow: /cgi-bin/
Disallow: /tmp/
# Einzelne Dateien für alle Crawler sperren:
User-agent: *
Disallow: /pfad/zur/ersten/datei.html
Disallow: /die/zweite-datei.html
Disallow: /und/eine/dritte.php
# Googles Bot aus dem Verzeichnis /git aussperren:
User-agent: Googlebot
Disallow: /git/
# Googles Bildersuche soll die privaten Bilder ignorieren:
User-agent: Googlebot-Image
Disallow: /bilder/privat/
# Ein-boeser-Spambot soll gefälligst draußen bleiben:
User-agent: Ein-boeser-Spambot
Disallow: /

Beim Einsatz der robots.txt-Datei müssen Sie zwei Dinge beachten:

1. Die robots.txt-Datei ist nur eine Bitte an die Crawler, sie müssen die Datei nicht beachten. Insbesondere bösartige Crawler, die zum Beispiel E-Mail-Adressen für Spammer sammeln sollen oder nach bekannten Schwachstellen suchen, ignorieren sie.
2. Die Datei ist für alle lesbar. Jeder kann sehen, welche Verzeichnisse Sie nicht in die Suchmaschinen aufgenommen haben wollen. Allein diese Information kann schon gefährlich sein, zum Beispiel wenn dadurch im Rahmen eines Social-Engineering-Angriffs Insiderwissen vorgetäuscht werden kann, z. B.: „Ich habe meinen Zugangscode für das Verzeichnis /nichts/für/Suchmaschinen/ vergessen, wie lautet der?“

Indexieren, aber nicht archivieren

Sollen Seiten zwar von den Suchmaschinen erfasst, aber nicht im Cache aufgenommen werden, müssen Sie in jeder dieser Seiten ein entsprechendes META-Tag im HEAD-Bereich der HTML-Datei setzen [47]. Einige Beispiele dazu:

<meta name=’robots‘ content=’noarchive‘> verbietet allen Suchmaschinen das Cachen der Seite.
<meta name=’Googlebot‘ content=’noarchive‘> verbietet Google das Cachen der Seite.
<meta name=’robots‘ content=’noindex‘> verhindert die Aufnahme einer Seite in den Index. Auf der Seite enthaltenen Links wird aber gefolgt.
<meta name=’robots‘ content=’nofollow‘> erlaubt die Indexierung der Seite, den enthaltenen Links wird aber nicht gefolgt.
<meta name=’robots‘ content=’noindex, nofollow‘> sorgt dafür, dass die Seiten nicht in den Index aufgenommen und den enthaltenen Links nicht gefolgt wird.
<meta name=’Googlebot‘ content=’nosnippet‘> ist speziell für Googles Crawler und verhindert, dass Google Ausschnitte übernimmt. Außerdem werden so markierte Seiten nicht in den Cache übernommen.

Fazit

Google Hacking ist kein Spaß, sondern eine ernst zu nehmende Bedrohung. Die Google Hacking Database [2] stellt nur einen Ausschnitt der möglichen Anfragen dar. Die Möglichkeiten, die das Google Hacking bietet, sind noch lange nicht vollständig ausgelotet.
Für die Gefährlichkeit des Google Hackings noch ein letztes Beispiel: Mit der Anfrage !Host=*.* intext:enc_UserPassword=* ext:pcf hat „Kayla“ von LulzSec erfolgreich nach Zugangsdaten zu VPNs gesucht [48]. Darüber war dann der Zugriff auf das lokale Netz der betroffenen Unternehmen und Organisationen möglich. Diese Dateien sollten bestimmt nicht auf einem Webserver liegen. Noch weniger sollten sie offen zugänglich sein – vom Indexieren durch die Suchmaschinen-Crawler ganz zu schweigen.
Achten Sie also darauf, welche Dateien Sie überhaupt auf dem Webserver speichern, auf welche davon der Zugriff ohne Authentifizierung möglich ist und welche von den Suchmaschinen-Crawlern indexiert werden.
Zu guter Letzt noch ein Hinweis auf ein relativ neues Forschungsprojekt: Von Stach & Liu wurde das Google Hacking Diggity Project [49] ins Leben gerufen, das sich mit der Untersuchung des Suchmaschinen-Hackings (speziell natürlich über Google und Bing, aber auch über spezielle Suchmaschinen wie Shodan) und der Entwicklung entsprechender Tools beschäftigt.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -