Test d'applications web
Securite des applications web contre les abus et vulnerabilites
Frontend et API, testés conjointement
Une application web moderne se compose de deux éléments : l'interface que vos utilisateurs voient et la couche API qui se cache derrière. Tester uniquement l'un des deux vous donne une fausse impression de couverture.
Chaque test d'application web CREDS couvre ces deux aspects. Nous testons l'interface utilisateur afin de détecter les failles qui apparaissent via le navigateur, et nous testons directement la couche API, y compris les points de terminaison que l'interface utilisateur n'appelle jamais, la logique d'autorisation qui n'est appliquée qu'en côté serveur, ainsi que les fonctionnalités accessibles sans passer par l'interface.
Dans la pratique, c'est au niveau du API que se trouvent généralement les failles les plus graves. Les failles d'autorisation au niveau des objets, l'absence de contrôle d'accès sur les terminaux individuels et les logiques métier susceptibles d'être exécutées hors séquence ne sont pas visibles depuis l'interface utilisateur et ne sont pas détectées par un scan.
Interface utilisateur
L'authentification et la gestion des sessions, le traitement des données saisies, la logique côté client, le contrôle d'accès tel qu'il est mis en œuvre dans l'interface, ainsi que les failles qui affectent le navigateur de l'utilisateur.
API
Autorisation au niveau des points de terminaison, contrôle d'accès au niveau des objets, utilisation abusive de la logique métier, requêtes en chaîne et points de terminaison non exposés via l'interface.
Comment nous procédons aux tests
Un test d'intrusion est une opération dont la durée est limitée. La véritable question n'est donc pas de savoir « ce qui peut être testé », mais « comment optimiser le temps dont on dispose ». Notre approche est entièrement conçue pour répondre à cette question.
L'automatisation effectue le travail préparatoire
Nous mettons en œuvre un haut degré d'automatisation dans l'ensemble de l'application avant et pendant le test : cartographie de la surface d'attaque, recensement des terminaux et préparation du terrain, autant de tâches qui ne nécessitent pas d'intervention humaine. Ce n'est pas cela, le test. C’est ce qui libère nos testeurs des tâches répétitives, leur permettant ainsi de consacrer leur temps aux aspects que l’automatisation ne peut pas couvrir : la logique métier, les vulnérabilités en chaîne, les failles d’autorisation et l’exploitation abusive des fonctionnalités réelles de l’application.
Révision du code source, dans la mesure du possible
Nous préférons intégrer la révision automatisée du code source dans notre mission. L'accès au code nous apporte deux avantages : d'une part, une vision plus claire de l'origine réelle des faiblesses, et non pas seulement de l'endroit où elles apparaissent ; d'autre part, un test nettement plus efficace, car nous ne perdons pas de temps à essayer de deviner le fonctionnement de l'application.
Avec l'analyse du code source, nous plongeons dans le code pour identifier les vulnerabilites potentielles.
Des tests manuels là où cela compte vraiment
L'automatisation détecte les schémas connus. Elle ne détecte pas les failles qui n'existent qu'en raison de la manière dont votre application gère un processus métier particulier. Ce travail est manuel ; il est effectué par un testeur qui comprend la finalité de votre application, et c'est à cela que la majeure partie des heures consacrées à la mission est consacrée.
Trois niveaux d'évaluation
Nous classons nos tests par niveaux, en fonction du degré de maturité de votre application et de votre organisation. Le niveau qui vous convient dépend de la fréquence des modifications apportées à l'application, de son importance stratégique et du nombre de tests déjà effectués.
- 01
Test d'intrusion de référence
Le test incontournable, adapté à toutes les applications web. Axé sur l'identification des vulnérabilités courantes au niveau du front-end et de API, il est réalisé conformément aux normes reconnues. C'est le point de départ idéal pour un premier test, une application récemment mise en service ou une vérification régulière.
Typical duration: 1 semaine
- 02
Test d'intrusion avancé
Il va plus loin en ciblant des problèmes complexes qu’un test de référence ne permet pas de mettre en évidence : chaînes d’attaques complexes, exploitation abusive de la logique métier, failles d’autorisation subtiles et vulnérabilités qui n’apparaissent que lorsque plusieurs faiblesses mineures sont combinées. Il convient aux applications traitant des données sensibles, ou lorsque le résultat d’un test de référence précédent s’est révélé relativement satisfaisant.
Typical duration: 2 semaines
- 03
Test d'intrusion basé sur des scénarios
Des scénarios personnalisés, conçus en fonction de votre environnement opérationnel et de votre paysage de menaces, qui simulent les attaques qu’un pirate spécifique et réaliste tenterait réellement de mener contre votre application. Cette approche est indiquée lorsque vous souhaitez répondre à une question précise plutôt que d’obtenir une couverture globale.
Typical duration: 2 à 3 semaines
Vous ne savez pas quel niveau vous convient ? C'est la première chose que nous déterminons ensemble lors de la définition du périmètre, et nous ne manquerons pas de vous le signaler si un test plus simple s'avère être la solution la plus adaptée.
Testé conformément à des normes reconnues
Les tests ne sont utiles que si leur profondeur et leur étendue sont vérifiables. Nous travaillons selon des normes internationales afin que la couverture de vos tests soit comparable, reproductible et défendable face à un auditeur, plutôt que de dépendre du testeur qui vous a été attribué.
OWASP ASVS. La norme de vérification de la sécurité des applications, notre cadre de référence principal pour définir le niveau d'exhaustivité d'un test d'application web.
OWASP : Top 10. L'ensemble de référence des risques liés à la sécurité des applications.
Guide de test de sécurité Web OWASP. La méthodologie suivie par nos testeurs.
Fiche pratique sur la sécurité des services Web OWASP. Appliqué aux essais API, le cas échéant.
Directives du NCSC en matière de sécurité informatique. Pour les applications Web et pour le protocole TLS (Transport Layer Security).
BIO. « Baseline Informatiebeveiliging Overheid », destiné aux activités de l'administration publique.
Normes Logius. Pour les évaluations DigiD.
Certifications et affiliations
Rien ne part sans avoir été vérifié par une deuxième paire d'yeux
Chaque test d'intrusion CREDS fait l'objet d'une révision par des pairs avant de vous être transmis, conformément à notre principe du « double contrôle », et ce selon deux axes.
Analyse technique
Un deuxième testeur examine les résultats eux-mêmes : la vulnérabilité est-elle réelle, son impact a-t-il été correctement évalué, la procédure de reproduction est-elle exacte et aucun élément relevant du périmètre d'analyse n'a-t-il été omis ?
Révision du contenu
Une vérification distincte du rapport en tant que document : chaque constat est-il expliqué de manière suffisamment claire pour permettre de prendre des mesures, la notation du risque est-elle justifiable, les recommandations de correction sont-elles spécifiques plutôt que génériques, et le rapport sera-t-il compréhensible pour le développeur chargé de corriger le problème et pour le responsable chargé d'approuver le travail ?
Cela ne concerne pas uniquement les projets de grande envergure. Cela s'applique à tous les tests, à tous les niveaux.
Audits DigiD, avec un auditeur faisant déjà partie de notre équipe
Les organisations soumises à une évaluation DigiD ont généralement besoin de deux prestataires : d'une part, un prestataire chargé de réaliser le test d'intrusion, et d'autre part, un auditeur informatique agréé chargé de produire le rapport d'audit. Cela implique deux contrats, deux calendriers et un transfert de responsabilité entre ces deux prestataires.
CREDS dispose en interne d'auditeurs informatiques agréés (RE) spécialisés. Notre auditeur RE accompagne le test d'intrusion, travaille en étroite collaboration avec les testeurs tout au long de la mission et rédige le chapitre supplémentaire qui servira de base à votre audit DigiD, dans le cadre de cette même mission.
Nous intégrons des cadres de contrôle tels que DigiD au test lui-même, de sorte que celui-ci soit dès le départ adapté aux exigences, plutôt que d'y être aligné a posteriori. Il en résulte un seul fournisseur, un seul calendrier et un rapport d'audit rédigé par une personne ayant assisté au déroulement du test.
Convient à la norme DigiD, ainsi qu'aux organisations travaillant selon la norme BIO.
Vous n'attendez pas dans le noir
Un test d'intrusion ne doit pas se résumer à une « boîte noire » qui produit un rapport trois semaines plus tard. Voici ce qui se passe pendant le déroulement des opérations.
Notifications quotidiennes de début et de fin
Vous êtes informé du début et de la fin des activités de test chaque jour, ce qui permet à votre équipe de toujours savoir si le trafic vers l'application provient de nous ou d'un tiers.
Les résultats présentant un risque élevé sont communiqués immédiatement
Si nous constatons un problème grave, vous en serez informé dès qu'il sera confirmé, et non pas dans le rapport. Une vulnérabilité critique n'est pas un sujet qu'il convient de garder pour la réunion de clôture.
Résultats visibles en temps réel
Les constatations apparaissent sur le portail client dès qu'elles sont signalées ; vos développeurs peuvent ainsi commencer à travailler avant même la fin de la mission, sans avoir à attendre la réception d'un document.
Nous réorientons le test avec vous
Un test d'intrusion est soumis à une contrainte de temps, ce qui signifie qu'il est toujours possible de choisir où consacrer les heures restantes. Au cours du test, nous réfléchissons avec votre équipe aux prochains axes à explorer, en nous appuyant sur ce que nous avons découvert jusqu'à présent et sur ce que vous savez de l'application. Une découverte dans un domaine rend souvent un autre domaine plus intéressant que ne le prévoyait le plan initial.
Ce que vous recevez
Un projet de rapport, qui fait l'objet de discussions avant d'être finalisé. Nous vous présentons en détail les conclusions et les niveaux de risque tant qu'il est encore possible de corriger un malentendu concernant votre environnement. Aucun client ne devrait découvrir un rapport finalisé pour la première fois.
Le rapport complet. Chaque constat, son impact, une méthode de reproduction et des conseils de remédiation spécifiques.
Un résumé du projet destiné à vos parties prenantes. Un résumé distinct et clair, destiné aux personnes qui doivent comprendre les résultats et valider le travail, et non à celles qui s'occupent de le réaliser.
Une feuille de route pour la remise en état, le cas échéant. Si les conclusions justifient l'élaboration d'un plan plutôt que d'une liste de tâches, nous l'élaborerons avec vous.
Accès continu aux résultats. Vos résultats restent accessibles sur le portail client, y compris les demandes de nouveau test.
Vos résultats, regroupés en un seul endroit
Chaque mission liée à une application web CREDS donne accès au portail client. C'est là que le test cesse d'être un simple document pour devenir un outil avec lequel votre équipe peut travailler.
Résultats en direct
Les résultats sont publiés sur le portail au fur et à mesure qu'ils sont identifiés au cours du test, accompagnés d'une analyse d'impact et de recommandations de correction.
Demandes de nouveau test
Lorsqu'un correctif est déployé, demandez directement depuis le portail qu'un nouveau test soit effectué sur le problème initial, afin que la vérification soit enregistrée dans le dossier correspondant plutôt que d'être suivie dans un tableur.
Intégration du système de tickets
Les résultats sont intégrés aux outils que vos développeurs utilisent déjà, notamment Jira et ServiceNow, de sorte que la correction s'inscrit dans votre processus de sprint existant plutôt que dans un processus parallèle.
Historique des missions
Les tests précédents et leurs résultats restent accessibles, ce qui vous permet de constater les changements intervenus d'un test à l'autre.
Les nouveaux tests sont inclus dans la prestation. Vérifier qu'une correction a bien fonctionné ne vous coûte rien de plus.
Security that moves with your release schedule
Nous croyons que le test d'applications web est un voyage collaboratif.
Nous preconisons des tests periodiques alignes sur vos sprints de developpement.
Because findings flow into your ticket system and retests are requested from the portal, recurring testing fits your existing sprint process rather than sitting alongside it.
Questions concernant les tests d'applications web
Testez-vous le API ainsi que le front-end ?
De quel niveau d'examen avez-vous besoin ?
Avez-vous besoin d'accéder à notre code source ?
S'agit-il d'un test automatisé ?
Utilisez-vous la plateforme ART pour tester des applications web ?
Comment peut-on savoir si le test a été exhaustif ?
Que se passe-t-il une fois que nous aurons corrigé ces anomalies ?
Les résultats peuvent-ils être transmis directement à nos développeurs ?
Combien de temps dure un examen ?
Pourriez-vous nous aider à réaliser notre évaluation DigiD ?
Allons-nous avoir connaissance de conclusions graves avant la publication du rapport ?
Êtes-vous prêt à tester votre application ?
Dites-nous en quoi consiste l'application et à quelle fréquence elle évolue, et nous vous indiquerons quel niveau de test convient le mieux, ainsi que les ressources nécessaires.