Vincent Bodson, Airbus CyberSecurity
Le heros de la lutte contre "wannacry" arrete pour "hacking"
Valentyn Ogirenko
Parler des attaques sur le Web est presque devenue une habitude. "Defacement" (défiguration, en français), fuite de données, attaque par "déni de service" sont des termes qui jalonnent les éditos pour nous expliquer comment des pirates se sont « débrouillés » pour voler ou détruire des données, pour rendre inaccessible un site web ou le défigurer et provoquer des impacts ô combien lourds pour les entreprises et utilisateurs.
Mais que se passe-t-il vraiment, quel est le modus operandi ? Si aujourd'hui, on a tendance à bannir la technicité ou la complexité dans les propos publics pour faire « simple », n'est-il pas nécessaire de comprendre les mécanismes internes d'une attaque pour mieux la contrer ? C'est ce que nous croyons fermement.
Comme en architecture du bâtiment, l'informatique peut connaître des défauts de construction. Telle une fissure dans un mur qui le fragilise, et dont un coup de burin bien placé suffit à le faire tomber, le hacker malveillant n'a qu'à chercher les failles et taper dedans. Dans le Top 10 des failles de sécurité dont on dit qu'elles sont « exploitées » par les attaquants figurent le Cross-Site Scripting (XSS, en abrégé) et "l'injection SQL" (SQLi). Des termes certes un peu barbares, mais qu'il convient de bien retenir en ce qu'ils représentent aujourd'hui la porte d'entrée de plus de la moitié des attaques.
> Qu'est-ce qu'une injection SQL ? Le SQL (Structured Query Language) est un langage permettant de communiquer avec une base de données. Ainsi, lorsqu'un site Web comprend une base de données, le modus operandi de l'attaquant consiste souvent, via un formulaire Web ou couple Login / password à introduire des commandes dans ce langage, dans le but de dialoguer avec la base, de la modifier ou d'en télécharger le contenu.
> Le Cross-Site Scripting permet à un utilisateur légitime, par exemple un utilisateur de blog, d'ajouter une commande de script à la fin d'une entrée de données textuelles. Lorsqu'un autre utilisateur clique dessus, la commande s'exécute avec les autorisations de cet utilisateur. La finalité pour un attaquant peut être de dérober les informations personnelles de l'utilisateur légitime ou de lui envoyer des malwares.
L’actualité qui compte pour vous, chaque jour dans votre boîte mail.
Si ces failles sont connues, pourquoi alors ne pas les contrer ? Ces failles existent en raison du filtrage insuffisant et peu robuste des données attendues par l'application web, lors de la phase de développement (c'est-à-dire l'étape des fondations, pour reprendre notre analogie du début avec le BTP). Ces failles se perpétuent dans le temps, dans la mesure où chaque site Web est conçu sur mesure et continuellement mis à jour.
Il faut dire que, malheureusement, la sécurité est rarement prise en compte dès la conception des applications et que les phases de configuration et de test des sites Web ne sont pas toujours aussi approfondies qu'on le souhaiterait en tant qu'experts de la sécurité. C'est heureusement moins le cas lorsqu'il s'agit d'applications commerciales grand public.
La complexité entre parfois aussi dans l'équation. La faille peut aussi se manifester dans l'application de base de données sous-jacente. Il ne s'agit pas ici de nommer les exemples. Retenons simplement que l'exploitation de ces failles représente une porte d'entrée non verrouillée pour les attaquants.
Pour faire face à ces menaces, il faut prendre en compte la nature du site. S'il s'agit d'un site simple web doté de fonctionnalités minimales, il est possible de s'en remettre à un développeur compétent en développement sécurisé web qui saura comment configurer le serveur de façon sécurisée et pourra entreprendre une évaluation rigoureuse du code. Il se préoccupera en outre des résultats d'un test d'intrusion, ainsi que de la mise en place d'un processus de diffusion des correctifs.
En règle générale, un pare-feu d'application Web est nécessaire pour protéger des sites potentiellement vulnérables au Cross-Site Scripting ou à l'injection SQL, mais les règles devront être mises à jour à intervalles réguliers pour correspondre aux fonctionnalités du site Web.
Pour les sites Web plus complexes qui évoluent continuellement, il n'est sans doute pas envisageable sur le plan pratique d'effectuer des tests rigoureux à chaque nouvelle mise à jour, c'est pourquoi il faudra songer à mettre en place un processus de vérification des failles en continu. Des services d'analyse des vulnérabilités, appelés souvent « scan » sont proposés par différentes entreprises spécialisées et comportent des analyses périodiques de vulnérabilité du site, incluant les zones susceptibles d'être visées par une attaque SQLi et XSS.
Une réflexion doit être menée aussi en phase de déploiement et de maintenance du site. Aujourd'hui, la plupart des entreprises ont recours à une société d'hébergement pour implémenter et gérer leur site Web. Les PME ne disposant pas en interne d'une équipe dédiée à la sécurité peuvent compter sur ce prestataire pour les aider dans l'application des correctifs et la maintenance de leur serveur, mais celui-ci ne couvre pas toujours tout le scope sécuritaire. Il est alors important de vérifier ce que l'offre du prestataire prévoit contractuellement, notamment en termes de contrôle de sécurité, de réduction des attaques DDoS (par "déni de service"), de réactivité aux incidents de sécurité et de processus de gestion des incidents.
Les entreprises qui hébergent elles-mêmes leur site Web, doivent, quant à elles, être extrêmement vigilantes et s'assurer que leurs propres systèmes soient bien protégés et bien séparés du serveur Web ; et ce, pour empêcher l'utilisation du serveur Web comme cheval de Troie dans le but d'attaquer les systèmes informatiques de l'entreprise.
Quelle que soit l'approche adoptée, l'outil de développement nécessite d'être étudié. Par le passé, certains hackers malveillants s'en sont pris à des outils de développement de site Web. Ainsi, chaque site développé ensuite par les entreprises comportait des portes dérobées, ouvertes à tout attaquant ou encore des malwares préinstallés. Ce type d'attaque est complexe à détecter. Néanmoins, l'attitude du fournisseur en matière de sécurité peut être décisive, et les tests de sécurité de la chaîne de développement doivent prendre en compte cette éventualité.
À lire également
Tout ceci démontre l'importance d'intégrer la sécurité dès la phase de développement et pendant tout son cycle de vie en ligne. Cela repose notamment sur des méthodes de travail dites DevSecOps qui portent sur le développement, la sécurité et l'exploitation des systèmes informatiques, sur une évaluation des risques et des menaces, et l'application de règles de codage et d'analyse automatisée du code.
Vincent Bodson, Airbus CyberSecurity
