Une application Web ou une application Web est une application qui s’exécute sur un système distant et est diffusée sur Internet via un navigateur.
Les principaux composants d’une application Web sont le code d’application, le serveur, la base de données, le transport, le navigateur, la logique de présentation et les utilisateurs. Pour sécuriser complètement les applications Web et protéger les données du système et des clients, vous devez comprendre le risque de sécurité à chaque couche et concevoir une stratégie pour renforcer complètement chaque couche.
La plupart des développeurs pensent implémenter une sécurité cadre ou l’authentification et l’autorisation dans une application sont suffisantes pour assurer la sécurité de l’application ; il s’agit d’une vue trop simpliste des exigences de sécurité des applications (AppSec). Il existe plusieurs vecteurs supplémentaires nécessaires à la sécurisation des applications Web. Disséquons chaque couche et voyons quels risques de sécurité elles exposent.
Couches d’application
Le numéro un dans la liste est votre application elle-même ; c’est la couche la plus critique. Il comporte plusieurs éléments clés qui jouent un rôle essentiel.
Cadre de sécurité
Un cadre de sécurité remplit deux fonctions essentielles.
- Empêcher les demandes non authentifiées d’accéder à des fonctionnalités sécurisées telles que les pages Web et les données d’entreprise.
- Empêcher les demandes authentifiées d’accéder à des fonctionnalités non autorisées telles que des pages Web et des données commerciales non autorisées.
Ces défis semblent simples, mais ils sont connus pour causer de nombreux problèmes d’application. En conséquence à la Top 10 des API OWASP, l’authentification cassée est classée numéro deux des failles fréquemment exploitées. Le problème d’autorisation n’est rien d’autre qu’une escalade de privilèges causée par la mise en œuvre et le mappage incorrects des rôles, des étendues et de l’autorisation aux ressources appropriées telles que les pages Web, les services internes, etc. Ces failles bien connues ont eu un impact négatif sur de nombreuses grandes organisations, y compris des mastodontes comme Microsoft, dans la violation de Microsoft Office 365, par exemple.
Logique métier
Les contraintes de sécurité sont très répandues dans le code de logique métier. Il est difficile de séparer la sécurité du code, et de nombreux développeurs ne réalisent même pas à quelle fréquence ils incluent la sécurité dans leur code fonctionnel. Par exemple, pensez à Dropbox fonctionnalité de partage de fichiers. Il vous permet de partager des fichiers de plusieurs façons, y compris avec vos amis, collègues, groupes, groupe public, groupe modifiable, public Internet, etc. Comme vous pouvez le constater, la plupart de ces fonctionnalités ne sont que des contraintes de sécurité très probablement réparties sur la base de code. . Pour vous assurer que votre application ne divulgue pas de données commerciales à des utilisateurs non autorisés, vous devrez tester chaque fonction en tenant compte de la sécurité.
Logique d’accès à la base de données
Les failles d’application les plus importantes au cours des deux dernières décennies provenaient de SQL, NoSQL, de commandes et de problèmes d’injection similaires. Il existe quelques bonnes pratiques que vous devez suivre lors de l’intégration de bases de données et de systèmes similaires.
Tout d’abord, utilisez les informations d’identification de la base de données avec les privilèges de base qui prennent en charge vos besoins d’accès aux données ; évitez les informations d’identification qui peuvent faire plus comme supprimer des tables, des collections, des bases de données, etc.
Les bases de données sont des systèmes robustes et riches en fonctionnalités. Ils vous permettent d’exécuter des opérations de programmation complexes, y compris des requêtes dynamiques qui peuvent lire, modifier et supprimer toutes les données sans vérifications d’autorisation appropriées. Vous devez utiliser les meilleures pratiques standard telles que les instructions préparées lors de l’écriture de code sur des bases de données.
Serveur d’application
Les serveurs d’applications comme Weblogic, Tomcat, IIS, etc., ont joué un rôle essentiel dans le passé. Ils prenaient en charge des fonctionnalités critiques telles que les déploiements à chaud, la haute disponibilité (HA), les sessions de mappage, l’équilibrage de charge, etc. Ces systèmes étaient également des cibles de choix pour les attaques ; la plupart des exploits recherchaient des systèmes mal configurés ou des systèmes qui ne modifiaient pas les informations d’identification par défaut. Avec la large adoption de conteneurs, sans serveur et Kubernetes, les développeurs abandonnent l’utilisation de serveurs d’applications pour les nouvelles charges de travail cloud natives. La meilleure pratique consiste à utiliser Kubernetes ou une architecture sans serveur pour déployer vos applications.
Infrastructure de serveur
La plupart des applications s’exécutent dans des machines virtuelles, sur des serveurs bare metal sur site ou dans le cloud. Ces systèmes sont constamment attaqués par des acteurs malveillants qui tentent d’exploiter des ports mal configurés, des packages vulnérables, SSH, etc. La meilleure pratique consiste à configurer correctement les groupes de sécurité et à restreindre l’accès aux ports et aux services à des adresses IP administratives limitées.
Le transport
L’exécution d’applications Web non SSL était une pratique souvent utilisée et acceptable dans le passé. Mais cela a permis des attaques de l’homme du milieu et d’autres vecteurs. Plus récemment, cependant, ce vecteur d’attaque s’est considérablement renforcé car la plupart des navigateurs ne restituent même plus les sites SSL non SSL ou mal configurés, obligeant les développeurs à configurer SSL correctement.
Navigateur/Logique de présentation
Cette couche contient du code HTML, CSS et JavaScript. L’attaque de script intersite (XSS) est un exploit courant que les pirates déploient généralement contre cette couche. La meilleure pratique pour se prémunir contre cet exploit consiste à vérifier chaque entrée utilisateur pour le code JavaScript et à rejeter ces demandes. Sinon, vous risquez de propager accidentellement le code d’exploitation à tous les autres utilisateurs non suspects, d’exécuter le code malveillant et de voler les données de l’utilisateur.
Utilisateurs
La force brute, les mots de passe volés et les cookies/sessions volés sont des exploits courants de prise de contrôle de compte. La meilleure pratique pour contrer ces exploits consiste à mettre en œuvre des techniques de reconnaissance IP, des appareils et des navigateurs, y compris l’authentification multifacteur (MFA).
Résumé de la sécurité des applications
La sécurité des applications Web est complexe et nécessite une approche en couches pour traiter toutes les vulnérabilités potentielles.
● Tester la mise en œuvre correcte des fonctions d’authentification et d’autorisation à chaque changement de code.
● Tester la bonne implémentation de RBAC et OAuth2.0.
● Les failles de la logique métier sont complexes ; chaque changement de code et l’introduction de nouvelles données peuvent introduire un bogue de sécurité. Une stratégie de test complète est nécessaire pour éviter les violations de données.
● Tester l’application par rapport aux catégories d’injection à l’aide de tests dynamiques de sécurité des applications (DAST) et d’outils similaires.
● Modernisez vos serveurs d’applications, utilisez les frameworks d’orchestration de conteneurs comme Kubernetes et suivez ses meilleures pratiques pour assurer la sécurité.
● Une configuration correcte des groupes de sécurité est nécessaire pour restreindre l’accès aux ports et SSH au personnel administratif.
● Suivez les meilleures pratiques SSL standard.
● Effectuez un rejet des mauvaises entrées (pas seulement une désinfection) pour éviter les XSS et d’autres problèmes.
● Implémentez la MFA, l’appareil, l’adresse IP et la reconnaissance du navigateur pour éviter les problèmes de prise de contrôle de compte utilisateur.
