Johanne Ulloa

Un article fort intéréssant paru dans « Capital » du mois d’aout fait état de vulnérabilités de plusieurs site Web.  Dans un premier temps nous verrons quelles vulnérabilités ont été exploitées et nous préciserons comment se prémunir de ces vulnérabilités.

Quelles sont les vulnérabilités exploitées ?

3 types de vulnérabilités ont été exploités :
1) lié à des défaillances techniques (SQL injection, Cross Site Scripting),
2) lié à des défaillances organisationnelles (possibilité d’accéder aux pages
d’administration des sites Web)
3) lié à des défaillances dans la logique applicative.

Comment se prémunir de ces vulnérabilités ?

Dans  le  premier  cas  (Injection  SQL, Cross  Site  Scripting ….). Comme  ces  attaques  font  appel  à  des  langages  informatiques  (SQL,  JavaScript),  elles  sont  assez  facilement reconnaissables et elles peuvent être bloquées grâce à un firewall applicatif Web (WAF). Il est  toutefois  recommandé  d’utiliser  un  WAF  qui  est  capable  d’avoir  une  approche pondérée (comme la Scoring List de Deny All) pour reconnaitre ces attaques. En effet, les WAF qui utilisent de simples « black list » ne sont pas assez efficaces contre ces attaques ou bien, bloquent trop fréquemment le trafic légitime (ce qui est inacceptable).

Dans le deuxième cas, il a été possible d’accéder à l’interface d’administration, car celle-ci n’était pas suffisamment sécurisée. Là encore, un WAF aurait été  fort utile, car  il permet d’augmenter le niveau d’authentification. Il est par exemple possible de faire en sorte que les  administrateurs  ne  puissent  accéder  à  l’interface  d’administration  qu’après  une
authentification forte (Certificat client, RSA SecureID, Vasco, Active Card…)  ce qui permet d’être protégé des attaques qui consistent à deviner un mot de passe en faisant des essais
répétés et automatiques.

Dans  le  troisième  cas,  les vulnérabilités exploitées étaient  liées à des problématiques de logique applicative. Ici, les mécanismes de défense traditionnels sont souvent inefficaces.
En effet, L’exploitation de  la vulnérabilité ne passe pas par un vecteur d’attaque comme une  injection  de  code  (qui  est  identifiable), mais  par  exemple  par  la manipulation  d’un
paramètre dans une URL. Il est toutefois possible d’en limiter les risques grâce au modèle de sécurité positive du WAF  (White List :  tout ce qui n’est pas expressément prévu sera
rejeté).

L’article fait état du temps de réaction des différentes entités. Comment réagir rapidement quand une vulnérabilité a été détectée ?

Certains WAF permettent de mettre en œuvre un patch virtuel sans que l’on ait à modifier l’application WEB. Ceci permet de traiter la vulnérabilité qui a été détectée immédiatement
en  laissant  du  temps  aux  équipes  de  développement  pour  corriger  le  problème  en profondeur sans devoir interrompre le service.

Moralité de l’histoire ?

Dans  le meilleur des mondes, ces vulnérabilités n’auraient pas pu être exploitées, car  les aspects de sécurité auraient été pris en compte de façon importante dès la conception de
l’application WEB et tout au long de son cycle de vie (développement, exploitation). Il est toutefois difficile de prendre en  charge  ces aspects de  sécurité en amont : on demande aux développeurs de concentrer leurs efforts sur les fonctionnalités et non sur la sécurité. De plus, il arrive très fréquemment que l’on n’ait aucun contrôle sur le développement de l’application  Web.  C’est  pour  ces  raisons  et  parce  que  les  attaques  Web  sont  très attractives  pour  les  hackeurs  (simplicité  de mise  en œuvre  et  retour  sur  investissement très  fort)  qu’un  WAF  est  un  élément  devenu  maintenant  indispensable  dans  les infrastructures Web.