Sécurité des web services - les attaques

mieux protéger une application internet

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
L'apparition d'un nouveau communiquant nomade a bouleversé le monde du web, plutôt stable depuis le début du XXIe siècle. Désormais la communication ne se passe plus uniquement à travers le câble. De plus en plus de gens sont connectés à l'extérieur, certains pas forcément avec les ordinateurs. Tout cela a contribué au développement de nouveaux moyens de transfert de données, et notamment dans les web services. Ils, comme toute transmission d'informations, sont mis en danger.

A travers cette série d'articles on verra comment protéger les web services. Tout d'abord on se concentrera sur les différentes attaques que peuvent subir les API. On verra qu'une grande partie ressemble beaucoup aux failles détectées dans des applications web "classiques". C'est pourquoi ce type d'attaques sera traité au tout début. Plus loin on abordera des dangers propres aux web services.

Pollution des paramètres
Le premier danger commun entre les web services et des applications web est lié à l'introduction des paramètres inattendus (par exemple une chaîne de caractères au lieu d'un integer). Cela peut mener à des failles bien connues : le XSS et le SQL injection.

L'un des moyens de se protéger contre ces vulnérabilités est la validation des paramètres avant leur soumission dans l'application. Pour cela on peut utiliser le WSDL (Web Services Description Language) ou les schémas XML (XSD - XML Schema Definition). Le premier définit l'ensemble des opérations pouvant être effectuées par le web service. Il détermine également comment les paramètres doivent être structurés avant d'être exécutés.

Concernant les schémas XML, c'est un document qui décrit la structure statique des paramètres. Il permet de préciser des détails plus importants, comme par exemple la longueur maximale d'un champ ou le pattern RegEx qu'il doit valider pour qu'un paramètre soit accepté.

Vol des sessions
Le vol des session concerne également les web services. Le danger principal repose sur le fait que l'échange entre le client et le fournisseur ne soit pas crypté. Grâce à cela la personne qui "écoute" cet échange peut facilement intercepter les informations et se faire passer pour le client.

La première solution à mettre en place est le protocole SSL/TLS. Cela garantira l'échange crypté entre le client et le web service. Un autre moyen de protection est XML signature. Cette recommandation du W3C permet de s'assurer que les informations transmises ont été bien demandées par le destinataire et bien emises par l'expéditeur. Elle permet donc une transmission intégrale des données entre les parties autorisées.

Attaques DOS
Dans la plupart des cas les web services ont pour but d'ouvrir l'accès à une application à une personne tiers. Il est donc évident que les attaques DOS et DDOS ont une porte ouverte.

Parmi les cibles d'attaques on peut distinguer :
- surcharge de la structure des documents : l'attaquant analyse d'abord le schéma de validation. Il choisit sa cible et y précise une valeur incorrecte. Ensuite, à partir de cet élément, il crée une arborescence infinie, composée uniquement d'élément sélectionné. On peut l'illustrer par cet exemple dans lequel la balise <wall /> devrait contenir un seul caractère :

<?xml version="1.0" encoding="UTF-8"?>
<home>
<wall>
<wall>
<wall>
<wall>
<wall>12</wall>
</wall>
</wall>
</wall>
</wall>
</home>


- surcharge de la taille du document : l'attaquant peut également soumettre une requête trop grande, dont le parseur ne sera pas capable de traiter à cause de la consommation de mémoire trop importante.
- replay attack : cette attaque se base sur l'envoi des requêtes à répétition dans de petites intervalles du temps. Elle peut mener à la surcharge du web service, liée par exemple à la validation des schémas par le parseur XML.

DTD Entity Reference Attack
Document Type Definition (DTD) est une sorte de dictionnaire qui sert à décrire l'organisation d'un document XML. Grâce à lui on peut préciser par exemple qu'une balise ne peut pas contenir une autre ou qu'une balise doit posséder un attribut. Voici un DTD d'exemple :

