Passwortklau für Dummies

Viele sehen in Cross Site Scripting nach wie vor keine echte Gefahr, weil sie damit verunstaltete Seiten und alberne Popup-Meldungen nicht beeindrucken. Diese Demo zeigt haarklein, wie man damit Passwörter auf echten Login-Seiten klauen kann.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 6 Min.
Inhaltsverzeichnis

ACHTUNG: Der eigentliche Artikeltext ist im Legacy-Feld damit das Demo-Skript in der Zwischenüberschrift funktioniert! Der RTE-Inhalt wird somit nicht ausgegeben.

Das Sicherheitskonzept von JavaScript beruht fast vollständig auf der Herkunft von Code, also der sogenannten Same-Origin-Policy. Code, der vom selben Webserver stammt wie eine Webseite, genießt besonderes Vertrauen. Er darf dann nahezu alle Elemente der Web-Seite lesen und sogar verändern, auch während diese bereits im Browser dargestellt wird. Cross Site Scripting ist der Versuch, sich genau diese Rechte zu erschleichen. Dazu schiebt ein Angreifer Ihrem Browser Code so unter, dass es aussieht, als käme er vom selben Server wie beispielsweise eine Login-Seite.

Stellen Sie sich vor, diese Demo-Login-Seite wäre die reguläre Anmelde-Seite des Heise-Servers. Klicken Sie auf den Link, probieren Sie den Login aus, schauen Sie sich den HTML-Code an. Die Seite enthält nichts besonderes, es ist nur ein einfaches Formular, das die eingegebenen Daten im Klartext an sich selbst verschickt. Sie tauchen dann als Parameter "username=" und "password=" in der Adresszeile des Browsers auf. Benutzen Sie also zum Ausprobieren keine echten Passwörter.

Und nun stellen Sie sich vor, dieser Artikel hier enthielte bösartigen Script-Code, den ein Angreifer irgendwie eingeschmuggelt hat. Hier kommt unsere kleine Demo ins Spiel. Wenn Sie den Demo-Link unten anklicken, öffnet sich wieder die oben vorgestellte Demo-Login-Seite. Und zwar die echte keine billige Fälschung wie bei herkömmlichen Phishing-Attacken. Sie können das an der URL in der Adresszeile des neuen Fensters und dem HTML-Code überprüfen. Es ist die selbe, harmlose Login-Seite.

Und doch ist diesmal alles anders. Denn nun hält der bösartige Code alle Fäden in der Hand. Er hat im Hintergrund eine unsichtbare Wanze angebracht, die heimlich alles mitlauscht. Wenn Sie auf den Login-Button klicken, erscheint eine Alert-Box, die Ihr Passwort anzeigt. Diese Meldung hat der dann doch nicht ganz so böse böse Code erzeugt. Er hat das Passwort aus der Demo-Login-Seite ausgelesen und angezeigt; genausogut hätte er es natürlich heimlich an einen externen Server im Internet schicken können. Die Demo-Login-Seite selbst bekommt von dieser Schnüffelei nichts mit und funktioniert wie gewohnt.

All das hätte auch automatisiert vor sich gehen können, sobald Sie diese "böse" Seite aufrufen. Der Code könnte dann im Hintergrund warten, bis Sie die Login-Seite selber öffnen, um sich anzumelden. Oder er könnte den Log-Out-Button betätigen, eine plausible Nachricht über einen Timeout anzeigen, die Sie zum erneuten Login auffordert. Sie müssen lediglich ihr Passwort auf der Login-Seite eingeben und nicht einmal das, wenn ein Passwort-Manager das automatisch erledigt. Dann könnte der Passwortklau sogar komplett automatisiert und heimlich im Hintergrund erfolgen. All diese Gemeinheiten, werden derzeit in passende Exploit-Module verpackt, sodass Angreifer sie einfach in ihre XSS-Attacken einbauen können.

