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, fvrier2000Le 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:alert('bonjour')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 requteImaginons 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 lequelLa 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.