<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Security und Seo Blog &#187; Crosssite Scripting</title>
	<atom:link href="http://www.in-security.net/tag/crosssite-scripting/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.in-security.net</link>
	<description>Mein Blog über SEO, Sicherheit, Internet und die Welt</description>
	<lastBuildDate>Mon, 02 Aug 2021 14:29:11 +0000</lastBuildDate>
	<language>de-DE</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
		<item>
		<title>Cross-Site Scripting</title>
		<link>http://www.in-security.net/sicherheit/cross-site-scripting/</link>
		<comments>http://www.in-security.net/sicherheit/cross-site-scripting/#comments</comments>
		<pubDate>Thu, 14 Jul 2011 19:49:27 +0000</pubDate>
		<dc:creator>toni</dc:creator>
				<category><![CDATA[Sicherheit]]></category>
		<category><![CDATA[Cross Site Scripting]]></category>
		<category><![CDATA[Crosssite Scripting]]></category>
		<category><![CDATA[XSS]]></category>

		<guid isPermaLink="false">http://www.in-security.net/?p=702</guid>
		<description><![CDATA[Cross-Site-Scripting (kurz XSS) ist wohl einer der häufigsten Angriffe auf Webapplikationen überhaupt. Obwohl das Prinzip altbekannt ist, tauchen immer wieder neue Seiten im Netz auf, die entweder nicht gegen JavaScript-Manipulationen geschützt sind oder eben dieses Verfahren unterschätzen. Im Prinzip sind XSS-Angriffe immer gleich aufgebaut: Über eine Lücke in der Parameterüberprüfung versucht der Angreifer seinen eigenen JavaScript-Code einzuschleusen, der anschließend auf dem Clienten ausgeführt wird. Ein einfaches Beispiel: &#60;!-- Der Benutzer soll seinen Namen eingeben und wird begrüßt --&#62; &#60;form action="" method="POST"&#62; Name: &#60;input type=“text“ name=“user“ /&#62; &#60;input type=“submit“ name=“greeting“ value=“Grüße mich!“ /&#62; &#60;/form&#62; &#60;?php if (isset($_POST['user'])) { //Formularinhalt ungefiltert ausgegeben echo „Hallo “.$_POST['user'].“!“; } ?&#62; Daten, die im vorherigen Formular eingegeben werden, werden anschließend ungefiltert über den ECHO-Befehl ausgegeben. Gibt ein Angreifer also anstelle seines Namens ein JavaScript-Code ein, so wird dieser ausgeführt, beispielsweise: &#60;script&#62;alert('Dies ist ein XSS-Test');&#60;/script&#62; Schon wäre ein erster XSS-Angriff gelungen; allerdings ein sehr kleiner, zugegebenermaßen. Jedoch wäre der Angreifer nun zumindest um die Erkenntnis reifer, dass an dieser Stelle eine JavaScript-Code-Einschleusung möglich ist. Gefährlich ist dieses Beispiel natürlich noch für keine Seite – schlussendlich wird der Code ja nur auf dem Rechner des Angreifers selbst ausgeführt. Anders verhält es sich dagegen, wenn noch eine Datenbankanbindung besteht: [...]
Keine ähnlichen Artikel vorhanden.]]></description>
			<content:encoded><![CDATA[<p>Cross-Site-Scripting (kurz XSS) ist wohl einer der häufigsten Angriffe auf Webapplikationen überhaupt. Obwohl das Prinzip altbekannt ist, tauchen immer wieder neue Seiten im Netz auf, die entweder nicht gegen JavaScript-Manipulationen geschützt sind oder eben dieses Verfahren unterschätzen.</p>
<p>Im Prinzip sind XSS-Angriffe immer gleich aufgebaut: Über eine Lücke in der Parameterüberprüfung versucht der Angreifer seinen eigenen JavaScript-Code einzuschleusen, der anschließend auf dem Clienten ausgeführt wird.</p>
<p>Ein einfaches Beispiel:</p>
<pre style="padding-left: 30px;">&lt;!-- Der Benutzer soll seinen Namen eingeben und wird begrüßt --&gt;
&lt;form action="" method="POST"&gt;
Name: &lt;input type=“text“ name=“user“ /&gt;
&lt;input type=“submit“ name=“greeting“ value=“Grüße mich!“ /&gt;
&lt;/form&gt;</pre>
<pre style="padding-left: 30px;">&lt;?php
if (isset($_POST['user']))
{
	//Formularinhalt ungefiltert ausgegeben
	echo „Hallo “.$_POST['user'].“!“;
}
?&gt;</pre>
<p>Daten, die im vorherigen Formular eingegeben werden, werden anschließend ungefiltert über den ECHO-Befehl ausgegeben. Gibt ein Angreifer also anstelle seines Namens ein JavaScript-Code ein, so wird dieser ausgeführt, beispielsweise:</p>
<pre style="padding-left: 30px;">&lt;script&gt;alert('Dies ist ein XSS-Test');&lt;/script&gt;</pre>
<p>Schon wäre ein erster XSS-Angriff gelungen; allerdings ein sehr kleiner, zugegebenermaßen. Jedoch wäre der Angreifer nun zumindest um die Erkenntnis reifer, dass an dieser Stelle eine JavaScript-Code-Einschleusung möglich ist.</p>
<p>Gefährlich ist dieses Beispiel natürlich noch für keine Seite – schlussendlich wird der Code ja nur auf dem Rechner des Angreifers selbst ausgeführt. Anders verhält es sich dagegen, wenn noch eine Datenbankanbindung besteht: Schafft es der Angreifer beispielsweise in einem Forum, XSS-Code innerhalb seines Beitrages zu platzieren, so wird dieser bei jedem Betrachten des Beitrages interpretiert – und auf denjenigen Benutzer angewandt, der gerade dann unschuldig durchs Forum surft.</p>
<p>Solch ein JavaScript-Code würde natürlich im seltensten Fall ein simples ALERT-Fenster aufrufen. Dagegen ist es wahrscheinlicher, dass der Angreifer jeden Forennutzer zum Beispiel auf eine andere Seite weiterleitet (ggf. sogar kombiniert mit einem Phishing-Angriff!) oder versucht, die benutzereigenen Cookies auszulesen (unter Umständen sogar hilfreich bei einem Session-Diebstahl, der sehr gefährliche Auswirkungen haben kann).</p>
<p>Auch wenn es auf dem ersten Blick also ungefährlich scheint, können XSS-Angriffe sehr stark sein und sollten niemals unterschätzt werden.</p>
<p>Verhältnismäßig einfach ist dagegen der Schutz gegen XSS. Gemäß dem Leitsatz „<strong>Vertraue nie Eingaben, die vom Benutzer kommen!</strong>“ hilft eine gute Parameterüberprüfung vor möglicher Manipulation.</p>
<p>So ist es angebracht, sämtliche Benutzereingaben vor der Verwertung (speichern in Datenbank, Ausgeben, ..) von allen HTML-Tags durch die PHP-Funktion strip_tags() zu bereinigen. Um im Anschluss noch zu verhindern, dass Angreifer ihr HTML manipulieren, muss auf die Benutzereingaben htmlentities() angewandt werden. Die PHP-interne „Magic Quotes“ reichen nicht aus und sind -abgesehen davon- als DEPRECATED markiert.</p>
<p>Eine Absicherung des obigen Beispiels gegen XSS-Angriffe würde also so aussehen:</p>
<pre style="padding-left: 30px;">&lt;!-- Der Benutzer soll seinen Namen eingeben und wird begrüßt --&gt;
&lt;form action="" method="POST"&gt;
Name: &lt;input type=“text“ name=“user“ /&gt;
&lt;input type=“submit“ name=“greeting“ value=“Grüße mich!“ /&gt;
&lt;/form&gt;</pre>
<pre style="padding-left: 30px;">&lt;?php
if (isset($_POST['user']))
{
	$strip = strip_tags($_POST['user']);
	$gegenXSS = htmlentites($strip, ENT_QUOTES);
	//Formularinhalt gefiltert ausgegeben
	echo „Hallo “.$gegenXSS.“!“;
}
?&gt;</pre>

<!-- using Like-Button-Plugin-For-Wordpress [v4.5.2] | by Stefan Natter (http://www.gb-world.net) -->
<iframe src="http://www.facebook.com/plugins/like.php?href=http://www.in-security.net/sicherheit/cross-site-scripting/&amp;layout=standard&amp;show_faces=false&amp;width=400&amp;action=like&amp;colorscheme=light&amp;height=30&amp;locale=de_DE" scrolling="no" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:400px; height:30px"></iframe>
<!-- using Like-Button-Plugin-For-Wordpress [v4.5.2] | by Stefan Natter (http://www.gb-world.net) -->
<p>Keine ähnlichen Artikel vorhanden.</p>]]></content:encoded>
			<wfw:commentRss>http://www.in-security.net/sicherheit/cross-site-scripting/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
