<?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>Johanne Ulloa &#187; xss</title>
	<atom:link href="http://johanne.ulloa.org/category/attacks/xss/feed" rel="self" type="application/rss+xml" />
	<link>http://johanne.ulloa.org</link>
	<description>Just another blog about Web Application Security  :-)</description>
	<lastBuildDate>Tue, 15 Sep 2009 17:12:20 +0000</lastBuildDate>
	<language>fr</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
		<item>
		<title>Qu&#8217;est-ce qu&#8217;une attaque XSS/CRSF et comment s&#8217;en prémunir</title>
		<link>http://johanne.ulloa.org/how-xsscrsf-attaks-can-be-stopped.html</link>
		<comments>http://johanne.ulloa.org/how-xsscrsf-attaks-can-be-stopped.html#comments</comments>
		<pubDate>Wed, 22 Apr 2009 17:16:44 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[attacks]]></category>
		<category><![CDATA[csrf]]></category>
		<category><![CDATA[xss]]></category>

		<guid isPermaLink="false">http://localhost:89/?p=7</guid>
		<description><![CDATA[Qu&#8217;est-ce qu’une attaque XSS/CSRF ? Ce type d’attaque cible l’utilisateur en utilisant une vulnérabilité du serveur WEB. Le but étant de forcer le navigateur de la cible (l’utilisateur) à envoyer des requêtes au serveur. Ces requêtes paraitront donc tout à fait légitimes aux yeux du serveur et la cible réalisera donc des actions à son [...]]]></description>
			<content:encoded><![CDATA[<h3>Qu&#8217;est-ce qu’une attaque XSS/CSRF ?</h3>
<p>Ce type d’attaque cible l’utilisateur en utilisant une vulnérabilité du serveur WEB. Le but étant de forcer le navigateur de la cible (l’utilisateur) à envoyer des requêtes au serveur. Ces requêtes paraitront donc tout à fait légitimes aux yeux du serveur et la cible réalisera donc des actions à son insu.</p>
<h3>Comment cette attaque est réalisée ?</h3>
<h4>Les attaques XSS/CSRF sont généralement exécutées en 4 phases :</h4>
<h4>Phase 1 :  L’injection de code sur le serveur vulnérable</h4>
<p>Lors de cette phase, le pirate injecte le code (qui peut-être html, css ou javascript) sur le serveur Web. Rappelons que si le serveur Web n’est pas sensible à l’injection de code ou qu’il est protégé par un WAF, l’attaque ne pourra être menée. (à bon entendeur …)</p>
<h4>Phase 2 : obtention du code malveillant</h4>
<p>Le navigateur obtient le code malveillant injecté précédemment par le pirate. Bien souvent, ce code est hébergé sur un serveur tier, dans ce cas, le but de la phase 1 sera d’injecter un lien vers ce code malveillant.</p>
<h4>Phase 3 and 4:  Execution du code</h4>
<p>Lors de celle phase, le navigateur exécute le code malveillant. Bien souvent, ce code consiste dans un premier temps à récupérer le cookie de session de l’utilisateur de façon à l’utiliser dans les requêtes qui seront forgées par la suite. Ceci permettra de rendre ces requêtes tout à fait légitimes au regard de l’application Web.</p>
<h3><img class="aligncenter size-large wp-image-217" title="XSS CSRF 4" src="/wp-content/uploads/2009/04/XSS-CSRF-41-1024x948.png" alt="XSS CSRF 4" width="644" height="597" /></h3>
<h3>Que faire contre ce type d’attaques ?</h3>
<p>Il est possible d’agir sur le serveur et sur le client</p>
<p>Côté serveur :</p>
<ul>
<li>Il faut prendre en compte la sécurité      applicative lors des phases de développement. Principalement en contrôlant      les « input » de l’utilisateur. C&#8217;est-à-dire que tout ce qui      pourra être envoyé à l’application par l’utilisateur devra être « nettoyé »      et validé.</li>
<li>Pour empêcher que le cookie de session soit accessible      via javascript, il est possible de les marquer avec le flag : <a href="http://www.owasp.org/index.php/HTTPOnly">HTTPOnly</a>.</li>
<li>Utiliser un <a href="http://www.denyall.com/">Firewall Applicatif Web</a> de façon à prémunir le serveur Web des injections de code.</li>
</ul>
<p>Coté client :</p>
<ul>
<li>Je vous recommande fortement l’usage de      Firefox et du plugin <a title="Noscript" href="http://noscript.net/">NoScript</a>. Ce plugin pemet de n’activer javascript      qu’à la demande.  Son rapport &laquo;&nbsp;Sécurité apporté/Contraintes d&#8217;utilisation&nbsp;&raquo; est très bon.</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://johanne.ulloa.org/how-xsscrsf-attaks-can-be-stopped.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
