expert Cybersecurité

Contexte

Le client recherche un prestataire en cybersécurité capable de réaliser une évaluation offensive complète du système d'information, avec un focus particulier sur son exposition Internet, ses applications, ses APIs et son mécanisme d'authentification avec le SI.

Objectif principal : jusqu'où un attaquant pourrait-il aller, depuis Internet ou avec un compte utilisateur légitime, et quelles données pourrait-il potentiellement récupérer ?

1. Évaluer ce qui est visible depuis Internet (OSINT / test d'exposition)

Sans informations préalables fournies au prestataire. Identifier :

• les domaines et sous-domaines exposés ;
• les certificats et services accessibles ;
• les adresses e-mail visibles publiquement ;
• les éventuelles fuites d'informations ;
• les métadonnées accessibles ;
• les identifiants déjà compromis et connus ;
• les informations publiques qui pourraient aider un attaquant à préparer une attaque.

Le client souhaite savoir quelle image de KOREGE est accessible publiquement et quelles informations sensibles un attaquant pourrait collecter avant même de tenter une intrusion.

2. Tester la sécurité externe en boîte noire

Test d'intrusion externe, sans compte utilisateur et sans accès interne préalable. Rechercher notamment :

• les vulnérabilités de l'OWASP Top 10 2021 ;
• les failles d'authentification ;
• les défauts de configuration ;
• les accès non autorisés ;
• les failles directement exposées sur Internet ;
• l'efficacité des protections contre les attaques répétées ou automatisées.

Objectif : simuler un attaquant externe ne disposant d'aucun compte, pour vérifier si les applications ou services publics peuvent être compromis.

3. Tester les APIs sensibles avec un compte légitime

Les APIs considérées comme sensibles seront identifiées en amont avec les équipes IT. Le prestataire disposera d'un compte utilisateur de type « client ». Vérifier si un utilisateur légitime peut :

• accéder à des données auxquelles il ne devrait pas avoir accès ;
• contourner les contrôles d'autorisation ;
• exploiter les APIs pour accéder à d'autres comptes ou ressources ;
• aspirer ou exfiltrer une quantité importante de données ;
• utiliser les fonctionnalités normales de l'application pour dépasser ses droits.

Le client ne cherche pas uniquement des vulnérabilités techniques classiques : il veut aussi mesurer le risque lié à un compte compromis ou à un utilisateur malveillant, notamment la capacité à extraire massivement des données.

4. Auditer le code source de l'API d'authentification

L'API utilisée par les clients de la banque pour accéder au SI sans devoir se reconnecter. Analyser :

• la robustesse de la logique d'authentification ;
• la gestion des sessions et des tokens ;
• les mécanismes de confiance entre deux entités ;
• les risques de contournement de l'authentification ;
• les risques d'usurpation d'identité ou d'accès indu ;
• la possibilité de rebondir du système d'authentification vers le SI.