Attaques/Applications-et-Systeme-Exploitation/Attaques-applications-web

From aldeid
Jump to navigation Jump to search

Attaque des applications Web

Définition

Le Web étant en constante évolution, de plus en plus de sites et d'applications Web apparaissent chaque jour. De ce fait, ces applications, quand bien même protégées par une authentification, sont des cibles potentielles pour les pirates. C'est pourquoi il est indispensable de considérer une sécurité appropriée lorsque vous publiez une application sur la toile. Cette section vous présente différentes attaques et outils dont usent les attaquants potentiels pour voler des informations sur les applications Web, ou encore modifier, voire détruire ces portails et les données qu'ils contiennent.

Attaques

  • Authentification et privilèges :
    • Collecte d'identifiants : si l'application révèle une faiblesse dans les messages d'erreur lors de l'authentification (personnalisation des messages en fonction de l'erreur sur le login ou le mot de passe) d'une part, et qu'aucun système de "blacklist" (blocage d'un identifiant après un nombre défini d'échecs d'authentification) n'est effectué d'autre part, un attaquant pourrait exploiter cette faille en collectant des identifiants par bruteforce.
    • Sniffing des comptes sur un LAN : sur un réseau local, un attaquant est susceptible d'intercepter des données d'authentification par sniffing si la page d'authentification repose sur le protocole HTTP. Privilégiez HTTPS afin de crypter les informations qui circulent sur le réseau.
    • Contrôle de la robustesse des mots de passe : un attaquant peut soumettre l'authentification à une attaque sur les mots de passe
    • Echappement des contrôles clients : un attaquant va vérifier si les contrôles JavaScript exécutés côté client sont également effectués côté serveur (désactivation du JavaScript)
    • Modification des paramètres envoyés par le client : l'attaquant peut modifier les données envoyées par le navigateur dans le but d'élever ses privilèges
    • Contrôles de privilèges dans toutes les pages de l'application : si des contrôles de privilèges ne sont pas placés dans chaque page de l'application, n'importe quel utilisateur pourrait élever ses privilèges en accédant directement aux URL des pages auxquelles il n'a normalement pas accès avec son profil.
    • Modules "cachés" : ce n'est pas parce qu'une partie de l'application n'est pas référencée par des liens dans l'application (modules "cachés") qu'un attaquant ne va pas les découvrir. En effet, s'il n'est pas spécifié explicitement d'une part de ne pas indexer le dit module "caché", celui-ci est susceptible d'être découvert par Google. D'autre part, des outils de bruteforce comme DirBuster ou Wikto permettent de dévoiler cette partie cachée de l'iceberg.
  • Injections et exploitation des champs masqués :
    • Injections SQL : l'attaquant peut soumettre l'application à des injections SQL afin de passer l'authentification sans s'authentifier ou encore voler, voire détruire des données stockées en base de données
    • Purification des données : l'attaquant va soumettre des données non initialement attendues par l'application, au travers des champs de formulaire, afin de vérifier si les données sont purifiées
    • XSS : l'attaquant va tenter d'exploiter des failles de XSS
    • Injection de code arbitraire : si les données ne sont pas vérifiées côté serveur, un attaquant va pouvoir injecter du code arbitraire pour récupérer des informations du serveur, non initialement fournies par l'application.
    • Champs masqués (hidden) : un attaquant peut intercepter et modifier les requêtes à destination du serveur (voir WebScarab) dans le but de forcer des valeurs qui ne seraient contrôlées que du côté client.
  • Robustesse des méthodes basées sur ajax :
    • Contrôle du contenu envoyé au client : un attaquant peut découvrir dans le code source des informations, même si elles ne sont pas affichées dans la page (données stockées dans des tableaux JavaScript par exemple)
    • Vérification de l'origine des requêtes entrantes : un attaquant peut directement appeler une requête normalement appelée en ajax
    • Injections DOM, XML, JSON : un attaquant peut injecter du code dans des requêtes Ajax si elles ne purifient pas les entrées utilisateur.
  • Robustesse du mécanisme de génération des sessions :
    • Dès lors que les identifiants de session sont prévisibles, le mécanisme de génération des sessions est réputé faillible. Un attaquant pourrait exploiter cette faiblesse à des fins de vol de session.
  • Buffer overflow sur les applications Web :
    • les tests de montée de charge sont souvent laissés à l'abandon. Un attaquant peut soumettre une application Web à un fort trafic afin d'en étudier le comportement.
    • DoS (déni de service) : Un attaquant peut également tester le comportement d'une application avec des accès concurrents. Si l'application est mal conçue, un attaquant est susceptible de rendre l'application inopérante.
  • Qualité de code :
    • Un attaquant va rechercher dans le code des commentaires laissés (in)volontairement par les développeurs.
    • Traitement des exceptions : un attaquant peut exploiter une mauvaises gestion des erreurs pour récupérer des informations sur l'architecture de l'application (en particulier la base de données)

Outils

Voir les article suivants :

Protections contre les attaques des applications Web

  • Connaissance des attaques : Le meilleur moyen de prévenir les attaques sur les applications Web est de les connaître. Le groupe OWASP propose un toolkit de formation, WebGoat, contenant une application volontairement vulnérable à de nombreuses attaques. Si vous êtes développeur, entraînez-vous à ces tutoriels afin de ne pas commettre certaines erreurs de programmation.
  • Purification des données : purifiez les données utilisateur (issues des champs de formulaire) avant de les traiter. Ceci vous évitera les injections diverses (injections SQL, XSS, commandes arbitraires, etc.)
  • Reverse-proxy : La mise en place d'un reverse proxy améliore également la sécurité de vos applications Web
  • Firewall applicatif (WAF : Web Application Firewall) : Vous avez également la possibilité d'installer un firewall applicatif, comme par exemple mod_security pour Apache. Celui-ci permet de combler certaines vulnérabilités applicatives en rejetant les requêtes douteuses.
  • Indexation : Portez une vigilance particulière au contenu que vous souhaitez indexer sur Internet. Si vous ne spécifiez pas explicitement le contenu qui ne doit pas apparaître dans les bases d'indexation des robots, celui-ci sera indexé automatiquement (comportement par défaut). Par ailleurs, le célèbre moteur de recherche Google peut se révéler être une arme redoutable pour mettre en évidence des problèmes de configuration serveur, voire même, indexer des backups de fichiers sources. Pour plus d'informations à ce sujet, vous pouvez lire ces articles :
  • OWASP : consultez les préconisations d'OWASP
Retrieved from "https://www.aldeid.com/w/index.php?title=Attaques/Applications-et-Systeme-Exploitation/Attaques-applications-web&oldid=35574"