“Schwachstellen in Standardsoftware und Webauftritten werden häufig für Angriffe genutzt” (bsi.bund.de)
Aus dem PDF Seite 12:
Cross-Site-Scripting
Ein weiteres Problem ist das „Cross-Site-Scripting“: Dabei nimmt eine Webanwendung Daten von einem Nutzer an und sendet sie ungeprüft an einen anderen Browser weiter. So kann ein Angreifer zum Beispiel Skripte auf dem Rechner seines Opfers ausführen.
<sezier>
Dabei nimmt eine Webanwendung Daten von einem Nutzer an
Richtig…
und sendet sie ungeprüft
richtig…
an einen anderen Browser weiter.
nicht so ganz richtig.
</sezier>
Reflexives Cross-Site Scripting
Bei reflexivem XSS sendet das Opfer unbemerkt selber den Schadcode an den Server, der von diesem zurückgesendet und vom Browser des Opfers interpretiert wird.
Der Angreifer verteilt eine mit unerwünschtem Code erweiterte URL, via Kurz-URL (bit.ly, tinyurl.com, goo.gl, etc.) über Twitter, Skype, Facebook, Blogs, Kommentare jeglicher Art oder meinetwegen auch per E-Mail, an seine Opfer. Das Opfer klickt den Link zur Kurz-URL an und sendet damit den unerwünschten Code selber an den Server. Bei dem Code handelt es sich meist um JavaScript, HTML und/oder CSS. Der Server verarbeitet diesen Code aber nicht, sondern sendet ihn ungefiltert (die XSS-Lücke) an den Client, den Browser des Opfers, zurück und dieser interpretiert dies.
Szenario:
Ein Angreifer findet eine XSS-Lücke in einer Website, beispielsweise in der der Harvard University:
http://news.harvard.edu/gazette/
?s=</script><script>alert('Dumpfbacken!')</script>
bit.ly macht daraus: http://bit.ly/gU9q96
Der Angreifer verteilt nur diese Kurz-URL.
Da die meisten Opfer arglos sind, klicken sie den Link zur Kurz-URL an und schon sind sie in die Falle getappt und… sehen in diesem Fall nur eine JavaScript-Alert-Meldung. Bei einem echten böswilligen Angriff bemerkt das Opfer gar nicht, dass im Hintergrund, für ihn nicht sichtbar, etwas geschehen ist, zum Beispiel das Auslesen des Session-Cookie, mit deren Hilfe sich der Angreifer in den Account des Opfers einschleichen kann.
Also noch einmal für die Lernschwachen… ;O)
Ein Angreifer
- findet eine XSS-Lücke,
- nutzt Kurz-URL-Dienste zum verschleiern der manipulierten URL und
- verteilt diese Kurz-URL.
Das Opfer
- klickt auf den Link zur Kurz-URL. Der Aufruf mit der manipulierten URL erfolgt vom Browser des Opfers.
- Der Server sendet den Schadcode zurück an den Absender, den Browser des Opfers.
- Der zurückgesendete Code führt dann im Browser des Opfers, den meist destruktiven Code des Angreifers aus, der aber vom Opfer selber an den Server gesendet wurde.
Wer nun bei “Kurz-URL” nur an GET-Request denkt, also wo der Schadcode direkt in der Adresszeile des Browsers sichtbar ist, der sollte bedenken: Im Breitband-Zeitalter sind auch Weiterleitungen, die erst über ein Formular auf der Website eines Angreifers laufen (POST-Request), so schnell, dass diese den meisten Opfern nicht auffallen werden. Auch in Anbetracht der manchmal undurchsichtigen Weiterleitungen verschiedener Trackingsysteme zur Aufzeichnung des Nutzerverhaltens, wird der Surfer keinen Verdacht schöpfen.
<fund_am_rande>
Hängt man an die bit.ly-Kurz-URL ein Pluszeichens (+), so kann man neben der Statistik (wie oft die URL aufgerufen wurde, woher der Aufruf kam) auch den “Long Link” sehen, damit man weiß wohin man weitergeleitet wird.
Hänge ich nun an die obige bit.ly-URL das Pluszeichen ran, sehe ich auch den JavaScript-Alert, was mal wieder zeigt: Viele, sehr viele Websites sind Anfällig für Cross-Site Scripting.
</fund_am_rande>
Persistentes Cross-Site Scripting
Auch hier findet ein Angreifer eine XSS-Lücke in einer Website, aber hier wird der Schadcode auf dem Server gespeichert. Foren, Gästebücher, Kommentare oder auch die Profilseiten eines registrierten Benutzers der Website können entsprechende Lücken aufweisen, um ausführbaren Code zu speichern. Das Opfer wird in diesem Fall auf eine regulär erscheinende URL verwiesen, der man nicht ansehen kann, dass dahinter ein Angriff verborgen ist.
Für diesen Fall könnte man die Aussage des BSI zum Teil gelten lassen — wenn man gnädig ist. ;O)
Am häufigsten trifft man auf reflexives Cross-Site Scripting, wahrscheinlich weil Entwickler noch immer meinen, was der Server nicht speichert, das kann auch nicht gefährlich sein.
Weiter von Seite 12 des PDFs:
Über das „Cross-Site-Scripting“ werden nicht nur die Anbieter, sondern auch die Benutzer der Webseite angegriffen, was einen hohen Imageverlust für den Anbieter bedeutet.
Das Ziel von XSS-Angriffen sind meist die Besucher einer Website und nicht der Anbieter selber. Ist z.B. mal wieder eine Lücke in Twitter bekannt, so ist beispielsweise das Ziel der Angriffe, unbemerkt einen Wurm von anderen Benutzern weiterverbreiten zu lassen. Hierbei soll die Reputation der Benutzer ausgenutzt werden. Der Betreiber, also Twitter selber, ist hierbei nicht das Ziel des Angriffs. Der Wurm kann Code enthalten um Zugangsdaten zu stehlen oder um einfach nur einen Link zu einem Shop mit Blauen-Pillen zu verbreiten.
Mir geht es hier nicht darum, das BSI vorzuführen, sondern darum, dass sich Missverständnisse erst gar nicht weiter verbreiten. Es kommt eben manchmal doch auf die Korinthe an die gekackt werden muss.