Der Klick auf "Demo" oben aktivierte JavaScript-Code. Der öffnete die echte und harmlose Demo-Login-Seite in einem neuen Fenster. Da sie aber vom selben Server stammt wie der JavaScript-Code, greift die Same-Origin-Policy und der Code hat alle Rechte, die Elemente dieser Seite auszulesen und deren Attribute zu verändern während sie im Browser angezeigt wird. Konkret nutzte er diese Rechte, eine zusätzliche onsubmit-Funktion an das Formular anzuhängen, die ausgeführt wurde, als Sie "Login" anklickten. Dabei las sie das Passwort aus dem Eingabefeld und zeigte es in der Alert-Box an. Das funktioniert mit jedem Browser der JavaScript unterstützt, inklusive Internet Explorer, Firefox, Opera, Safari und so weiter.

Dieser "böse" JavaScript-Code ist kein Hexenwerk, sondern im Gegenteil geradezu primitiv. Deshalb ist auch nichts dabei, ihn hier zu präsentieren:

function open_steal_login() { 
mylogin = window.open("demo-login.html");
mylogin.onload = function() {
mylogin.document.forms[0].onsubmit = stealit;
}
}

function stealit() {
alert('Ihr Passwort lautet: ' +
mylogin.document.forms[0].password.value + ' !');
}

Ein Klick auf den Demo-Link aktiviert open_steal_login(). Das öffnet ein neues Fenster mit "demo-login.html" und die onload-Function hängt nach dem Laden stealit() an das Formular an. Das war's schon.

Für diesen Passwortklau muss der Angreifer irgendwie JavaScript auf einem Server einschleusen können oder es zumindest für den Browser so aussehen lassen, als käme sein Code von diesem Server. Dann kann er jegliche Inhalte von diesem Server und die Kommunikation mit ihm beliebig manipulieren. Im Allgemeinen betrifft dies Seiten, die Eingaben von Anwendern nicht ausreichend filtern; beispielsweise auf Seiten, die Anwender selbst gestalten können, in Foren oder das klassische Cross Site Scripting Szenario, bei dem Web-Applikationen bestimmte Parameter mit "><script>... erneut ausgeben und so dem Anwender unterschieben. Für derartige Angriffe und diese Demo muss natürlich im Browser des Anwenders JavaScript aktiviert sein.

Das ist richtig schwierig! Trauen Sie keinen Seiten, die es Anwendern erlauben, Seiten mit JavaScript zu erstellen. Andererseits könnte der Code auch via XSS eingeschmuggelt werden. Also trauen Sie auch keinen Seiten, die anfällig für XSS-Attacken sind. Aber hey woher sollte Sie wissen, welche das sind, ohne jede Seite einzeln zu testen? Das erwischt auch die Besten; selbst Bankenseiten sind immerwieder von derartigen Problemen betroffen. Sicherheitsdienstleister, die im Auftrag von Firmen Webseiten testen, schwärmen nicht umsonst von Erfolgsquoten jenseits der 90 Prozent.

Wer JavaScript komplett abschaltet, ist auf der sicheren Seite. Aber für die Meisten ist das keine echte Alternative, weil immer mehr Web-Seiten ohne gar nicht mehr funktionieren. Beim Internet Explorer kann man immerhin mit dem Zonen-Modell arbeiten und Active Scripting nur für die Zone der vertrauenswürdigen Sites gestatten.

Bei Firefox kann man mit der Erweiterung NoScript JavaScript zunächst verbieten und dann über eine sorgfältig zusammengestellte Ausnahmeliste vetrauenswürdigen Seiten wieder gestatten. Des weiteren enthält NoScript einige zusätzliche XSS-Schutzfunktionen, die wir allerdings bislang noch nicht getestet haben. Darüber hinaus kann man nur raten: Halten Sie die Augen offen, bewahren Sie sich ein gesundes Misstrauen und hoffen Sie auf gutes Karma. (ju)