REDPIXEL - stock.adobe.com
Cinq étapes pour les tests de sécurité des applications Web
Cette approche en cinq étapes, avec des tests aux résultats documentés, aide à maintenir la sécurité des applications Web à un niveau satisfaisant.
De nombreux composants sont impliqués dans les tests de sécurité des applications Web. Mais malgré cette complexité, les tests n'ont pas besoin d'être extrêmement difficiles. L’important est de savoir ce que l’on veut, ce qui est nécessaire pour l’obtenir, puis d'adopter une approche pragmatique pour concentrer ses efforts sur les applications les plus importantes.
Alors, comment procéder pour vérifier son environnement applicatif afin de s’assurer de l’absence de failles de sécurité importantes dans ses applications critiques ? C'est faisable même dans les environnements les plus complexes.
Les informations suivantes décrivent le quoi, le quand, le pourquoi et le comment de la plupart des scénarios de test de sécurité des applications Web, y compris pour déterminer les systèmes à tester, les outils les mieux adaptés, l'utilisation de scanners de vulnérabilités, la validation de leurs résultats, et les vérifications manuelles supplémentaires.
Que tester ?
La portée de l’évaluation de sécurité est extrêmement importante. Elle peut dépendre de besoins internes ou d’exigences d’un partenaire commercial ou d’un client.
Il doit être clair de savoir quelles applications, systèmes réseau et code sont à tester, comment les tests doivent être conduits, et quelles sont les attentes spécifiques pour les livrables. Ceci inclut les attentes relatives aux rôles utilisateurs à mettre à l’épreuve. Il est toujours préférable de réaliser les tests comme un utilisateur standard, mais également comme un utilisateur externe malveillant, ou encore comme un utilisateur aux privilèges élevés.
Quels sont les outils les mieux adaptés ?
Au minimum, le test de sécurité des applications Web nécessite l'utilisation d'un analyseur de vulnérabilité, tel que Netsparker ou Acunetix Web Vulnerability Scanner. Pour les tests authentifiés, un proxy HTTP tel que Burp Suite permet d'essayer de manipuler les connexions des utilisateurs, la gestion des sessions, les workflows des applications, etc.
D'autres outils sont disponibles si l'analyse du code source est une exigence, mais attention, on obtient ce pour quoi l’on paie avec les outils d'analyse du code source et, malheureusement, la plupart sont coûteux. Cette analyse n’est pas forcément des plus utiles, mais si elle constitue une exigence, il est difficile de s’y soustraire.
Analyse de vulnérabilités
Lorsque de la recherche de vulnérabilités, il convient de s’assurer que les scanners testent les points les plus critiques, comme l'injection SQL, les scripting intersites (XSS) et l'inclusion de fichiers. L'exécution des tests sur la base du top 10 de l'Owasp constitue souvent un bon début. Mais il se peut qu’il soit nécessaire de définir une stratégie de tests personnalisée en fonction de la plateforme applicative et de ses besoins spécifiques.
L'analyse des vulnérabilités se concentre principalement sur la couche 7, mais le code source, les configurations cloud et des hôtes réseau peuvent nécessiter d’être couverts. Au minimum, les tests automatisés devraient rechercher les erreurs de configuration SSL/TLS, ainsi que les vulnérabilités au niveau du serveur Web et du serveur d'application.
Les scanners dédiés aux vulnérabilités Web devraient trouver la plupart des failles, mais il peut être nécessaire de recourir à des outils de recherche de vulnérabilités plus étendus tels que ceux de Tenable ou de Qualys, voire de Cloud Conformity.
Validation des tests et vérifications manuelles supplémentaires
Il n’est pas possible de lister exhaustivement tous les contrôles à effectuer, tant les vecteurs d’attaque peuvent être nombreux et diversifiés. La première chose à faire consiste à valider les résultats du scanner de vulnérabilités Web pour voir ce qui est exploitable et ce qui compte dans le contexte de son application et de son entreprise. Mais au-delà, d'autres domaines peuvent mériter un examen :
- le mécanisme de connexion et les manipulations de session impliquant des mots de passe, des cookies et des jetons ;
- l’impact de failles liées à l'utilisateur ou au navigateur Web ;
- les faiblesses de la logique applicative qui permettent la manipulation manuelle du déroulement des opérations et des champs de saisie spécifiques ;
- et la politique de gestion des mots de passe, qu’il s’agisse de leur complexité ou de la gestion des compromissions.
C'est sans doute l'aspect le plus difficile et le plus long des tests de sécurité des applications. Le but principal devrait être d'examiner l’application avec une mentalité malveillante et de voir ce qu'un attaquant peut faire à l'application en utilisant un vieux navigateur web et un proxy http.
Documenter et diffuser ses conclusions
Malheureusement, beaucoup de tests de sécurité des applications s'arrêtent à l'étape précédente. Mais la documentation des résultats est essentielle. Elle permet non seulement de créer une trace écrite et de faire preuve de la diligence requise, mais aussi d'aider les autres parties concernées – équipes de développement, personnel de DevSecOps, direction générale, etc. – à s’impliquer. L'un des moyens les plus rapides de perdre la responsabilité des initiatives de sécurité des applications – et de se faire pirater – est de tout garder pour soi et de garder les autres dans l'ignorance.
Chaque environnement est différent et chaque entreprise a ses besoins propres. Mais une approche raisonnable des tests de sécurité des applications Web comprendra probablement certains des éléments ci-dessus, sinon tous. Il y a trop d'enjeux et trop de choses que les attaquants peuvent exploiter pour simplement exécuter des analyses de base sans évaluation formelle des risques ni documentation des résultats.
