API ou bibliothèque non sécurisées

Catégorie OWASP : MASVS-CODE : qualité du code

Présentation

L'utilisation d'API ou de bibliothèques non sécurisées réduit considérablement la stratégie de sécurité d'une application. Une brèche de sécurité dans l'une de ces dépendances permettrait à un pirate informatique d'exploiter un certain nombre de vecteurs pour mener de nombreuses attaques, comme celle l'homme du milieu (MitM) et l'exécution de code à distance (RCE).

La menace de l'implémentation de dépendances non sécurisées survient lorsque les développeurs n'intègrent pas les évaluations de sécurité et les tests de failles dans le cycle de vie du développement logiciel (SDLC, Software Development Lifecycle) ou, dans certains cas, lorsqu'ils n'implémentent pas de règle de mise à jour automatisée pour les dépendances d'applications.

L'exploitation des dépendances commence généralement par l'analyse du binaire de l'application (.apk) pour rechercher les bibliothèques vulnérables. À ce stade, l'Open Source Intelligence (OSINT) est utilisé pour identifier les failles précédemment découvertes et potentiellement exploitables. Les pirates informatiques peuvent ensuite exploiter des informations publiquement divulguées, telles que les vulnérabilités et les expositions communes (CVE, Common Vulnerabilities and Exposures) pour effectuer d'autres attaques.

Impact

La réussite de l'exploitation des dépendances non sécurisées peut entraîner un large éventail d'attaques, comme l'exécution de code à distance (RCE), les injections SQL (SQLi) ou les scripts intersites (XSS). L'impact global est donc directement lié au type de faille introduit par les logiciels tiers et que les pirates informatiques peuvent exploiter. Les conséquences potentielles d'une exploitation réussie des dépendances vulnérables sont les violations de données ou l'indisponibilité des services, ce qui peut avoir un impact significatif sur la réputation et le chiffre d'affaires.

Stratégies d'atténuation

Défense en profondeur

Notez que les stratégies d'atténuation mentionnées ci-dessous doivent être mises en œuvre conjointement pour renforcer la stratégie de sécurité et réduire la surface d'attaque de l'application. L'approche exacte doit toujours être évaluée au cas par cas.

Évaluations des failles de dépendance

Implémentez la vérification des dépendances au début du cycle de développement pour détecter les failles dans le code tiers. Cette phase consiste à vérifier si le code qui n'est pas compilé en interne est sécurisé avant d'être déployé dans les environnements de production. La validation peut être complétée par la mise en œuvre de tests de sécurité des applications statiques (SAST) et d'outils de test de sécurité des applications dynamiques (DAST) dans le cycle de vie du développement logiciel afin d'améliorer la stratégie de sécurité de l'application.

Mettre à jour les dépendances en continu

Veillez à mettre à jour les dépendances intégrées au code en permanence. Pour ce faire, il est recommandé d'implémenter les mises à jour automatiques qui sont mises en production chaque fois qu'un composant tiers publie un nouveau correctif de sécurité.

Effectuer des tests d'intrusion sur l'application

Effectuez régulièrement des tests d'intrusion. Ces types de tests visent à détecter toute faille connue pouvant affecter le code propriétaire et/ou les dépendances tierces. En outre, les évaluations de sécurité révèlent souvent des failles inconnues (vulnérabilités 0-day). Les tests d'intrusion sont utiles aux développeurs, car ils leur fournissent un instantané de la stratégie de sécurité actuelle de l'application et les aident à hiérarchiser les problèmes de sécurité exploitables à résoudre.

Ressources