HIP – Beyond OWASP Top 10 (Aaron Hnatiw)

Azmi Sbai Conférences

L’OWASP est une communauté en ligne travaillant sur la sécurité des applications Web. Son objectif principal est de produire des documents et des standards dédiés à la sécurité de ses applications. Parmi les projets les plus reconnus on trouve le Top 10 qui référence les 10 vulnérabilités les plus répandues sur le web. La plupart des tests d’intrusion web se basent sur ce Top 10 qui établit un classement de risque pour chaque vulnérabilité (en prenant compte les aspects détection, exploitation et impact). Les vulnérabilités identifiées sur le classement de 2013 sont les suivantes:

  •  A1 – L’injection
  • A2 – Broken Authentication and Session Management
  • A3 – Cross-Site Scripting (XSS)
  • A4 – Insecure Direct Object References (IDOR)
  • A5 – Security Misconfiguration
  • A6 – Sensitive Data Exposure
  • A7 – Missing Function Level Access Control
  • A8 – Cross-Site Request Forgery (CSRF)
  • A9 – Using Components with Know Vulneabilites
  • A10 – Unvalidated Redirects and Forwards.

Cette conférence était axée sur trois vulnérabilités trouvées régulièrement dans les audits de sécurité des applications Web et qui ne sont pas décrites dans le Top 10 de l’OWASP: Race Conditions, HTTP Parameter Pollution (HPP) et Server Side Request Forgery (SSRF).

1 – Race Conditions (CWE-362):

Race Condition est un scénario qui se produit lorsqu’un dispositif ou un système tente d’effectuer deux opérations ou plus en même temps pour accéder à une ressource partagée (comme une variable ou un code) et le modifient en raison d’une exécution indéterminée du processus dans l’algorithme de planification des processus. Un exemple d’exploitation de cette vulnérabilité a été découvert par un chercheur en 2015 sur les cartes cadeaux de Starbuck’s.

Comment tester:

Pour tester si un code ou une application Web est vulnérable à la Race Conditions si l’auditeur a accès au code source (boite blanche) il faut:

  • identifier toutes les données partagées en particulier celles sur le système
  • trouvez l’emplacement où cet accès aux données n’est pas synchronisé
  • faire beaucoup de requêtes simultanées pour tester.

Dans le cas contraire (boite noire), l’auditeur peut utiliser des outils automatisés comme Race The Web (RTW) qui permet de découvrir les Race Conditions dans les applications Web en envoyant un grand nombre de requêtes à un point final spécifique en même temps. Cependant, il peut engendrer des comportements involontaires sur le serveur, comme la duplication des informations de l’utilisateur, les bitcoins, les bons de réduction …

Attention: Par la nature de ses tests l’outil génère un grand nombre de requête, ce qui implique un risque de déni de service. Il est donc important d’avoir l’accord en amont du client.

Contre-mesure & recommandations:

Beaucoup de développeurs utilisent des manières détournées comme la limitation du nombre de demandes par IP compte ou action. Les moyens appropriés de le faire sont les suivants:

  • utiliser un verrouillage LOCKS sur les ressources partagées (pour la clause UPDATE)
  • utiliser des tokens CSRF qui permettent de rendre plus difficile une attaque automatisée
  • utiliser une fast database qui permet de répondre à deux requêtes simultanées.

2 – HTTP Parameter Pollution (HPP) CWE-235:

HTTP Parameter Pollution (HPP) permet à un attaquant d’exploiter les applications Web en manipulant les paramètres de la requête dans l’URL et le corps demandé. Cette vulnérabilité peut provoquer des Cross-Site Scripting (XSS), des injections SQL ou même des contournements d’autorisation. HPP affecte à la fois le coté Serveur et les composants coté client. En effet, l’attaque consiste à injecter des délimiteurs de chaînes de requêtes encodées dans des paramètres HTTP existants (par exemple GET / POST / Cookie).

Exploit:

Un exemple d’exploitation d’une HPP pour provoquer une injection SQL:

http://example.com/search.aspx?q=select/*&q=*/name&q=password/*&q=*/from/*&q=*/users

Résultat de cette injection HPP:

