Nouvelle catégorie de risque dans le Top 10 de l'OWASP : Prévoir l'imprévu

Avec la publication du Top 10 2025 de l'OWASP, les entreprises doivent prêter une attention particulière à de nouvelles catégories de risques, dont une toute nouvelle qui prouve, une fois pour toutes, que ce que vous ignorez peut effectivement vous nuire.

La nouvelle catégorie, Mauvaise gestion des conditions exceptionnelles, souligne les risques encourus lorsque les organisations ne sont pas préparées à prévenir, détecter et répondre à des situations inhabituelles ou imprévisibles. Selon l'OWASP, cette vulnérabilité survient lorsqu'une application ne parvient pas à empêcher un événement inhabituel, à identifier un problème lorsqu'il survient, et/ou réagit mal, voire pas du tout, face à une situation inattendue.

L'idée que les entreprises doivent être prêtes à l'imprévu reflète la réalité des systèmes hautement distribués et interconnectés d'aujourd'hui. L'OWASP ne parle pas de problèmes inconnus : la mauvaise gestion des circonstances exceptionnelles englobe 24 Common Weakness Enumerations (CWE). Il s'agit simplement de faiblesses (gestion incorrecte des erreurs, échec d'ouverture d'événements, erreurs logiques, etc.) pouvant survenir dans des conditions anormales. Cela peut résulter, par exemple, d'une validation inadéquate des entrées, d'erreurs de haut niveau dans les fonctions de traitement ou d'une gestion incohérente (voire inexistante) des exceptions. Comme l'indique l'OWASP : « Chaque fois qu'une application n'est pas sûre de son instruction suivante, une condition exceptionnelle a été mal gérée. »

Ces circonstances exceptionnelles peuvent plonger les systèmes dans un état imprévisible, entraînant des plantages, des comportements inattendus et des vulnérabilités de sécurité persistantes. La clé pour prévenir ce type de perturbation est, essentiellement, de s'attendre au pire et de se préparer à toute éventualité.

[REGARDER LA VIDÉO]

Circonstances exceptionnelles et évolution du Top 10

La composition du classement quadriennal des risques les plus graves pour la sécurité des applications web est restée assez stable au fil des ans, avec quelques changements de position et une ou deux nouveautés tous les quatre ans. L'édition 2025 comporte deux nouvelles entrées, dont la « Mauvaise gestion des conditions exceptionnelles » en 10e position. L'autre, Défaillances de la chaîne d'approvisionnement logicielle, qui occupe la 3e place, est une extension d'une catégorie précédente, Composants vulnérables et obsolètes (6e en 2021), qui inclut désormais un large éventail de compromissions logicielles. (Pour rappel, le Contrôle d'accès défaillant reste le risque numéro 1).

Les conditions exceptionnelles constituant cette nouvelle catégorie peuvent engendrer une multitude de vulnérabilités, allant des bugs logiques aux dépassements de mémoire, en passant par les transactions frauduleuses et les problèmes de timing, d'authentification ou d'autorisation. Ces vulnérabilités peuvent affecter la confidentialité, la disponibilité et l'intégrité d'un système ou de ses données. Elles permettent à un attaquant de manipuler la gestion défaillante des erreurs d'une application pour exploiter la vulnérabilité, précise l'OWASP.

Un exemple de mauvaise gestion des conditions inattendues survient lorsqu'une application identifie des exceptions lors du téléchargement de fichiers pendant une attaque par déni de service, mais omet de libérer les ressources par la suite. Les ressources restent alors verrouillées ou indisponibles, provoquant un épuisement des ressources. Si un attaquant s'immisce dans une transaction financière en plusieurs étapes, un système qui ne revient pas en arrière après la détection d'une erreur pourrait permettre à l'attaquant de vider le compte de l'utilisateur. Si une erreur est détectée en cours de transaction, il est crucial d'appliquer le « fail closed » : annuler toute la transaction et recommencer. Tenter de récupérer une transaction en cours peut entraîner des erreurs irréparables.

Fail Closed vs. Fail Open

Quelle est la différence entre ces deux approches ? Clarifions les choses :

Fail Open : Si un système est en mode « fail open », il continue de fonctionner ou reste « ouvert » en cas de problème. C'est utile lorsque la continuité de service est primordiale, mais cela peut présenter des risques pour la sécurité.

Fail Closed : Si un système est en mode « fail closed », il s'arrête automatiquement ou se verrouille lorsqu'un problème survient. C'est une approche plus sûre, car elle permet de prévenir les accès non autorisés.

Gestion des erreurs imprévues

La prévention de ce type de risque commence par la planification face à l'inconnu. Cela implique d'être capable de détecter toute erreur système potentielle dès qu'elle survient et de prendre les mesures nécessaires pour résoudre le problème. Vous devez être en mesure d'informer correctement l'utilisateur (sans révéler d'informations critiques à un attaquant), de journaliser l'événement et, si nécessaire, d'émettre une alerte.

