Zum Inhalt springen

Was hat Phishing mit Web Application Security zu tun?

Phishing [1] ist seit langem schon ein Problem in Ländern wie den USA und Australien. Jetzt hat es auch uns erreicht.

Was hat Phishing mit der Sicherheit von Webanwendungen – der Web Application Security - zu tun? Auf den ersten Blick wenig, kann doch ein Unternehmen zunächst einmal kaum etwas dazu, wenn irgendwo am anderen Ende der Welt ein Betrüger eine Website aufmacht, die so ähnlich heißt und genauso aussieht wie die eigene, und dann mit Spam-Mails und unter einem überzeugenden Vorwand die ahnungslosen Kunden auf diese Websites lockt, um sie dort zur Übergabe ihrer Kennung, ihres Passworts und beim Banking auch noch der TAN zu bewegen.

Doch der erste Augenschein trügt. Phishing ist ein Phänomen, das grundlegende Mängel beim Umgang mit der Sicherheit von Webanwendungen offenbart (und ausnutzt), und das wahrscheinlich nur die erste Erscheinungsform einer Vielzahl weiterer Täuschungstechniken darstellt. Schauen wir uns die beiden betroffenen Bereiche an:

(1) Die technische Ebene

Das, was zur Zeit passiert, das plumpe Fälschen einer Website, ist die einfachste Form dieser Art von Betrug. Der momentane schlechte Zustand der Sicherheit von Webanwendungen und Website bereitet einer weit raffinierteren Methode das Feld, die zudem schon bald nicht mehr nur Banken betreffen wird, sondern eine Bedrohung für die gesamte E-Commerce- und E-Business-treibende Wirtschaft darstellen wird. Mit dieser Angriffsform ist es möglich, gefälschte datenabfischende oder mit anderer Täuschungsabsicht versehene Inhalte in die Original-Webseite einzubauen, so dass weder an einem verletzten SSL-Zertifikat (es bleibt intakt!) noch an einem veränderten Hostnamen im URL (der Original Hostname wird angezeigt, da die Seite ja auch vom Originalserver geladen worden ist) zu erkennen ist, ob die angezeigte Seite nun echt oder manipuliert ist. Die Schwachstelle, die hier ausgenutzt wird, ist das sogenannte Cross-Site Scripting (XSS). Nach unseren Untersuchungen haben heute noch immer rund 80% aller Websites mindestens eine solche Sicherheitslücke. Und das, obwohl das CERT bereits in 2000 [2] davor gewarnt hat.

(2) Die semantische Ebene

Phishing würde kein größeres Problem darstellen, wenn es jedem Benutzer genauso selbstverständlich wäre, dass er seine Benutzerkennung und Passwort nicht in ein Formular eingeben darf, das er über einen Link in einer Email oder von einer fremden Website aus erreicht hat, wie es für ihn selbstverständlich ist, dass er die PIN zu seiner EC-Karte nicht nennt, wenn er auf der Strasse danach gefragt wird. Weil dem Benutzer das aber bisher kaum jemand gesagt hat (erst jetzt wird damit begonnen, entsprechende Warnhinweise zu platzieren und Sicherheit auch in diesem Punkt vorzuleben), er im Gegenteil sogar tagtäglich die Erfahrung macht, dass ihn Online-Kaufhäuser, Payment-Dienste, der eigene Webspace-Provider und andere sensible Anwendungen (bis vor kurzem sogar Banken) in Emails genau dazu auffordern, ist er Phishing-Angriffen momentan recht schutzlos ausgeliefert. Einzig die fehlende Authentizität der in den Emails verwendeten Ansprache bewahrt die meisten wohl noch davor, zum Opfer derartiger Betrugsversuche zu werden. Doch auch hier gilt, mit der Aufklärung des Benutzers allein in diesem Punkt ist es nicht getan. Betrüger werden die besagte Sicherheitslücke in Anwendungen ausnutzen, da diese ihnen raffiniertere Techniken ermöglicht [3]. Und sie werden auch hier auf einen weitgehend unvorbereiteten Benutzer treffen, weil dieser nicht in der Lage ist, Verdacht zu schöpfen.

Denn: Viele Unternehmen konditionieren ihre Website-Besucher zur Zeit in einer Weise, die Betrügern direkt in die Hände spielt. Da geht auf der Homepage eines Unternehmens ein Popup auf, das Werbung einblendet, eine Umfrage dazwischenschiebt oder andere Dinge in den Vordergrund bringt, die eigentlich nicht zur Sache gehören. Da ist die Passwortvergabe oder Passworteingabe in einer Weise gelöst, die dem Benutzer zeigt, dass er mit diesen Dingen ruhig sorglos umgehen darf. Und es werden aktive Inhalte (JavaScript, Flash) eingesetzt, die zwar den Erfordernissen des Marketings gerecht werden, nicht jedoch denen der Sicherheit.