q=select/*,*/name,password/*,*/from*,*/users

Généralement, un attaquant peut utiliser les vulnérabilités HPP pour:

  • supprimer des paramètres HTTP codés existants
  • modifier le comportement normal de l’application
  • accéder et exploiter potentiellement des variables qui n’ont pas été correctement contrôlées.
  • ignorer les règles WAF ou les mécanismes de validation des entrées.

Comment tester:

Comme l’affectation des paramètres HTTP se fait typiquement dans le serveur d’application, et non dans le code applicatif lui-même, tester les réponses à la pollution de paramètres devrait se faire de manière uniforme sur toutes les pages et actions. Cependant, comme cela nécessite une connaissance approfondie de la logique applicative, tester les HPP nécessite des tests manuels. Les outils automatisés (comme HPP finder ou OWASP ZAP HPP) ne peuvent assister que partiellement les auditeurs.

Contre-mesure & recommandations:

Afin d’éviter ces types de vulnérabilités, une validation d’entrée étendue et appropriée devrait être effectuée. Il existe des méthodes sûres pour être conformes à chaque technologie Web. De plus, la prise de conscience du fait que les utilisateurs peuvent fournir plus d’un paramètre devrait être augmentée. Du côté client, utiliser l’encodage d’URL en plaçant le contenu fourni par l’utilisateur dans les liens et appliquer une Regular Expression (regexp) strict dans la réécriture d’URL.

3 – Server Side Request Forgery (SSRF) CWE-918:

Server Side Request Forgery (SSRF) est une vulnérabilité qui permet à un attaquant de forcer un serveur vulnérable à déclencher des requêtes malveillantes vers des ressources internes ou des serveurs tiers. SSRF est habituellement utilisé pour cibler les systèmes internes derrière les firewalls qui sont normalement inaccessibles à un attaquant du réseau externe. L’idée est de trouver des interfaces du serveur victime qui permettront d’envoyer des paquets à son localhost ou à un autre serveur isolé par un firewall depuis l’extérieur. Idéalement, cette interface permet d’envoyer des paquets à n’importe quel hôte et n’importe quel port. De plus, cette interface doit être accessible à distance sans authentification ou au moins avec des droits minimaux.

La SSRF se produit lorsqu’une application Web effectue une demande sur laquelle un attaquant a un contrôle total ou partiel. Un exemple commun est le moment où un attaquant peut contrôler tout ou partie de l’URL vers laquelle l’application Web fait une demande à un service tiers. Généralement, un attaquant peut utiliser la vulnérabilité SSRF pour: by passer les firewalls, accéder au réseau interne ou même obtenir des XSS, des injections SQL via le contenu retourné…

Exploit:

 

  1. Trouver le point final suivant dans l’URL: https://example.com/example/media_preview.php?url=
  2. Définir une URL distante qui pointe vers une page qui contient un code html pour exécuter une XSS: https://example.com/example/media_preview.php?url=http://ziot.org/xss.html? 

Comment tester:.

Vérifier s’il y a un point final url= dans l’URL de l’application Web et essayer de le modifier avec un autre URL, d’autres adresses IP locales, ou même d’autres protocoles URL (par exemple: file:// , ssh://, ftp:// …) et analyser la réponse du serveur après la modification.

Contre-mesure & recommandations:

  • Manipulation des réponses: en veillant à ce que la réponse reçue par le serveur distant soit celle qui doit être attendue, il est important d’éviter l’envoi des données de réponse imprévues à l’attaquant. Ainsi, en aucun cas, le corps de réponse brut de la demande envoyée par le serveur doit être livré au client.
  • Désactiver les schémas d’URL inutilisés: si l’application utilise uniquement HTTP ou HTTPS pour effectuer des requêtes, il ne faut autoriser que ces schémas d’URL. La désactivation des schémas d’URL inutilisés empêchera une application Web de faire des requêtes en utilisant des schémas d’URL potentiellement dangereux tels que: le file:///, dict://, ftp:// …
  • Mise en place d’une liste blanche d’entrées et une résolution DNS afin d’éviter d’injecter des adresses locales.
  • Authentification sur les services internes.