Top 10 des acronymes de la sécurité des applications
Explication des acronymes courants de l’AppSec
Écrit par
0 minutes de lecture
Aide-mémoire
Les 10 principaux acronymes de la sécurité des applications expliqués
Imaginez la situation suivante : vous êtes développeur et participez à une réunion où un spécialiste de la sécurité présente les résultats d’un récent test d’intrusion ou d’une analyse statique du code que vous avez écrit.
Tout au long de la discussion, cette personne utilise différents acronymes de sécurité des applications, en supposant que vous en connaissez la signification, alors qu’en réalité, ces termes ne vous sont pas familiers. Cette situation vous semble-t-elle familière ? Malheureusement, elle est fréquente dans de nombreuses organisations DevSecOps. En fait, chez Snyk, nous sommes tombés dans ce piège lors de notre récente annonce des capacités SAST de Snyk. Sur les réseaux sociaux, de nombreuses personnes nous ont dit ne pas savoir ce que signifiait SAST. Nous avons donc pensé qu’il serait utile de réunir dans un aide-mémoire les 10 acronymes de sécurité les plus courants. Et rassurez-vous, SAST en fait partie : poursuivez votre lecture pour en savoir plus.
1. SAST — tests statiques de sécurité des applications
Les tests statiques de sécurité des applications, ou SAST, consistent à analyser le code source d’une application, d’un service, d’un microservice, etc. afin de repérer les vulnérabilités potentielles dues à des pratiques de programmation non sécurisées. Le SAST repose le plus souvent sur des outils automatisés qui recherchent dans le code source des modèles de programmation, des fonctions ou des objets non sécurisés susceptibles d’entraîner des vulnérabilités. Il sert principalement à détecter les vulnérabilités dans le code nouvellement développé. Il est généralement effectué pendant la phase de programmation ou au moment où le code est promu vers un environnement de test.
L’un des principaux avantages du SAST est qu’il permet de détecter les vulnérabilités tôt dans le processus de développement et de repérer des problèmes cachés qui pourraient passer inaperçus si l’on se contentait d’examiner les fonctionnalités de l’application. Les outils SAST automatisés peuvent analyser rapidement de grandes quantités de code. En revanche, ils peuvent aussi générer un grand nombre de résultats, qui comprennent souvent des faux positifs ou des vulnérabilités qui ne présentent pas réellement de risque dans le contexte de l’application. Avec certains outils, il peut falloir beaucoup de temps pour les régler et éliminer ces problèmes. Malgré cela, ces outils jouent un rôle essentiel dans votre posture de sécurité.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis Capture The Flag en regardant à la demande notre atelier virtuel d’initiation.
2. DAST — tests dynamiques de sécurité des applications
Les tests dynamiques de sécurité des applications, ou DAST, consistent à analyser une application ou un service en cours d’exécution afin d’y détecter des vulnérabilités. Le DAST vise à simuler les types d’attaques qu’un utilisateur malveillant pourrait lancer contre l’application par le biais de son interface utilisateur ou de son interface applicative. Cette approche permet de détecter des vulnérabilités complexes dues à des fonctionnalités spécifiques de l’application, qui pourraient passer inaperçues lors d’une simple analyse du code source.
Avec le DAST, l’interface est examinée à la recherche de divers signes de vulnérabilités, en observant la manière dont l’application répond à différentes requêtes et entrées (souvent appelées charges utiles). Des champs de saisie utilisateur aux en-têtes HTTP, tout est analysé afin de déterminer si une gestion correcte des données et des mesures de sécurité ont été mises en œuvre pour empêcher les attaquants de manipuler l’application ou le service.
Des outils automatisés, semi-automatisés et manuels peuvent être utilisés pour réaliser des tests DAST. Les outils DAST entièrement automatisés peuvent généralement cartographier les différentes pages d’une application et les tester à la recherche d’un large éventail de vulnérabilités potentielles, à l’aide de variantes de charges utiles. Ils sont souvent également capables de tester les services Web et les microservices. D’autres outils DAST sont plus spécialisés et permettent d’analyser plus en profondeur un ou plusieurs types de vulnérabilités spécifiques. Le DAST est généralement effectué lors des dernières phases de test, juste avant le déploiement d’une application ou d’un service en production.
Pour en savoir plus sur la différence entre SAST et DAST, consultez notre article SAST ou DAST.
3. SCA — analyse de la composition logicielle
L’analyse de la composition logicielle, ou SCA, consiste à analyser une application afin d’identifier les composants logiciels tiers ou open source qu’elle comprend. En général, la SCA comprend l’analyse de ces dépendances externes pour repérer les vulnérabilités connues et les éventuels problèmes de licence. Les outils SCA automatisés, comme Snyk Open Source, peuvent généralement cartographier l’ensemble de l’arbre des dépendances : ils recensent non seulement les composants inclus dans le code source de l’application, mais analysent aussi les dépendances de chacun de ces composants, et ainsi de suite.
L’analyse de la composition logicielle peut être effectuée à n’importe quelle étape du pipeline de livraison, mais il est généralement préférable de la réaliser tôt, souvent pendant la phase de programmation, afin de pouvoir corriger rapidement les problèmes détectés. La SCA sert notamment à repérer les failles de sécurité potentielles introduites par des composants tiers lors du développement d’une application, mais aussi à permettre à l’organisation d’évaluer rapidement si elle est concernée par de nouvelles vulnérabilités annoncées dans des logiciels tiers ou open source, puis de planifier leur correction.
Découvrez-en plus sur SAST et SCA et sur la manière de les exploiter pour publier des logiciels sécurisés.
Lancez-vous dans les compétitions Capture The Flag
Apprenez à résoudre des défis de capture du drapeau en regardant à la demande notre atelier virtuel d’initiation.
4. OWASP — projet pour la sécurité des applications Web ouvertes
L’Open Web Application Security Project, ou OWASP, est une organisation à but non lucratif qui se consacre à la sécurité logicielle. OWASP est connu pour ses nombreux projets communautaires visant à fournir des ressources pédagogiques et des conseils sur la création de logiciels plus sécurisés. OWASP fédère une vaste communauté de bénévoles qui proposent, développent et gèrent ces projets et contenus pédagogiques au bénéfice de l’ensemble des communautés de la sécurité et du développement logiciel.
L’un de ses projets les plus connus est l’OWASP Top 10, une liste des dix types de vulnérabilités les plus courants dans les applications Web, régulièrement mise à jour à partir des contributions de la communauté. Lors de tests SAST ou DAST, vous entendrez peut-être parler de l’OWASP Top 10 comme référence pour les types de vulnérabilités recherchés par les testeurs. Cette liste ne répertorie pas toutes les vulnérabilités possibles, mais constitue un bon point de départ.
OWASP organise également différentes conférences sur la sécurité dans le monde entier et dispose de sections locales qui se réunissent régulièrement pour échanger des idées, travailler sur des projets et partager leurs connaissances. Il arrive aussi que des projets organisent des sommets afin de réunir des professionnels et des membres des projets pour discuter de certains aspects et les améliorer.
5. XSS — scripts intersites
Les scripts intersites, ou XSS, constituent un type de vulnérabilité couramment détecté dans les applications Web. Ils figurent dans l’OWASP Top 10 depuis sa toute première édition, publiée en 2003. Une attaque XSS permet à un attaquant d’exécuter du code de script malveillant (le plus souvent du JavaScript) dans le navigateur d’un utilisateur ou de plusieurs utilisateurs. Ce type d’exploitation peut servir à recueillir des informations sensibles, notamment des données de session ou des données personnelles.
On distingue généralement trois types de XSS :
Réfléchi : l’attaquant incite l’utilisateur à envoyer à l’application une requête contenant la charge utile de l’attaque. L’application l’inclut dans sa réponse, ce qui entraîne son exécution dans le navigateur.
Stocké : l’attaquant envoie la charge utile malveillante à l’application, qui l’enregistre dans une valeur ensuite renvoyée à d’autres utilisateurs dans des pages générées dynamiquement, entraînant l’exécution du script dans leur navigateur.
Basé sur le DOM : l’attaquant envoie le script malveillant à l’utilisateur (généralement dans un lien malveillant). Celui-ci est alors exécuté directement dans le DOM de la page, sans passer par l’application.
Pour en savoir plus sur les XSS et découvrir comment les prévenir, consultez notre page XSS sur Snyk Learn.
6. CSRF — falsification de requêtes intersites
La falsification de requêtes intersites, ou CSRF, est une autre forme courante d’attaque contre les applications Web. Lors d’une attaque CSRF, l’attaquant exploite une session déjà authentifiée entre le navigateur de l’utilisateur et l’application pour en exécuter les fonctionnalités à l’aide de requêtes intégrées à un site malveillant qu’il contrôle. La CSRF est parfois aussi appelée « chevauchement de session » (session riding), et certaines personnes la prononcent « C-Surf ».
La falsification de requêtes intersites exploite souvent une requête valide envoyée à l’application cible et la fait rejouer dans le navigateur de la victime alors qu’une session authentifiée avec cette application est active. Par exemple, l’attaquant peut intercepter une requête provenant d’une application bancaire en ligne et permettant d’effectuer un virement. Il crée ensuite un site malveillant et y intègre cette même requête dans une IFRAME, afin que toute personne visitant le site l’envoie à l’application bancaire. Ainsi, si le visiteur dispose d’une session active avec cette application bancaire (peut-être dans un autre onglet du navigateur), la requête sera envoyée dans le cadre de cette session. Pour attirer des visiteurs sur le site, l’attaquant utilisera probablement une campagne d’hameçonnage ciblée, afin d’inciter les clients potentiels de la banque — et donc les utilisateurs probables de son application bancaire — à visiter le site malveillant.
Pour en savoir plus sur la falsification de requêtes intersites et découvrir comment la prévenir, consultez notre page CSRF sur Snyk Learn.
7. RASP — autoprotection des applications à l’exécution
L’autoprotection des applications à l’exécution, ou RASP, est une technique de défense intégrée à une application qui lui permet de détecter les attaques et d’y réagir immédiatement. Le RASP est le plus souvent mis en œuvre à l’aide d’outils tiers. Ceux-ci s’intègrent généralement à l’application et surveillent non seulement les requêtes entrantes, mais aussi le comportement de l’application afin de détecter et de prévenir les attaques. Ils peuvent se présenter sous forme de packages, de bibliothèques ou de plug-ins qui agissent comme un filtre à l’entrée de l’application et permettent d’inspecter les requêtes et le comportement de l’application. Le principal avantage du RASP est que même si l’application comporte des vulnérabilités, un attaquant ne peut pas les exploiter avec succès — ou, à tout le moins, l’ampleur de l’exploitation peut être considérablement limitée.
8. DoS — déni de service
Le déni de service, ou DoS, est un type d’attaque par lequel un attaquant cherche à limiter ou à empêcher la disponibilité d’une application ou d’un service. Pour cela, il rend généralement l’application, le service ou le système inactif ou extrêmement lent. L’attaque peut aussi viser l’infrastructure réseau qui assure les communications avec l’application. Une attaque DoS se produit lorsqu’un attaquant exploite une faille dans le code, le logiciel système ou l’infrastructure réseau d’une application pour la rendre indisponible. Il existe de nombreuses façons de lancer une attaque DoS, mais deux types spécifiques sont souvent évoqués :
DDoS : le déni de service distribué consiste pour un attaquant à utiliser un grand nombre de systèmes (généralement regroupés au sein d’un botnet) pour submerger une cible de trafic et la rendre indisponible.
REDoS : Le déni de service par expression régulière est une faille spécifique fréquemment présente dans les applications JavaScript côté serveur. Un attaquant peut exploiter cette faille pour pousser le moteur d’expressions régulières à consommer d’importantes ressources et rendre l’application non réactive.
9. CSP — Politique de sécurité du contenu
La politique de sécurité du contenu, ou CSP, est une contre-mesure destinée aux applications web pour prévenir les attaques XSS. Elle permet aux développeurs d’applications d’utiliser un en-tête HTTP afin d’indiquer au navigateur de ne charger et d’exécuter des scripts qu’à partir de sources spécifiques. En empêchant le chargement de scripts depuis des sources non prévues, les développeurs peuvent éviter que les scripts injectés lors d’une attaque XSS ne s’exécutent une fois arrivés dans le navigateur.
Découvrez d’autres ressources et informations sur la CSP dans notre blog.
10. SSRF — Falsification de requête côté serveur
La falsification de requête côté serveur, ou SSRF, est une forme d’attaque contre les applications qui permet à un attaquant de faire envoyer par l’application front-end des requêtes vers des destinations arbitraires (par exemple, d’autres serveurs internes ou externes, voire l’application elle-même). Cela peut lui donner accès à des données ou à des fonctionnalités auxquelles il n’est pas autorisé à accéder.
Pour en savoir plus sur les SSRF, nous vous recommandons ce guide de OWASP.
En résumé
Comme dans tout secteur, la sécurité comporte de nombreux termes techniques, souvent abrégés en acronymes pour faciliter les échanges. Cela peut dérouter les personnes qui ne travaillent pas dans la sécurité. Pour les développeurs, savoir décrypter les termes employés par leurs partenaires sécurité peut grandement contribuer à renforcer la collaboration dans le pipeline de livraison DevSecOps.