Développé en 2012 et rendu open source en 2015 par Facebook, GraphQL (Graph Query Language) est depuis 2019 sous la tutelle de “GraphQL Foundation”.
GraphQL est un langage de requêtes, c’est à dire un langage utilisé pour accéder aux données d’une base de données ou tout autre système d’information, au même titre que le SQL (Structured Query Language).
L’authentification et, par extension, l’identification d’un utilisateur sont des éléments centraux des applications web.
En effet, de ces deux mécanismes découlent la gestion des droits et des accès (par exemple entre un administrateur et un utilisateur standard), le cloisonnement des données entre différents comptes, la possibilité d’identifier différents utilisateurs, etc.
Lors d’un test d’intrusion, on considère généralement 3 conditions de tests : boite noire, grise ou blanche.
Ces conditions de tests correspondent à des niveaux d’informations fournis aux pentesters pour réaliser un pentest sur une cible spécifique. Alors qu’un pentest white box consistera à fournir un maximum d’informations, lors d’un pentest black box les pentesters disposeront d’aucune donnée sur la cible des tests.
Lors d’un pentest d’application web, d’API ou de réseau interne, on distingue généralement 3 approches : des tests en boite noire, en boite grise ou en boite blanche.
Ces approches ou conditions de tests correspondent à différents niveaux d’informations fournis aux pentesters pour identifier des vulnérabilités et des faiblesses potentielles pouvant compromettre l’intégrité d’un système cible. Alors qu’un pentest black box consistera à fournir aucune donnée spécifique, lors d’un pentest white box, les pentesters disposeront d’un maximum d’informations.
Avec l’augmentation du risque cyber, il devient de plus en plus évident de réaliser un pentest (test d’intrusion) pour rassurer clients, partenaires et investisseurs.
De plus, pour les entreprises engagées dans un processus de certification ou une démarche ISO 27001, SOC2, HDS, PCI-DSS, etc., un pentest est un impératif. Et pour les autres, une condition sine qua non pour satisfaire les demandes de rapport de pentest de leurs clients et prospects.
Vous connaissez certainement le phishing qui consiste à envoyer des emails malveillants pour inciter les destinataires à réaliser des actions sensibles, comme renseigner leurs identifiants de connexion VPN sur une fausse page d’authentification par exemple.
Le smishing est quasiment identique, à ceci près que l’attaquant n’envoie non pas des emails, mais des SMS, d’où le nom de smishing. Essentiellement, le smishing est ni plus ni moins que du phishing par SMS.
Les APIs sont des cibles de choix pour les attaquants en raison de leur exposition et de leur caractère « critique », notamment en termes de manipulation de données sensibles. De fait, pour minimiser le risque de failles de sécurité, il est impératif de mettre en œuvre des mesures de sécurité robustes, de comprendre les types d’attaques et d’évaluer leur impact potentiel.
Il existe plusieurs moyens d’évaluer la sécurité d’une API. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion d’API (ou pentest API). Nous y détaillons les principes et objectifs ainsi que des use cases de pentest en boite noire, grise et blanche.
Les applications mobiles sont de plus en plus utilisées dans tous les domaines d’activités : RH, finance, assurances, transports, etc. De fait, elles constituent des cibles de choix pour les attaquants.
Il existe plusieurs moyens d’évaluer la sécurité d’une application mobile. Dans cet article, nous vous présentons l’approche « offensive » qui reste, selon nous, la plus efficace : les tests d’intrusion mobile (ou pentest mobile). Nous y détaillons les principes, objectifs ainsi que la méthodologie et les éléments testés lors de tests d’intrusion d’application mobile.
La mauvaise configuration de sécurité est un problème préoccupant puisqu’il occupe la cinquième place du Top 10 de l’OWASP. En effet, nous rencontrons assez fréquemment de nombreuses vulnérabilités de ce type lors de nos tests d’intrusion d’application web. Par ailleurs, cette problématique sécurité toucherait un grand nombre d’applications web (90% selon l’OWASP).
Dans cet article, nous vous présentons ce type de failles à travers le prisme de l’OWASP Top 10, et ce via des scénarios d’attaques. Nous y détaillons également les bonnes pratiques et les mesures à mettre en œuvre pour s’en prémunir.
Les composants tiers sont omniprésents dans les applications web. En effet, librairies, frameworks et autres composants système sont de plus en plus utilisés car ils permettent de réduire les coûts et de faciliter les développements.
Cependant, comme tout système, ces composants tiers peuvent contenir des vulnérabilités exploitables lors d’attaques sur des applications web. De plus, les exploits découverts, et souvent rendus public, peuvent avoir un effet boule de neige et ainsi compromettre l’intégralité d’une application web, les serveurs, les systèmes de base de données, etc.