Aide-mémoire : les 10 principaux acronymes de la sécurité des applications
1 décembre 2020
0 minutes de lectureImaginez la situation : vous êtes développeur et assistez à une réunion où un spécialiste de la sécurité présente les résultats d’un test d’intrusion récent ou d’une analyse statique du code que vous avez écrit.
Tout au long de la discussion, cette personne emploie divers acronymes en supposant que vous en connaissez le sens, alors qu’en réalité, ces termes ne vous sont pas familiers. Cela vous dit quelque chose ? Malheureusement, cette situation semble courante dans de nombreuses organisations DevSecOps. En fait, chez Snyk, nous sommes tombés dans le piège en annonçant récemment les fonctionnalités SAST de Snyk. Sur les réseaux sociaux, de nombreuses personnes nous ont fait savoir qu’elles ne savaient pas ce que signifiait SAST. Nous avons donc pensé qu’il serait utile de créer un aide-mémoire des 10 acronymes de sécurité les plus courants. Et rassurez-vous, nous avons inclus SAST : poursuivez votre lecture pour découvrir de quoi il s’agit.
DAST — Dynamic Application Security Testing
SCA — Software Composition Analysis
OWASP — Open Web Application Security Project
XSS — Cross-Site Scripting
CSRF — Cross-Site Request Forgery
RASP — Runtime Application Self-Protection
DoS — Denial of Service
CSP — Content Security Policy
SSRF — Server Side Request Forgery
1. SAST — Static Application Security Testing
Static Application Security Testing, ou SAST, consiste à analyser le code source d’une application, d’un service, d’un microservice, etc., afin de détecter les éventuelles vulnérabilités de sécurité dues à des pratiques de codage 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 code, des fonctions ou des objets non sécurisés susceptibles d’entraîner des vulnérabilités. Il est principalement utilisé pour détecter les vulnérabilités dans le code nouvellement développé. Il est généralement effectué pendant la phase de codage ou au moment où le code est promu dans 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, y compris celles qui pourraient passer inaperçues 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 contrepartie, ils peuvent aussi générer un grand nombre de résultats, souvent des faux positifs ou des vulnérabilités qui, dans le contexte de l’application, ne présentent pas de véritable risque. Avec certains outils, leur réglage et la résolution de ces problèmes peuvent prendre beaucoup de temps. Ces outils restent néanmoins essentiels à votre posture de sécurité.
2. DAST — Dynamic Application Security Testing
Dynamic Application Security Testing, ou DAST, consiste à analyser une application ou un service en cours d’exécution afin d’y détecter des vulnérabilités de sécurité. Le DAST vise à reproduire les types d’attaques qu’un utilisateur malveillant pourrait lancer contre l’application via son interface ou celle du service. Cette approche permet de détecter des vulnérabilités complexes liées à certaines fonctionnalités 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 différents signes de vulnérabilité, en observant la manière dont l’application réagit à diverses requêtes et entrées (souvent appelées charges utiles). Tout est examiné, des champs de saisie aux en-têtes HTTP, afin de vérifier que des mesures adéquates de traitement des données et de sécurité ont été mises en place pour empêcher les attaquants de manipuler l’application ou le service.
Le DAST peut être réalisé à l’aide d’outils automatisés, semi-automatisés ou manuels. Les outils DAST entièrement automatisés sont généralement capables de cartographier les différentes pages d’une application et de les tester à l’aide de diverses variantes de charges utiles, afin de détecter un large éventail de vulnérabilités potentielles. Ils peuvent souvent aussi tester les services web et les microservices. D’autres outils DAST sont plus spécialisés et analysent en profondeur un ou quelques 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 page Learn SAST vs. DAST.
3. SCA — Software Composition Analysis
Software Composition Anlaysis, ou SCA, désigne l’analyse d’une application afin d’identifier les composants logiciels tiers ou open source qu’elle contient. En règle générale, la SCA consiste notamment à analyser ces dépendances externes pour détecter les vulnérabilités de sécurité connues et les éventuels problèmes de licence. Les outils SCA automatisés, comme Snyk OpenSource, sont généralement capables de cartographier l’ensemble de l’arbre des dépendances : ils repèrent les composants inclus dans le code source de l’application, puis analysent également 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 codage, afin de résoudre rapidement les problèmes détectés. La SCA permet notamment de détecter les failles de sécurité potentielles introduites par des composants tiers lors du développement d’une application. Elle permet aussi à l’organisation d’évaluer rapidement son exposition aux nouvelles vulnérabilités annoncées dans les logiciels tiers ou open source et de planifier leur correction.
4. OWASP — Open Web Application Security Project
L’Open Web Application Security Project, ou OWASP, est une organisation à but non lucratif qui se consacre à la sécurité des logiciels. OWASP est connue pour ses nombreux projets communautaires, qui visent à fournir des ressources pédagogiques et des conseils pour créer des logiciels plus sécurisés. OWASP s’appuie sur une vaste communauté de bénévoles qui proposent, développent et gèrent ces projets et ressources 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, mise à jour régulièrement grâce aux contributions de la communauté. Lors d’analyses 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 recense pas toutes les catégories de vulnérabilités possibles, mais constitue un bon point de départ.
OWASP organise également diverses conférences sur la sécurité dans le monde entier et compte des antennes locales qui se réunissent régulièrement pour échanger des idées, travailler sur des projets et partager leurs connaissances. Certains projets organisent aussi des sommets ponctuels, réunissant des professionnels et des membres du projet pour discuter de différents aspects des projets et les affiner.
5. XSS — Cross-Site Scripting
Le Cross-Site Scripting, ou XSS, est un type de vulnérabilité couramment détecté dans les applications web. Il figure dans l’OWASP Top 10 depuis la toute première édition, publiée en 2003. Le XSS est une forme d’attaque contre les applications qui peut permettre à un attaquant d’exécuter du code de script malveillant (le plus souvent en JavaScript) dans le navigateur d’un utilisateur ou de plusieurs utilisateurs. Ce type d’exploitation peut servir à recueillir des informations sensibles, comme des données de session ou des données personnelles.
On distingue généralement trois types de XSS :
Réfléchi : l’attaquant amène 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 de l’attaque à l’application, qui la stocke dans une valeur renvoyée à d’autres utilisateurs dans le cadre de pages générées dynamiquement. Le script s’exécute alors 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 exécuté directement dans le DOM de la page, sans passer par l’application.
Pour en savoir plus sur les attaques XSS et comment les prévenir, consultez la page XSS de Snyk Learn.
6. CSRF — Cross-Site Request Forgery
Le Cross-Site Request Forgery, 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 déclencher certaines fonctionnalités au moyen de requêtes intégrées dans un site malveillant qu’il contrôle. Le CSRF est parfois aussi appelé « session riding », et certaines personnes le prononcent « C-Surf ».
Les attaques par falsification de requête intersites consistent souvent à récupérer une requête valide destinée à l’application cible, puis à la faire rejouer dans le navigateur de la victime alors que celle-ci y dispose d’une session authentifiée active. Par exemple, l’attaquant peut intercepter une requête d’une application bancaire en ligne qui effectue 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 qui visite 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 est envoyée dans le cadre de cette session. Pour attirer des visiteurs sur le site, l’attaquant pourrait lancer une campagne d’hameçonnage ciblée afin d’inciter les clients de la banque (et donc les utilisateurs de son application bancaire) à visiter le site malveillant.
Pour en savoir plus sur le Cross-Site Request Forgery et les moyens de s’en protéger, consultez la page CSRF de Snyk Learn.
7. RASP — Runtime Application Self-Protection
Le Runtime Application Self-Protection, 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 repérer les attaques et de les empêcher. Ils peuvent prendre la forme de packages, de bibliothèques ou de plug-ins qui agissent comme un filtre à l’entrée de l’application pour inspecter les requêtes et le comportement de celle-ci. Le principal avantage du RASP est qu’il empêche un attaquant d’exploiter les vulnérabilités présentes dans l’application — ou, à tout le moins, limite considérablement les conséquences de leur exploitation.
8. DoS — Denial of Service
Le Denial of Service, ou DoS, est un type d’exploitation dans lequel un attaquant cherche à limiter ou à empêcher l’accès à une application ou à un service. Pour ce faire, il rend généralement l’application, le service ou le système inopérant ou extrêmement lent. Il peut également s’en prendre à 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 mener une attaque DoS, mais on distingue souvent deux types particuliers :
DDoS : le Distributed Denial of Service consiste, pour un attaquant, à utiliser un grand nombre de systèmes (généralement réunis au sein d’un botnet) pour submerger une cible de trafic et la rendre indisponible.
REDoS : le Regular Expression Denial of Service est une faille spécifique que l’on trouve couramment dans les applications JavaScript côté serveur. Un attaquant peut amener le moteur d’expressions régulières à consommer d’importantes ressources, rendant ainsi l’application inopérante.
9. CSP — Content Security Policy
La Content Security Policy (CSP) est une mesure de protection des applications web conçue pour empêcher les attaques XSS. Elle permet aux développeurs d’applications d’utiliser un en-tête HTTP pour 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 soient exécutés une fois parvenus au navigateur.
Retrouvez d’autres ressources et informations sur la CSP dans notre blog.
10. SSRF — Server Side Request Forgery
Le Server Side Request Forgery (SSRF) est une forme d’attaque contre une application qui permet à un attaquant de contraindre l’application front-end à envoyer des requêtes vers des destinations arbitraires (par exemple, d’autres serveurs internes ou externes, voire elle-même). L’attaquant peut ainsi accéder à des données ou à des fonctionnalités auxquelles il n’est pas autorisé à accéder.
Pour en savoir plus sur les attaques SSRF, nous vous recommandons ce guide de l’OWASP.
En résumé
Comme dans tous les secteurs, la sécurité emploie de nombreux termes techniques, souvent abrégés en sigles 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 utilisés par leurs interlocuteurs en sécurité est un atout précieux pour renforcer la collaboration dans le pipeline de livraison DevSecOps.
Téléchargez dès maintenant la fiche récapitulative des 10 principaux sigles de la sécurité des applications !