Für einen Betrüger ist es leicht, einem so konditionierten Internetnutzer etwas unterzuschieben, so dass dieser das dem besuchten Unternehmen zuordnet und es im Vertrauenskontext des Unternehmens interpretiert. Bereits eine einzige XSS-Schwachstelle, irgendwo auf demselben Host oder in derselben Domain, verschafft dem Betrüger die Möglichkeit, in der beschriebenen Weise zu agieren. Der Internetnutzer wird keinen Verdacht schöpfen, wenn da plötzlich ein überlappendes Fenster auftaucht oder eine eingestreuter Link ganz woanders hinweist. Er ist es von dieser Website ja so gewohnt. In [3] haben wir eine Reihe möglicher zukünftiger Szenarien beschrieben.

Was ist zu tun?

Der Nutzer, Kunde, Geschäftspartner ist angesichts der Schwächen der heutigen Webtechnologie nicht in der Lage, sich ausreichend zu schützen. Der versierte Anwender wohl noch etwas besser, die breite Masse der weniger versierten hat so gut wie keine Möglichkeit. So ist es an dem Anbieter, auch für die Sicherheit seiner Kunden und Partner Verantwortung zu übernehmen! Er muss einer solchen Bedrohung auf der Ebene der Implementierung und auf der Ebene der Semantik begegnen:

  • Web Application Security ist in die qualitätssichernden Prozesse einer Webanwendung oder Website als fester Bestandteil zu integrieren, so dass Sicherheitslücken wie die beschriebene erkannt und beseitigt werden, bevor die Anwendung online geht.
  • Die einzelne Anwendung sowie der gesamte Auftritt im Web sind auch nach semantischen Gesichtspunkten strengen Sicherheitsrichtlinien zu unterwerfen. Diese müssen darauf abgestellt sein, dass der Anwender durch eine Konstanz im Erscheinungsbild und in der Kommunikation auf Abweichungen automatisch mit Misstrauen reagiert. Wir sprechen vom Identitätsprinzip.

Die SecureNet GmbH berät Sie in allen Fragen der Web Application Security. Für uns ist die Betrachtung der semantischen Ebene dabei ein selbstverständlicher Bestandteil.

Einen Überblick über die Web Application Security finden Sie hier.

Referenzen

[1] "Passwort-Fischer" http://www.bsi-fuer-buerger.de/abzocker/05_08.htm
[2] "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" http://www.cert.org/advisories/CA-2000-02.html
[3] "Über die unbegrenzten Möglichkeiten für Täuschung und Betrug im Web"

Cross-Site Scripting - XSS

XSS tritt immer dann auf, wenn eine Webanwendung Eingaben des Anwenders ohne Filterung wieder in eine Webseite einbaut. Der wohl häufigste Fall ist die Wiedergabe in der auf die Eingabe direkt folgenden Antwortseite. Typisch: Die Antwort auf eine Suchanfrage lautet: "Die Suche nach München hat leider keine Treffer geliefert. Bitte versuchen Sie es erneut". Die Benutzereingabe, hier München, wird in der Antwortseite wiederholt. Ein einfacher Test zeigt, ob eine XSS-Schwachstelle vorliegt:

Wir geben folgenden Suchstring ein:

Münche<i>n


Wenn nun das Ergebnis lautet:

Die Suche nach 'München' hat leider keine Treffer geliefert.

also statt des eingegebenen <i> wird der auf die Eingabe folgende Text kursiv dargestellt, dann ist bereits klar, dass wir es hier mit XSS zu tun haben. Denn das wird nicht als Nutztext angezeigt, sondern als HTML-Code interpretiert (<i> steht für das Umschalten auf Kursivschrift). Ein Blick in den Quellcode gibt weiteren Aufschluss:

<P>Die Suche nach 'Münch<i>en' hat leider keine Treffer geliefert.

Der unterstrichene Textteil ist das, was der Anwender eingegeben und die Anwendung (hier das Suchprogramm) unverändert wieder ausgegeben hat. Der Browser stellt dies auch genauso dar, d.h. stellt kursiv, was auf das <i> folgt.

Richtig wäre gewesen, die Zeichen < und > in die Sequenz umzuwandeln, die der Browser auch als 'größer' und 'kleiner' darstellt. Das wären als HTML-Entity die Codes &lt; bzw. &gt; gewesen. Die Ausgabe hätte dann richtig gelautet:

Im Quellcode:

<P>Die Suche nach 'Münch&lt;i&gt;en' hat leider keine Treffer geliefert.

und im Browser:

Die Suche nach 'Münch<i>en' hat leider keine Treffer geliefert.

Eine andere Möglichkeit des Umgangs mit derartigen Eingaben wäre das Löschen von Zeichen wie < und > gewesen.

