Bug ou fonctionnalité ? Vulnérabilités cachées des applications Web découvertes

La sécurité des applications Web comprend une myriade de contrôles de sécurité qui garantissent qu’une application Web :

1. Fonctionne comme prévu.
2. Ne peut pas être exploité pour opérer hors des limites.
3. Impossible de lancer des opérations qu’il n’est pas censé faire.

Les applications Web sont devenues omniprésentes après l’expansion du Web 2.0, les plateformes de médias sociaux, les sites de commerce électronique et les clients de messagerie saturant les espaces Internet ces dernières années.

À mesure que les applications consomment et stockent des données encore plus sensibles et plus complètes, elles deviennent une cible de plus en plus attrayante pour les attaquants.

Méthodes d’attaque courantes

Les trois vulnérabilités les plus courantes qui existent dans cet espace sont les injections (SQL, code distant), les échecs cryptographiques (exposition de données auparavant sensibles) et le contrôle d’accès brisé (BAC). Aujourd’hui, nous nous concentrerons sur les injections et le contrôle d’accès cassé.

Injections

SQL est le logiciel de base de données le plus couramment utilisé et héberge une multitude de données de paiement, de données PII et de dossiers commerciaux internes.

Une injection SQL est une attaque qui utilise du code SQL malveillant pour manipuler la base de données principale afin d’accéder à des informations qui n’étaient pas destinées à être affichées.

Le point de départ pour cela est une commande telle que celle ci-dessous :

Cela renverra TOUTES les lignes de la table « Utilisateurs », puisque OR 1=1 est toujours VRAI. Pour aller plus loin, cette méthode renverra également les mots de passe s’il y en a.

Imaginez une attaque comme celle-ci menée contre une grande entreprise de médias sociaux ou une grande entreprise de commerce électronique, et vous pourrez commencer à voir combien de données sensibles peuvent être récupérées avec une seule commande.

Contrôle d’accès cassé

Le contrôle d’accès brisé (BAC) a grimpé dans le top dix de l’OWASP, passant du cinquième au rang des risques de sécurité des applications Web les plus courants. Les 34 énumérations de faiblesses communes (CWE) mappées au contrôle d’accès brisé ont eu plus d’occurrences dans les applications que toute autre catégorie lors des tests récents de l’OWASP.

Les types de BAC les plus courants sont l’élévation de privilèges verticale et horizontale. L’élévation verticale des privilèges se produit lorsqu’un utilisateur peut élever leurs privilèges et effectuer des actions, ils ne devraient pas y avoir accès.

Le CVE-2019-0211, qui était une élévation de privilèges locaux Apache. Cette vulnérabilité critique, datant de 2019, affectait les serveurs HTTP Apache exécutés sur les systèmes Unix, en particulier ceux utilisant les bibliothèques mod_prefork, mod_worker et mod_event.

Cela a donné aux attaquants la possibilité d’exécuter des scripts non privilégiés, conduisant potentiellement à un accès root et compromettant les services d’hébergement partagé. L’exploitation de cette faille nécessite la manipulation des régions de mémoire partagée au sein des processus de travail d’Apache, ce qui doit être effectué avant de lancer un redémarrage progressif d’Apache.

Ce qui suit est une capture d’écran du code POC. Comme on peut le constater, un certain niveau de compétence technique est requis à cet égard. Cependant, une élévation verticale des privilèges peut tout aussi bien se produire lorsque les autorisations d’un utilisateur sont trop permissives ou ne sont pas révoquées lorsqu’il quitte l’entreprise.

Cela nous ramène au principe du moindre privilège, un terme omniprésent dans le monde informatique, qui devient de plus en plus courant à mesure que nous réalisons à quel point les applications Web sont devenues cruciales.

L’élévation horizontale des privilèges se produit lorsqu’un utilisateur obtient l’accès à des données auxquelles il n’est pas censé avoir accès, mais ces données sont conservées au même niveau que ses propres autorisations. Cela peut être constaté lorsqu’un utilisateur standard accède aux données d’un autre utilisateur standard. Même si cela ne devrait pas être autorisé, les privilèges ne s’élèvent pas verticalement, mais s’étendent horizontalement. Ceci est parfois considéré comme plus dangereux, car cela peut se produire sans déclencher d’alerte sur les systèmes de sécurité.

Alors que le BAC est devenu de plus en plus présent ces dernières années, il est important de se rappeler :

• Se fier uniquement à l’obscurcissement n’est pas une méthode suffisante pour le contrôle d’accès.
• Si une ressource n’est pas censée être accessible au public, son accès devrait lui être refusé par défaut.
• Les développeurs doivent spécifier explicitement l’accès autorisé pour chaque ressource au niveau du code, avec le refus d’accès comme paramètre par défaut.

Meilleures pratiques – Lire entre les lignes (du code !)

