Johanne Ulloa

Ne pas confondre  WAF (WEB Application Firewall) et  WAF (Women Acceptance factor)

Si l’on s’en réfère à ce  lien, WAF signifie également « We Are the Future » !

Qu’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 insu.

Comment cette attaque est réalisée ?

Les attaques XSS/CSRF sont généralement exécutées en 4 phases :

Phase 1 :  L’injection de code sur le serveur vulnérable

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 …)

Phase 2 : obtention du code malveillant

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.

Phase 3 and 4:  Execution du code

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.

Que faire contre ce type d’attaques ?

Il est possible d’agir sur le serveur et sur le client

Côté serveur :

• 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’est-à-dire que tout ce qui pourra être envoyé à l’application par l’utilisateur devra être « nettoyé » et validé.
• Pour empêcher que le cookie de session soit accessible via javascript, il est possible de les marquer avec le flag : HTTPOnly.
• Utiliser un Firewall Applicatif Web de façon à prémunir le serveur Web des injections de code.

Coté client :

• Je vous recommande fortement l’usage de Firefox et du plugin NoScript. Ce plugin pemet de n’activer javascript qu’à la demande.  Son rapport « Sécurité apporté/Contraintes d’utilisation » est très bon.

Qu’est-ce que Twitter ?

Twitter est un site communautaire dans lequel les membres postent des informations courtes les concernant ou concernant leur communauté. On peut le qualifier de « micro-blogue ». Il est possible de suivre l’actualité de personnes. On devient dans ce cas le « follower » de la personne et l’on a accès aux éléments postés par cette personne.

Peut-on parler d’un ver ?

Un ver est un programme externe qui sera téléchargé puis exécuté sur l’ordinateur. Dans ce cas, le ver profite simplement de certaines faiblesses du navigateur et du serveur WEB pour se « reproduire ». Aucune présence de programme externe n’est donc nécessaire. Il convient donc mieux de parler d’un « ver WEB » ou « ver XSS/CSRF » car ce ver exploite des vulnérabilités de « Cross-site scripting (XSS) » et de « Cross-site request forgery (CSRF) ».

Concrètement que fait-il ?

Les motivations du jeune hacker (17 ans) ne sont pas claires. C’est sans doute pour gagner en notoriété qu’il a mis au point ce ver. Ce dernier poste de façon automatique à la place d’un utilisateur légitime, un message incitant ses « followers » à aller visiter un site Web. Si une personne clique sur ce lien, le même sort lui est réservé. (Ses « followers » verront que cette personne a posté un message incitant à aller visiter ce site WEB)

Quel est son mode opératoire ?

Tout d’abord, le ver utilise une faille XSS. Le XSS ou (cross site scripting) permet à un attaquant de faire exécuter du code javascript ou html au navigateur de l’utilisateur.
Ce type d’attaque est le plus souvent utilisé pour récupérer les cookies de sessions de l’utilisateur ou pour modifier l’apparence du site WEB.
En l’occurrence, dans ce cas li s’agit de récupérer le cookie de session  de l’utilisateur.

Une fois le cookie récupéré une requête Ajax est forgée de façon automatique avec votre cookie session (ce cookie sert de gage au serveur WEB pour déterminer si la requête vient de vous). Cette requête simule totalement ce que vous auriez fait en temps qu’utilisateur pour poster un message incitant vos « followers » à se rendre sur un site WEB.
Dans la deuxième version du ver, le simple fait de visiter la page twitter d’une personne « infectée » permet de déclencher l’attaque.

Quels sont les impacts de ce type d’attaque ?

Dans ce contexte précis, l’impacte pour les utilisateurs était très faible (poste d’un message à la place de l’utilisateur légitime). Toutefois, l’attaquant prend le contrôle du navigateur pour le forcer à réaliser des actions; on peut donc imaginer les dégâts que peuvent réaliser ce type d’attaques sur des sites sensibles, car ce scénario peut également être perpétré sur des sites traditionnels.

Le mécanisme est maintenant bien rodé sur des sites communautaires. Sans être devin, il est fort à parié que ce genre d’attaque sera perpétué sur d’autres type de sites. On imagine bien le potentiel de ces attaques : forcer un utilisateur à acheter ou vendre un bien ou un service … Les hackers ne sont limités que par leur imagination et la robustesse des systèmes de sécurité qu’ils trouveront face à eux.

Le trafic généré par ce type de ver doit aussi être pris en considération, car il peut mettre à mal la disponibilité du site WEB.

Comment se prémunir de ce type de ver ?

Si vous avez un serveur WEB et que vous souhaitez prémunir vos clients de ce type de vers, on peut:

· Prendre en compte les aspects de sécurité lors du développement d’applications WEB (validation des données envoyées par l’utilisateur);

· Renforcer le control des en utilisant des bibliothèques qui épurent les éléments transmis par les l’utilisateur (Par exemple AntiSamy );

· Taguer les cookies de sessions avec le flag HTTPOnly . Ce flag permet d’interdire l’accès au cookie de session via java script rendant les attaques XSS qui ciblent les cookies de session inefficaces.

· Utiliser un Firewall Applicatif WEB (WAF)  .Cet équipement situé devant le serveur WEB permet de bloquer les tentatives d’injections de code.( Il peut aussi flaguer à la volée les cookies de session en HTTPOnly si l’on n’a pas de contrôle sur l’applicatif )

Si vous êtes utilisateur:

· Utiliser noscript sur Firefox (ce module permet de n’activer java script qu’au cas par cas).

Johanne Ulloa