Voici un exemple de divulgation d'une erreur de requête SQL, accompagnée du chemin d'installation du site, qui pourrait être utilisée pour identifier un point d'injection :

Warning: odbc_fetch_array() expects parameter /1 to be resource, boolean given in D:\app\index_new.php on line 188

Un système idéal devrait disposer d'un gestionnaire d'exceptions global pour intercepter les erreurs oubliées, ainsi que d'outils de surveillance ou d'observabilité, ou d'une fonctionnalité détectant les erreurs répétées pouvant signaler une attaque en cours. Cela aide à se protéger contre les attaques visant à exploiter les faiblesses de l'entreprise dans la gestion des erreurs.

Pour une application web Java standard, par exemple, un gestionnaire d'erreurs global peut être configuré au niveau du descripteur de déploiement web.xml — dans ce cas, une configuration utilisée depuis la spécification Servlet version 2.5 et ultérieure.

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 

ns="http://java.sun.com/xml/ns/javaee"

xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
‍
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"

‍‍version="3.0">
...
  <error-page>
     <exception-type>java.lang.Exception</exception-type>
     <location>/error.jsp</location>
</error-page>
...
</web-app>
‍

Ce petit bloc de code indique à une application web Java comment réagir en cas d'anomalie en arrière-plan. Au lieu d'afficher un message d'erreur confus ou un écran vide, il intercepte discrètement le problème et redirige l'utilisateur vers une page d'erreur personnalisée, ici error.jsp.

Comme il est configuré pour gérer les types java.lang.Exception généraux, il agit comme un gestionnaire d'erreurs maître pour toute l'application. Ainsi, quel que soit l'endroit où survient une erreur, les utilisateurs sont redirigés vers la même page conviviale au lieu de voir des détails techniques bruts.

Prévenir l'imprévu

Idéalement, les organisations doivent s'efforcer d'empêcher, autant que possible, l'apparition de conditions exceptionnelles. La mise en œuvre de limitation de débit, de quotas de ressources et d'autres restrictions peut aider à contrer les attaques par déni de service ou par force brute. Identifiez les erreurs répétées pour les traiter statistiquement afin de ne pas saturer vos journaux. Un système devrait également inclure :

Une validation stricte des entrées, pour garantir que seules des données correctement formées et assainies entrent dans le flux de travail. Cela doit se faire tôt, idéalement dès la réception des données.

Des bonnes pratiques de gestion des erreurs, pour intercepter les erreurs là où elles surviennent. Elles doivent être traitées efficacement : informez clairement les utilisateurs, tenez un journal et envoyez des alertes si nécessaire. Un gestionnaire d'erreurs global est idéal pour capturer les oublis.

La sécurité transactionnelle générale, qui est indispensable. Appliquez toujours le principe de « fermeture en cas d'échec » : en cas de problème, annulez toute la transaction. Ne tentez jamais de corriger une transaction partiellement, cela pourrait aggraver la situation.

La journalisation, la surveillance et l'alerte centralisées, couplées à un gestionnaire d'exceptions global, permettent une investigation rapide des incidents et un traitement uniforme des événements, tout en facilitant la conformité.

La modélisation des menaces et/ou la revue de conception sécurisée, effectuées lors de la phase de conception des projets.

La revue de code ou l'analyse statique, ainsi que les tests de résistance, de performance et d'intrusion effectués sur le système final.

La mauvaise gestion des conditions exceptionnelles est peut-être une nouvelle catégorie, mais elle repose sur des principes fondamentaux de cybersécurité. Elle souligne la nécessité pour les entreprises de se préparer à l'imprévu. Vous ne savez peut-être pas quelle forme prendront ces conditions, mais vous savez qu'elles surviendront. L'essentiel est d'être prêt à les traiter de manière cohérente pour mieux les détecter et y répondre.

Note aux utilisateurs de SCW Trust Score™ :

Alors que nous mettons à jour le contenu de notre plateforme d'apprentissage pour l'aligner sur la norme OWASP Top 10 2025, vous pourriez constater des ajustements mineurs du Trust Score de vos développeurs Full Stack. Veuillez contacter votre responsable Customer Success pour toute question ou assistance.