<!DOCTYPE order [
<!ELEMENT order ANY>
<!ELEMENT cust_name ANY>
<!ENTITY customer "your customer name">
]>
<!-- ENTITY : you can access them by &ENTITY_NAME; at your XML document (in our case, we will able to call &customer; which will display "your customer name" -->


Cependant, le DTD peut être à l'origine d'un attaque qu'on nomme DTD Entity Reference Attack. Il s'agit ici d'exploiter une faille liée à la disponibilité des entités dans les documents XML. Supposons une telle répons envoyé à la requête du client http://mywebservice/getFileInfo?name=$fileName&result=$result;


<?xml version="1.0"?>
<!DOCTYPE os [
<!ENTITY fileName SYSTEM "$fileName">
]>
<os>
<fileResult>$result</fileResult>
</os>


Supposons maintenant que l'utilisateur malveillant envoie la requête suivante http://mywebservice/getFileInfo/?name=etc/passwd/&result=&fileName; qui donnera la réponse :


<?xml version="1.0"?>
<!DOCTYPE os [
<!ENTITY fileName SYSTEM "/etc/passwd">
]>
<os>
<fileResult>&fileName;</fileResult>
</os>


Dans cet exemple le parseur XML convertit le fichier recherché en une chaîne de caractères qui sera envoyé dans la réponse sous l'entité &fileName; . C'est de cette façon que l'attaquant a pu voir la liste des mots de passes du système. Bien sûr, le cas est un peu extrême, mais il a pour but d'illustrer clairement la vulnérabilité de DTD Entity Reference Attack .

XPath injection
Un autre danger auquel peut être exposé notre web service est XPath injection. Il s'agit ici, comme dans le cas de SQL injection, d'une mauvaise validation des données entrantes. Pour un petit rappel, XPath est un langage qui permet d'analyser l'ensemble d'un document XML. Il ressemble un peu aux chemins d'accès connus aux utilisateurs Windows. Dans ce système on retrouve le répertoire EA Sports sous le chemin C:/Program Files/EA Sports. Imaginons la même chose sous XML :

<?xml version="1.0"?>
<c>
<program_files>
<ea_sports>
<fifa1999 />
</ea_sports>
</program_files>
</c>

Pour se placer dans le noeud ea_sports, il faudra employer XPath suivant : /c/program_files/ea_sports .

A priori donc XPath n'a rien de dangereux. Cependant mal implémenté, il peut causer quelques soucis au niveau de notre application. Dans le cas du web service de notre librairie en ligne, supposons que l'on rajoute un rabais de 30% si le client saisit le code promotionnel "BUY_NOW". Le XPath de validation peut se présenter ainsi :


/order/code='BUY_NOW'


Et voici la structure du document XML à valider :

<?xml version="1.0"?>
<order>
<code />
<books>
<book />
</books>
</order>


L'attaquant peut assez facilement surpasser cette validation, tout comme dans le cas du SQL injection, en envoyant des paramètres inattendus par l'application :
 
?code=null' or '1' = '1


Notre application va d'abord chercher le code dans la base (cela ne donnera rien) et ensuite le mettre dans la réponse qui sera la suivante :


<?xml version="1.0"?>
<order>
<code />
<books>
<book collection="Les cahiers de programmeur">Java EE 5</book>
<book collection="Les cahiers de programmeur">Symfony</book>
<book collection="Les cahiers de programmeur">Zend Framework</book>
</books>
</order>


Dans la prochaine étape, l'application va se charger de décider s'il faut appliquer le rabais en exécutant le XPath de validation défini précédemment. Cependant, à cause des paramètres incorrects, cette formule va se présenter de cette manière et elle va toujours renvoyer true :

/order/code='null' or '1' = '1'


Et voici un bout de code PHP pour exécuter le XPath de validation et voir l'effet de cette XPath injection :

$params = array("null' or '1' = '1", "bad one");
$doc = '<?xml version="1.0" encoding="UTF-8"?>
<order>
<code>
</order>';
echo "Analyzing document : ".htmlspecialchars($doc)."

";

$domCl = new DOMDocument();
$domCl->loadXML($doc);
$xpath = new DOMXPath($domCl);
foreach($params as $param)
{
$x = $xpath->evaluate("/order/code='".$param."'");
echo "
Evaluating /order/code='".$param."'";
echo "
XPath expression result is ".(int)$x."
";
}


Le web service ne se différencie pas beaucoup d'une application web accessible par un internaute via son navigateur. Il est également vulnérable aux dangers du web basés sur, très souvent, un trop grand laxisme dans le filtrage des paramètres entrants. Il ne faut donc pas négliger cet aspect même dans le cas d'un langage banal de balises comme XML.
Bartosz KONIECZNY 14-05-2012 19:28 sécurité des applications web
Un conseil Symfony1

Comment inclure un template commun pour plusieurs modules ?

Le fichier à inclure (par exemple _menu.php) devrait être stocké dans le répertoire templates de l'application en question.

Ensuite, dans notre fichier de layout (par exemple layout.php), il suffit d'appeler le helper include_partial : Le répertoire global signifie que le template est global et n'appartient pas à un module particulier.