Die korrekte Wiedergabe in der Antwortseite ist übrigens noch kein Beweis dafür, dass an dieser Stelle keine XSS-Schwachstelle vorliegt. Es existieren vielfältige Möglichkeiten, es 'falsch' zu machen. Dies kann höchstens als ein Indiz dafür gewertet werden, dass die Softwareentwickler an genau dieser Stelle korrekt gearbeitet haben.

Damit ist der Sachverhalt, der dem XSS zugrunde liegt, auch schon erklärt. Natürlich wird ein Angreifer es nicht darauf anlegen, den Anwender durch Änderung der Formatierung zu ärgern...

Stichwort Vertrauenskontext

Vertrauenskontext ist das Umfeld, das bestimmt, wie viel Vertrauen wir einer Sache entgegenbringen. Auf das Spendenformular, das in unserer Bank am Schalter liegt, übertragen wir das (in der Regel hohe) Vertrauen, welches wir der Bank selbst entgegenbringen. Wäre die Hilfsorganisation nicht seriös, würde unsere Bank das Formular nicht auslegen. Dasselbe Formular in der Fußgängerzone von einem obskuren Vermittler verteilt hätte es deutlich schwerer, bei uns die Schwelle des Misstrauens zu überwinden. Oder nehmen wir die vorgeblich lohnende und absolut risikolose Geldanlage. Sie hat kaum eine Chance, wenn sie vom freundlichen aber fremden Finanzberaters um die Ecke mit großen Worten angepriesen wird. Wir kennen den nicht, wissen aber, dass es in der Branche nicht gerade seriös zugeht. Also schenken wir der Sache nur wenig bis gar kein Vertrauen. Ganz anders jedoch, wenn uns der ARD-Ratgeber Geld diese Geldanlage ans Herz legt. Die Seriosität dieses Magazins überträgt sich auf das besprochene Produkt. Noch ein Beispiel. Der unglaublichen Enthüllungsstory schenken wir eher Glauben, wenn wir sie in der Süddeutschen lesen (hoher Vertrauenskontext) als wenn wir sie dem Exklusiv-Bericht der Regenbogenpresse entnehmen (geringer Vertrauenskontext).

Voraussetzung dafür, dass diese Art der Herleitung von Vertrauen funktioniert, ist, dass wir uns der Echtheit der Kriterien, die wir für die Bewertung des Vertrauens heranziehen, auch versichern können. Hält uns der Finanzberater die Zeitschrift FINANZTEST unter die Nase, in der die von ihm gelobte Geldanlage entsprechend gut abgeschnitten hat, dann werden wir ihm nicht unterstellen, dass er das Heft gefälscht hat. Das wäre wohl zu aufwändig und am Kiosk könnten wir uns jederzeit von der Echtheit überzeugen. Wir haben also ein Kriterium an der Hand, das uns hilft, den Grad an Vertrauen, den wir dieser Sache entgegenbringen, recht verlässlich zu bestimmen.

So vorgeprägt begeben wir uns ins Internet und übersehen dabei, dass die vermeintlich sicheren Kriterien, die den Vertrauenskontext herstellen, höchst manipulierbar sind. Eine Webseite, die exakt so aussieht, wie die uns vertraute Anmeldemaske zum Online-Banking, macht uns Glauben, dass wir uns auch auf der Website der Bank – in vertrauenswürdigem Umfeld – befinden. Wir bedenken nicht, dass es für einen Betrüger außerordentlich leicht ist, eine gefälschte Webseite irgendwo im Internet abzulegen. Und so geben wir unsere Zugangsdaten ohne weitere Echtheitsprüfung in die Anmeldemaske ein und damit geradewegs in die falschen Hände.

Identitätsprinzip

Der Anwender ist in die Lage zu versetzen, Manipulationen, Fälschungen und Täuschungen zu erkennen. Dazu muss er im Umgang mit der Website, aber auch in der gesamten Kommunikation mit dem Unternehmen, gelernt haben, dass das Unternehmen bestimmte Konventionen durchgängig einhält. Sind diese Konventionen einmal verletzt, wird er automatisch misstrauisch und legt auf einmal eine Vorsicht an den Tag, die es einem Betrüger deutlich erschwert, sein Ziel zu erreichen. Diese Konstanten und Konventionen sollten dem Anwender darüber hinaus explizit mitgeteilt werden, und es sollten Verhaltenshinweise für den Fall der Verletzung genannt werden.

Das Prinzip, welches auch der Corporate Identity eines Unternehmens zugrunde liegt, nämlich die Schaffung einer unverwechselbaren Identität und eines Wiedererkennungseffektes, wird mit dieser Maßnahme auf die Online-Kommunikation zum Zweck der Herstellung von mehr Sicherheit auf der semantischen Ebene angewandt.