© istockphoto.com/VLADGRIN, © istockphoto.com/enotmaks
Websecurity ist ein alter Hut? Das sehen Sicherheitsforscher anders!

Forschungsfeld Webanwendung


Sie denken, im Bereich der Websecurity wurden längst alle möglichen Schwachstellenarten und Angriffe entdeckt, und es gibt nichts Neues mehr zu entdecken? Dann haben Sie die Rechnung ohne Sicherheitsforscher gemacht!

Dem kann ich nur ein „Zum Glück“ hinzufügen. Denn Sicherheitsforscher veröffentlichen ihre Forschungsergebnisse, sodass Sie zumindest eine Chance haben, Ihre Webanwendungen abzusichern, bevor es die ersten Angriffe „in the wild“ gibt. Die Cyberkriminellen wären nicht so rücksichtsvoll, die würden sofort zuschlagen.

Zum Glück (zum zweiten Mal) haben die zumindest bisher kein besonderes Interesse am Erforschen neuer Angriffe gezeigt. Wieso auch, wenn sie doch mit Angriffen auf die bekannten Schwachstellen auch ans Ziel kommen? Solange die Webentwickler weiter Fehler machen, durch die die altbekannten Schwachstellen entstehen, gibt es für die Cyberkriminellen keinen Grund, nach neuen Möglichkeiten für Angriffe zu forschen. Und weil es viele Admins mit der Installation sicherheitsrelevanter Updates nicht besonders eilig haben, müssen die Cyberkriminellen oft nicht mal nach neuen Schwachstellen suchen, sondern können alte, eigentlich längst behobene, aber auf dem angegriffenen Server nicht gepatchte Schwachstellen ausnutzen.

Aber gucken wir mal, was die Sicherheitsforscher in letzter Zeit Neues entdeckt haben.

Rechner oder Mensch, das ist hier die Frage!

Oft steht der Betreiber einer Webanwendung vor dem Problem, Zugriffe von Benutzern von denen durch Bots oder andere Tools zu unterscheiden. Wobei erschwerend hinzukommt, dass bei Bots meist noch zwischen den bösartigen Bots der Cyberkriminellen und den gutartigen Bots wie zum Beispiel den Crawlern der Suchmaschinen unterschieden werden muss.

Um automatisierte Angriffe zu erschweren, setzt man gerne auf CAPTCHAs. Sofern es nur darum geht, den Spamschutz eines Blogs auszuhebeln oder haufenweise Accounts bei Freemail-Providern oder Social Networks anzulegen, setzen die Cyberkriminellen zu deren Lösung oft auf simple Manpower. Es gibt Anbieter, die CAPTCHAs für ein sehr geringes Entgelt pro gelösten CAPTCHA von Menschen lösen lassen. Dagegen ist natürlich keine Gegenwehr möglich, die CAPTCHAs sollen ja von Menschen gelöst werden können und funktionieren in diesem Fall genau wie vorgesehen.

Für Brute-Force-Angriffe und Ähnliches eignet sich dieser Ansatz natürlich nicht, außerdem ist ein Rechner immer billiger als jeder noch so günstige dieser „Wir lösen Ihr CAPTCHA für Sie“-Anbieter. Deshalb gibt es immer wieder erfolgreiche Versuche, CAPTCHA-Systeme von Algorithmen brechen zu lassen. Was dann im Allgemeinen dazu führt, dass CAPTCHAs noch schwerer lösbar gemacht werden, was aber oft genug die Menschen mehr stört als die Algorithmen.

Wie es mit der Unterscheidung von Benutzern und Bots insgesamt sowie der Sicherheit von CAPTCHAs im Besonderen zurzeit aussieht, zeigen zwei Vorträge.

So unterscheidet man Bots von Menschen

Ryan Mitchell hat auf der DEF CON 23 einen allgemeinen Überblick über das Problem gegeben: „Separating Bots from the Humans“ [1]. Dabei ging sie von Bots aus, die für Web Scraping genutzt werden, also das Sammeln von Daten von Websites, ähnlich wie es auch ein Suchmaschinen-Crawler macht. Das Ganze lässt sich aber auch für beliebige Bots verallgemeinern.

Es gibt eine Reihe mehr oder weniger erfolgreicher Maßnahmen, um Bots auszusperren:

robots.txt – Bots bitte draußen bleiben!

Die robots.txt-Datei ist nur eine Bitte an die Bots, bestimmte Bereiche oder den gesamten Webserver nicht zu betreten, was von böswilligen Bots natürlich ignoriert wird. Und womöglich macht sie die Cyberkriminellen sogar erst auf die Bereiche aufmerksam, die für sie interessant sein könnten.

Bots verstoßen gegen die Nutzungsbedingungen!

Über Nutzungsbedingungen lässt sich der Einsatz von Bots verbieten. Da die aber sowieso kaum jemand liest, kann man da bekanntlich alles Mögliche reinschreiben, einschließlich des Rechts auf das erstgeborene Kind des Benutzers [2]. Und einen Cyberkriminellen stören irgendwelche Verbote in den Nutzungsbedingungen sowieso nicht. Die Angriffe sind im Allgemeinen schon durch Gesetze verboten, und wer die bricht, wird sich nicht daran stören, wenn er zusätzlich gegen die Nutzungsbedingungen verstößt. Formal kann man den Angreifer dann vielleicht wegen dieses Verstoßes zusätzlich vor Gericht zerren, aber dafür muss man ihn erst mal erwischen.

Header? Wer vertraut denn Headern?