Pour maintenir la sécurité, les développeurs doivent vérifier les données entrantes, mettre en œuvre des requêtes paramétrées lors de l’interaction avec les bases de données et appliquer des méthodes de gestion de session efficaces pour protéger les données sensibles. Une grande partie de cela repose à la fois sur la sécurité des navigateurs Web, mais également sur la sécurité back-end des serveurs Web fournissant le contenu Web, ce qui conduit à une séparation des tâches en matière de sécurité Web.

Le plus gros problème qui se pose ici est que, même si les pare-feu d’applications Web (WAF) peuvent atténuer ces risques, une grande partie de la responsabilité de la mise en œuvre sécurisée du contenu Web incombe aux développeurs qui créent ces sites. La cybersécurité peut souvent devenir une réflexion secondaire, la fonctionnalité étant privilégiée.

Exemple pratique – Validation des entrées

La validation d’entrée est le moyen le plus simple et le plus efficace d’implémenter un codage sécurisé, dans cet exemple pour empêcher les injections SQL.

1. Entrée utilisateur : l’utilisateur fournit une entrée, par exemple :

2. Nettoyage : l’entrée utilisateur n’est pas directement insérée dans la requête SQL. Il est nettoyé et traité comme des données, et non comme du code SQL.
3. Exécution de la requête : la requête SQL est exécutée avec l’entrée de l’utilisateur comme paramètre :
4. En tant que telle, la requête entre dans le backend comme ci-dessous :

Dans ce code, le (user_input,) est un tuple contenant l’entrée de l’utilisateur. Le pilote de base de données se charge d’échapper et de gérer correctement cette entrée. Il garantit que l’entrée est traitée comme une valeur de données et non comme du code SQL exécutable.

Si l’entrée utilisateur contient du code malveillant, tel que « 105 ou 1=1 », il n’est pas exécuté en tant que SQL. Au lieu de cela, il est traité comme une valeur à comparer au UserId dans la base de données.

Le pilote de base de données gère automatiquement l’échappement de l’entrée, l’empêchant d’affecter la structure de la requête SQL ou d’introduire des failles de sécurité.

Pare-feu d’applications Web (WAF)

Un WAF fonctionne au niveau de la couche 7 du modèle OSI et agit comme un proxy inverse, garantissant que le trafic client passe par le WAF avant d’entrer dans le serveur backend. Les règles ou politiques du WAF protègent contre les vulnérabilités documentées présentes dans ces serveurs backend et filtrent le trafic malveillant.

Il existe une pléthore de WAF sur le marché, et ceux-ci peuvent tous fournir une défense solide contre les attaques les plus récentes et contribuer bien à une approche de défense en profondeur. La pratique du codage sécurisé est quelque chose qui garantit que les fondations de l’application Web sont solides. sécurisé et ne sera pas victime d’attaques plus complexes ou nouvelles à l’avenir.

Les WAF évoluent actuellement vers un mélange de modèles de sécurité qui utilisent des technologies d’analyse comportementale pour détecter les menaces malveillantes et atténuer davantage les menaces des « robots » plus avancés qui ont été exploités pour des attaques à faible effort sur les sites Web.

Le principal inconvénient de l’utilisation d’un WAF, outre la latence supplémentaire et la surcharge HTTP, est le fait qu’un WAF peut être contourné en utilisant un exploit de 0 jour contre une application Web, qu’un codage sécurisé et une désinfection correcte peuvent atténuer plus efficacement. en compensant toute la sécurité des applications Web vers un WAF. Il est important de se rappeler qu’un WAF n’est qu’une couche de sécurité et non la solution complète.

Réponse aux incidents et récupération

QG de sécurité suggestions pour atténuer les attaques :

1. L’utilisation d’un WAF comme première ligne de défense est essentielle pour garantir que les entreprises peuvent se défendre contre un grand nombre d’attaques.
2. Assurez-vous que des algorithmes et des protocoles standards à jour et solides sont utilisés, cela doit être associé à une gestion appropriée des clés.
3. Chiffrez les données en transit avec des protocoles sécurisés tels que TLS avec des chiffrements Forward Secrecy (FS), et une priorisation des chiffrements par le serveur. Appliquez le chiffrement à l’aide de directives telles que HTTP Strict Transport Security (HSTS).
4. Activez des stratégies de gestion des robots sur les sites Web et disposez d’un plan de réponse aux incidents documenté.
5. Assurez-vous que des pratiques de développement sécurisées sont en place, avec un processus documenté de test des nouvelles fonctionnalités sur les applications Web et assurez-vous que la validation des entrées est déployée.

• Cela devrait s’accompagner du respect du principe du moindre privilège.

Pour plus d’informations sur ces menaces, parlez à un expert ici. Ou si vous soupçonnez un incident de sécurité, vous pouvez signaler un incident ici.

Remarque : Cet article a été rédigé de manière experte par Tim Chambers, responsable principal de la cybersécurité chez SecurityHQ.