De plus en plus souvent, les vols de donnes et les incidents lis aux applications Web font la

une de l'actualit de la scurit. Les attaques ont des consquences qui peuvent tre nuisibles
l'image de marque de l'entreprise, voire dans le pire des cas, au bon fonctionnement de son
systme d'information.
Dans ce contexte, nos experts vous apportent leurs savoir-faire en scurit applicative.
L'objectif vis est de garantir la scurit sur le plan applicatif des applications Web,
permettant ainsi de limiter fortement les risques lis la possibilit de pouvoir modifier le
contenu du site (action appele dfacement du site), de rcuprer des informations
confidentielles, d'usurper uneidentit, de pntrer dans le rseau local, ou d'utiliser le site
des fins malveillantes. Une scurit des applications bien pense interdit donc lutilisateur
mal intentionn de modifier le comportement de lapplication initialement
programme.

Une analyse des faits montre de manire vidente que la scurit au niveau de
l'infrastructure rseau n'est pas suffisante, mais qu'il faut galement scuriser
l'application Web elle-mme. En effet, les pare-feux classiques peuvent se rvler
inefficaces contre les offensives transitant par HTTP. Lagresseur de lapplication
utilise des requtes valides en passant par des ports connus, de sorte que les
pare-feux rseau, de par leur conception, autorisent volontairement ce trafic
pourtant nuisible. Llment nuisible nest pas la requte elle-mme mais les
donnes quelle contient. Souvent, ces donnes dangereuses sont des donnes
entres par lutilisateur, spcialement formates dans le but de modifier le
comportement de lapplication.

Les vulnrabilits au niveau des applications Web sont nombreuses et les plus
connues sont le Cross-Site Scripting et l'injection SQL.
Le Cross Site-Scripting est une technique de piratage qui repose sur un principe
simple : certaines pages dun site Web utilisent des donnes fournies par un
utilisateur sans que leur contenu soit contrl. Un utilisateur malintentionn peut
alors en profiter pour glisser dans ces donnes du code HTML et JavaScript
pernicieux, qui sexcutera sur le poste de la victime. Et en fonction du
programme insr, le degr de malveillance diffrera : vol de session, accs au
disque dur etc.

Le terme cross-site scripting n'est pas une description trs prcise de ce type de
vulnrabilit. Mark Slemko, pionnier du XSS, en disait :
Le problme n'est pas simplement le 'scripting', et il n'y a pas forcment quelque chose entre
plusieurs sites. Alors pourquoi ce nom ? En fait, le nom a t donn quand le problme tait
moins bien compris, et c'est rest. Croyez-moi, nous avions des choses plus importantes
faire que de rflchir un meilleur nom.

 Mark Slemko, Cross Site Scripting Info , sur The Apache HTTP Server
Project, fvrier 2000
Le principe est d'injecter des donnes arbitraires dans un site web, par exemple en dposant
un message dans un forum, ou par des paramtres d'URL. Si ces donnes arrivent telles
quelles dans la page web transmise au navigateur (par les paramtres d'URL, un message
post) sans avoir t vrifies, alors il existe une faille : on peut s'en servir pour faire
excuter du code malveillant en langage de script (du JavaScript le plus souvent) par le
navigateur web qui consulte cette page.
La dtection de la prsence d'une faille XSS peut se faire par exemple en entrant un script
Javascript dans un champ de formulaire ou dans une URL :
<script type="text/javascript">alert('bonjour')</script>

Si une bote de dialogue apparat, on peut en conclure que l'application Web est sensible aux
attaques de type XSS.

Linjection SQL permet une personne malintentionne dutiliser lapplication

pour interagir avec la base de donnes. Le principe repose sur la modification du
comportement dun appel vers la base de donnes en y injectant des portions de
code (par lintermdiaire des paramtres dun formulaire par exemple). On peut
envisager ainsi, avec ce mcanisme, la rcupration dinformations sensibles,
leur modification voire leur destruction.

Considrons un site web dynamique (programm en PHP dans cet exemple) qui dispose
d'un systme permettant aux utilisateurs possdant un nom d'utilisateur et un mot de passe
valides de se connecter. Ce site utilise la requte SQL suivante pour identifier un utilisateur :
SELECT uid FROM Users WHERE name = '(nom)' AND password = '(mot de passe
hash)';

L'utilisateur Dupont souhaite se connecter avec son mot de passe truc hash en MD5. La
requte suivante est excute :
SELECT uid FROM Users WHERE name = 'Dupont' AND password =
'45723a2af3788c4ff17f8d1114760e62';

Attaquer la requte
Imaginons prsent que le script PHP excutant cette requte ne vrifie pas les donnes
entrantes pour garantir sa scurit. Un cracker pourrait alors fournir les informations
suivantes :

Utilisateur : Dupont' --

Mot de passe : n'importe lequel

La requte devient :
SELECT uid FROM Users WHERE name = 'Dupont' -- ' AND password =
'4e383a1918b432a9bb7702f086c56596e';

Les caractres -- marquent le dbut d'un commentaire en SQL. La requte est donc
quivalente :
SELECT uid FROM Users WHERE name = 'Dupont';

L'attaquant peut alors se connecter sous l'utilisateur Dupont avec n'importe quel mot de passe.
Il s'agit d'une injection de SQL russie, car l'attaquant est parvenu injecter les caractres
qu'il voulait pour modifier le comportement de la requte.
Supposons maintenant que l'attaquant veuille non pas tromper le script SQL sur le nom
d'utilisateur, mais sur le mot de passe. Il pourra alors injecter le code suivant :

Utilisateur : Dupont

Mot de passe : ' or 1 --

L'apostrophe indique la fin de la zone de frappe de l'utilisateur, le code or 1 demande au

script si 1 est vrai, or c'est toujours le cas, et -- indique le dbut d'un commentaire.
La requte devient alors :
SELECT uid FROM Users WHERE name = 'Dupont' AND password = '' OR 1 --';

Ainsi, le script programm pour vrifier si ce que l'utilisateur tape est vrai, il verra que 1 est
vrai, et l'attaquant sera connect sous la session Dupont.