Header sind bekanntlich nicht die Elektronen wert, aus denen ihre Bits bestehen. Die Header des Clients kann der Angreifer nach Belieben fälschen, die des Servers ebenso nach Belieben ignorieren. Man kann zwar versuchen, darüber Zugriffsregeln und Ähnliches durchzusetzen, einen bösartigen Bot kann man damit aber nicht stoppen.

Wenn die Webanwendung zum Beispiel prüft, ob der Client die für einen Browser typischen Header mitschickt, dann kann der Bot genau diese Header fälschen. Und sich zum Beispiel als ein Chrome-Browser und Mac OS X, ein Firefox unter Windows 7 oder ein Edge unter Windows 10 ausgeben. Oder wie wäre es mit einem Edge unter Mac OS X? Den gibt es zwar nicht, einen Header mit einem entsprechenden User-Agent-Eintrag zu schicken, wäre aber kein Problem.

Ohne JavaScript geht nichts

So ähnlich ist es bei JavaScript-Code, der eine Indexierung der Website verhindern soll. Das klappt nur, sofern der Bot sich nicht daran zu schaffen macht, was ein Cyberkrimineller mit ziemlicher Sicherheit tun wird. Damit sperrt man also nur die gutartigen Bots aus, und die will man ja eigentlich auf seiner Website haben.

Text in Bildern verstecken, das ist ja sowas von alt

Das Einfügen von Texten als Bilder soll theoretisch das Ausspähen dieser Texte durch Bots verhindern. Das ist eine tolle Idee, jedenfalls wenn man seine Benutzer ärgern will, denen dadurch der Zugriff auf den Text über Copy and Paste unmöglich gemacht wird. Die Cyberkriminellen lachen nur darüber. „Texterkennung“, sie wissen schon – einmal mit der OCR drüber gehen und der Cyberkriminelle freut sich über den Klartext. Für einen bösartigen Bot ist das nur ein Arbeitsschritt mehr. Ein gutartiger wird das Bild dagegen vermutlich ignorieren.

CAPTCHAS – Das Rennen ist im Gang, der Ausgang offen

CAPTCHAs galten lange Zeit als das Mittel gegen eine automatisierte Nutzung der Webanwendung. Inzwischen sind die oft für die Benutzer schwerer zu lösen als für die Tools der Cyberkriminellen. Und da gerade von OCR die Rede war: Die lässt sich auch zum Lösen von CAPTCHAs verwenden, sie muss nur entsprechend trainiert werden, was für die Tesseract-OCR der von Ryan Mitchell entwickelte tesseract-trainer [3] übernimmt.

Mit dem Finger im Honigtopf ertappt

Honeypots, die (hoffentlich) nur von den bösartigen Bots aufgesucht werden, sollen helfen, die bösartigen Zugriffe zu erkennen. Ein typisches Beispiel dafür sind unsichtbare Formularfelder mit für den Bot verlockendem Namen, die ein Benutzer nie ausfüllt (da er sie nicht sieht), der Bot dagegen schon. Requests an die Webanwendungen, in denen diese eigentlich immer leeren Parameter Daten enthalten, stammen von einem Bot und können verworfen werden. Dieser Ansatz hat zwei Nachteile: Zum einen fallen unter Umständen auch gutartige Bots auf den Trick herein, zum anderen können entsprechend angepasste bösartige Bots unsichtbare Eingabefelder erkennen und ignorieren.

Ab zum Psychologen!

Die Auswertung von Verhaltensmustern kann bei der Erkennung von Bots helfen, denn die Bots besuchen eine Website anders als Menschen. Zum Beispiel „lesen“ die Bots viel schneller als ein Mensch, und sie scrollen im Allgemeinen auch nicht auf der Seite nach unten, da sie ja die gesamte Seite auf einmal „lesen“. Googles reCAPTCHA nutzt diesen Ansatz bereits.

Und noch ein Wettrennen, das Sie aber verlieren werden

Das Blockieren von IP-Adressen bekannter Bots artet im Zweifelsfall in einem Wettlauf aus, den der Websitebetreiber verliert, da die Cyberkriminellen ihre IP-Adresse sehr schnell wechseln können. Außerdem besteht immer die Gefahr, echte Benutzer auszusperren.

Irgendwie klappt das alles nicht so richtig

Insgesamt sieht es mit der Erkennung von Bots und ihrem Aussperren aus der Webanwendung also nicht besonders gut aus. Als Beispiel hat Ryan Mitchell das Kopieren von Amazons „Blick ins Buch“-Seiten vorgeführt.

Da sich Bots kaum aussperren lassen, schlägt Ryan Mitchell in der Präsentation vor, sich nicht mehr darum zu kümmern. Eine Website vor Bots zu schützen, ist viel zu aufwendig und stört meist ihre Zugänglichkeit. Soweit es das Ausspähen von Daten betrifft, sollte man sich fragen, ob die Daten den Aufwand wirklich wert sind. Vielleicht kann man ja das Bezahlen von Daten so attraktiv machen, dass ein Diebstahl sich nicht lohnt. Und wenn eine Anwendung anfällig für automatisierte Angriffe ist, dann ist das eben so. Punkt.

Im Vortrag selbst kommt dieser Teil (vermutlich aus Zeitgründen) nicht mehr vor, aber das wäre der Moment, an dem ich mir virtuell an die Stirn getippt hätte. Mit dem Argument könnte man ja jede Schwachstelle ignorieren. Ihr PHP-Skript ist anfällig für eine Remote File Inclusion? Pech gehabt, ist der Server halt Freiwild für die Cyberkriminellen. Ihre Datenbankabfragen erlauben SQL Injection? Na und, wird eben Ihre Kundendatenbank kopiert, was soll’s?

Aber selbst wenn es „nur“ automatisierte Angriffe sind, für die die Anw...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang