Scanner de sécurité d'applications Web créé par lcamtuf pour google - Miroir non officiel
http://code.google.com/p/skipfish/
Écrit et maintenu par :
Michal Zalewski [email protected] Niels Heinen [email protected] Sebastian Roschke [email protected]
Copyright 2009 - 2012 Google Inc, tous droits réservés.
Publié sous les termes et conditions de la licence Apache, version 2.0.
Skipfish est un outil actif de reconnaissance de sécurité pour applications web. Il prépare un plan de site interactif pour le site ciblé en effectuant une exploration récursive et des sondages basés sur un dictionnaire. La carte résultante est ensuite annotée avec la sortie d'un certain nombre de vérifications de sécurité actives (mais, espérons-le, non perturbatrices). Le rapport final généré par l'outil est destiné à servir de base pour des évaluations professionnelles de sécurité d'applications web.
Un certain nombre d'outils commerciaux et open source dotés de fonctionnalités analogues sont facilement disponibles (par exemple, Nikto, Nessus) ; utilisez celui qui vous convient le mieux. Cela dit, skipfish tente de résoudre certains des problèmes courants associés aux scanners de sécurité web. Les avantages spécifiques incluent :
Haute performance : 500+ requêtes par seconde contre des cibles Internet réactives, 2000+ requêtes par seconde sur les réseaux LAN / MAN, et 7000+ requêtes contre des instances locales ont été observées, avec une empreinte CPU, réseau et mémoire très modeste. Cela peut être attribué à :
Un modèle d'entrée/sortie réseau et de traitement de données asynchrone, monothread et multiplexé qui élimine les inefficacités de gestion de la mémoire, d'ordonnancement et de communication inter-processus présentes dans certains clients multithread.
Des fonctionnalités HTTP/1.1 avancées telles que les requêtes par plage, la compression de contenu et les connexions persistantes, ainsi qu'un dimensionnement forcé de la taille des réponses pour maîtriser les frais généraux au niveau réseau.
Une mise en cache intelligente des réponses et des heuristiques avancées de comportement de serveur sont utilisées pour minimiser le trafic inutile.
Une implémentation C pure orientée performance, incluant une pile HTTP personnalisée.
Facilité d'utilisation : skipfish est hautement adaptatif et fiable. Le scanner propose :
Reconnaissance heuristique des schémas obscurs de gestion de paramètres basés sur le chemin et la requête.
Gestion gracieuse des sites multi-cadres où certains chemins obéissent à des sémantiques complètement différentes, ou sont soumis à des règles de filtrage différentes.
Construction automatique de listes de mots basée sur l'analyse du contenu du site.
Fonctionnalités d'analyse probabiliste pour permettre des évaluations périodiques limitées dans le temps de sites arbitrairement complexes.
Des vérifications de sécurité bien conçues : l'outil est destiné à fournir des résultats précis et significatifs :
Des dictionnaires artisanaux offrent une excellente couverture et permettent des tests approfondis $mot-clé.$extension dans un délai raisonnable.
Des sondes différentielles en trois étapes sont préférées aux vérifications par signature pour détecter les vulnérabilités.
Une logique de type Ratproxy est utilisée pour repérer des problèmes de sécurité subtils : falsification de requête intersite, inclusion de script intersite, contenu mixte, problèmes de non-concordance MIME et de jeu de caractères, directives de mise en cache incorrectes, etc.
Les vérifications de sécurité incluses sont conçues pour gérer des scénarios délicats : XSS stocké (chemin, paramètres, en-têtes), injection SQL ou XML aveugle, ou injection shell aveugle.
Signatures de contenu de style Snort qui mettront en évidence les erreurs de serveur, les fuites d'informations ou les applications web potentiellement dangereuses.
Le post-traitement du rapport réduit considérablement le bruit causé par d'éventuels faux positifs ou astuces de serveur en identifiant les motifs répétitifs.
Cela dit, skipfish n'est pas une solution miracle et peut ne pas convenir à certains usages. Par exemple, il ne satisfait pas à la plupart des exigences énoncées dans les critères d'évaluation des scanners de sécurité d'applications web du WASC (certaines intentionnellement, d'autres par nécessité) ; et contrairement à la plupart des autres projets de ce type, il n'est pas livré avec une vaste base de données de vulnérabilités connues pour les vérifications de bannières.
Une liste approximative des vérifications de sécurité offertes par l'outil est décrite ci-dessous.
Risques élevés (pouvant mener à une compromission du système) :
Risques moyens (pouvant mener à une compromission des données) :
Problèmes à faible risque (impact limité ou spécificité faible) :
Avertissements internes :
Entrées informatives non spécifiques :
En plus d'une liste des problèmes identifiés, skipfish fournit également des aperçus récapitulatifs des types de documents et des types de problèmes trouvés ; et un plan de site interactif, avec les nœuds découverts par force brute notés de manière distinctive.
REMARQUE : Par choix de conception délibéré, skipfish ne se plaindra pas de manière redondante à propos de problèmes hautement non spécifiques, y compris mais sans s'y limiter :
La plupart de ces aspects sont faciles à inspecter dans un rapport si on le souhaite - par exemple, tous les formulaires HTML sont listés séparément, tout comme les nouveaux cookies ou les en-têtes HTTP intéressants - et l'on s'attend à ce que l'auditeur puisse choisir de faire certaines recommandations de conception basées sur ces données le cas échéant. Cela dit, ces occurrences ne sont pas mises en évidence comme une faille de sécurité spécifique.
Tout d'abord, ne soyez pas malveillant. Utilisez skipfish uniquement contre des services vous appartenant, ou pour lesquels vous avez une autorisation de test.
Gardez à l'esprit que tous les types de tests de sécurité peuvent être perturbateurs. Bien que le scanner soit conçu pour ne pas effectuer d'attaques malveillantes, il peut accidentellement interférer avec les opérations du site. Vous devez accepter le risque et planifier en conséquence. Exécutez le scanner sur des instances de test lorsque c'est possible, et soyez prêt à gérer les conséquences si les choses tournent mal.
Notez également que l'outil est destiné à être utilisé par des professionnels de la sécurité et est de nature expérimentale. Il peut renvoyer des faux positifs ou manquer des problèmes de sécurité évidents - et même lorsqu'il fonctionne parfaitement, il n'est tout simplement pas conçu pour être une application clé en main. Ne prenez pas ses résultats pour argent comptant.
Exécuter l'outil contre des sites de démonstration fournis par des vendeurs n'est pas une bonne façon de l'évaluer, car ils se rapprochent généralement très imparfaitement des vulnérabilités ; nous n'avons fait aucun effort pour accommoder ces cas.
Enfin, le scanner n'est tout simplement pas conçu pour traiter des serveurs HTTP malveillants ou mal configurés - et n'offre aucune garantie de comportement sûr (ou sain) dans ce contexte.
Pour le compiler, décompressez simplement l'archive et essayez make. Il est probable que vous deviez d'abord installer libidn.
Ensuite, vous devez lire les instructions fournies dans doc/dictionaries.txt pour sélectionner le bon fichier dictionnaire et le configurer correctement. Cette étape a un impact profond sur la qualité des résultats de l'analyse ultérieure, alors ne la sautez pas.
Une fois le dictionnaire sélectionné, vous pouvez utiliser -S pour charger ce dictionnaire, et -W pour spécifier un fichier initialement vide pour les nouveaux mots-clés spécifiques au site appris (qui seront utiles pour les évaluations futures) :
$ touch new_dict.wl
$ ./skipfish -o output_dir -S existing_dictionary.wl -W new_dict.wl
http://www.example.com/some/starting/path.txt
Vous pouvez utiliser -W- si vous ne souhaitez pas stocker les mots-clés auto-appris.
Notez que vous pouvez fournir plus d'une URL de départ si vous le souhaitez ; elles seront toutes explorées. Il est également possible de lire les URL à partir d'un fichier, en utilisant la syntaxe suivante :
$ ./skipfish [...autres options...] @../path/to/url_list.txt
L'outil affichera des statistiques utiles pendant que l'analyse est en cours. Vous pouvez également basculer vers une liste des requêtes HTTP en cours en appuyant sur Entrée.
Dans l'exemple ci-dessus, skipfish analysera l'intégralité de www.example.com (y compris les services sur d'autres ports, s'ils sont liés depuis la page principale) et écrira un rapport dans output_dir/index.html. Vous pouvez ensuite visualiser ce rapport avec votre navigateur préféré (JavaScript doit être activé ; et en raison des récentes améliorations de sécurité file:/// dans certains navigateurs, vous devrez peut-être accéder aux résultats via HTTP). Le fichier index.html est statique ; les résultats réels sont stockés sous forme d'une hiérarchie de fichiers JSON, adaptés au traitement automatique ou à différentes interfaces de présentation si nécessaire. De plus, une liste de toutes les URL découvertes sera enregistrée dans un seul fichier, pivots.txt, pour un post-traitement facile.
Un simple script compagnon, sfscandiff, peut être utilisé pour calculer un delta entre deux analyses exécutées contre la même cible avec les mêmes options. Le rapport le plus récent sera annoté de manière non destructive en ajoutant un fond rouge à tous les nœuds nouveaux ou modifiés ; et un fond bleu à tous les problèmes nouveaux ou modifiés trouvés.
Certains sites peuvent nécessiter une authentification pour laquelle notre support est décrit dans doc/authentication.txt. Dans la plupart des cas, vous voudrez utiliser la méthode d'authentification par formulaire qui est capable de détecter les sessions rompues afin de se réauthentifier.
Une fois authentifié, certaines URL du site peuvent déconnecter votre session ; vous pouvez y remédier de deux manières : en utilisant l'option -N, qui amène le scanner à rejeter les tentatives de définir ou de supprimer des cookies ; ou avec le paramètre -X, qui empêche la récupération des URL correspondantes :
$ ./skipfish -X /logout/logout.aspx ...autres paramètres...
L'option -X est également utile pour accélérer vos analyses en excluant /icons/, /doc/, /manuals/ et autres emplacements standard et banals de ce type. En général, vous pouvez utiliser -X et -I (pour n'explorer que les URL correspondant à une sous-chaîne) pour limiter la portée d'une analyse comme vous le souhaitez - y compris la restreindre à un protocole et un port spécifiques :
$ ./skipfish -I http://example.com:1234/ ...autres paramètres...
Une fonction connexe, -K, vous permet de spécifier les noms de paramètres à ne pas tester (utile pour les applications qui placent les identifiants de session dans l'URL, afin de minimiser le bruit).
Une autre option de cadrage utile est -D - vous permettant de spécifier des hôtes ou domaines supplémentaires à considérer comme dans le périmètre du test. Par défaut, tous les hôtes apparaissant dans les URL de la ligne de commande sont ajoutés à la liste - mais vous pouvez utiliser -D pour élargir ces règles, par exemple :
$ ./skipfish -D test2.example.com -o output-dir http://test1.example.com/
...ou, pour une correspondance de domaine générique, utilisez :
$ ./skipfish -D .example.com -o output-dir http://test1.example.com/
Dans certains cas, vous ne voulez pas réellement explorer un domaine tiers, mais vous faites suffisamment confiance au propriétaire de ce domaine pour ne pas vous inquiéter de l'inclusion de contenu cross-domain depuis cet endroit. Pour supprimer les avertissements, vous pouvez utiliser l'option -B, par exemple :
$ ./skipfish -B .google-analytics.com -B .googleapis.com ...autres paramètres...
Par défaut, skipfish envoie des en-têtes HTTP minimalistes pour réduire la quantité de données échangées sur le réseau ; certains sites examinent les chaînes User-Agent ou l'ordre des en-têtes pour rejeter les clients non pris en charge. Dans ce cas, vous pouvez utiliser -b ie, -b ffox, ou -b phone pour imiter l'un des deux navigateurs populaires (ou iPhone).
En ce qui concerne la personnalisation de vos requêtes HTTP, vous pouvez également utiliser l'option -H pour insérer des en-têtes supplémentaires non standard ; ou -F pour définir un mappage personnalisé entre un hôte et une adresse IP (en contournant le résolveur). Cette dernière fonctionnalité est particulièrement utile pour les services pas encore lancés ou hérités.
Certains sites peuvent être trop volumineux pour être analysés dans un délai raisonnable. Si le site comporte des "tarpits" bien définis - par exemple, 100 000 profils utilisateur presque identiques dans le cadre d'un réseau social - ces emplacements spécifiques peuvent être exclus avec -X ou -S. Dans d'autres cas, vous pouvez avoir recours à d'autres paramètres : -d limite la profondeur d'exploration à un nombre spécifié de sous-répertoires ; -c limite le nombre d'enfants par répertoire ; -x limite le nombre total de descendants par branche de l'arbre d'exploration ; et -r limite le nombre total de requêtes à envoyer lors d'une analyse.
Une option intéressante est disponible pour les évaluations répétées : -p. En spécifiant un pourcentage entre 1 et 100%, il est possible d'indiquer au robot d'exploration de suivre moins de 100% des liens, et d'essayer moins de 100% des entrées du dictionnaire. Cela - naturellement - limite l'exhaustivité d'une analyse, mais contrairement à la plupart des autres paramètres, cela le fait de manière équilibrée et non déterministe. C'est extrêmement utile lorsque vous mettez en place des évaluations périodiques de votre infrastructure, limitées dans le temps. Une autre option connexe est -q, qui définit la graine aléatoire initiale pour le robot à une valeur spécifiée. Cela peut être utilisé pour reproduire exactement une analyse précédente afin de comparer les résultats. Le caractère aléatoire est le plus sollicité dans le mode -p, mais également pour prendre quelques autres décisions de gestion d'analyse ailleurs.
Certains services particulièrement complexes (ou défectueux) peuvent impliquer un nombre très élevé de pages identiques ou quasi identiques. Bien que ces occurrences soient par défaut grisées dans le rapport, elles utilisent encore une certaine surface d'écran et prennent du temps à traiter au niveau JavaScript. Dans de tels cas extrêmes, vous pouvez utiliser l'option -Q pour supprimer complètement le signalement des nœuds en double, avant que le rapport ne soit écrit. Cela peut vous donner une compréhension moins complète de la façon dont le site est organisé, mais n'a aucun impact sur la couverture des tests.
Dans certaines évaluations rapides, vous n'avez peut-être également aucun intérêt à accorder une attention particulière à la fonctionnalité souhaitée du site - espérant explorer uniquement les secrets non liés. Dans ce cas, vous pouvez spécifier -P pour inhiber toute analyse HTML. Cela limite la couverture et supprime la capacité du scanner à apprendre de nouveaux mots-clés en regardant le HTML, mais accélère considérablement le test. Une autre option similaire qui réduit le risque d'effets persistants d'une analyse est -O, qui inhibe toutes les étapes d'analyse et de soumission de formulaires.
Certains sites qui traitent des données utilisateur sensibles se soucient du SSL - et de le faire correctement. Skipfish peut éventuellement vous aider à identifier les problèmes de contenu mixte ou les scénarios de soumission de mot de passe problématiques - utilisez l'option -M pour activer cela. Le scanner se plaindra de situations telles que des scripts http:// chargés sur des pages https:// - mais ignorera les scénarios sans risque comme les images.
De même, certains sites pointilleux peuvent se soucier des cas où la mise en cache est restreinte au niveau HTTP/1.1, mais aucune directive de mise en cache HTTP/1.0 explicite n'est donnée ; en spécifiant -E dans la ligne de commande, skipfish journalisera soigneusement tous ces cas.
Dans certaines occasions, vous souhaitez limiter le nombre de requêtes par seconde pour réduire la charge sur le serveur cible (ou éventuellement contourner la protection DoS). Le drapeau -l peut être utilisé pour définir cette limite et la valeur donnée est le nombre maximum de requêtes par seconde que vous souhaitez que skipfish effectue.
Les analyses ne devraient généralement pas prendre des semaines. Dans de nombreux cas, vous souhaitez probablement limiter la durée de l'analyse pour qu'elle s'inscrive dans une certaine fenêtre temporelle. Cela peut être fait avec le drapeau -k, qui permet de spécifier le nombre d'heures, de minutes et de secondes dans un format H:M:S. L'utilisation de ce drapeau peut affecter la couverture de l'analyse si le délai d'expiration survient avant le test de toutes les pages.
Enfin, dans certaines évaluations impliquant des sites autonomes sans contenu utilisateur étendu, l'auditeur peut se soucier de tout e-mail externe ou lien HTTP vu, même s'ils n'ont pas d'impact immédiat sur la sécurité. Utilisez l'option -U pour les journaliser.
La gestion des dictionnaires est un sujet spécial, et - comme mentionné - est couverte plus en détail dans doc/dictionaries.txt. Veuillez lire ce fichier avant de continuer. Certaines des options pertinentes incluent -S et -W (couvertes plus tôt), -L pour supprimer l'auto-apprentissage, -G pour limiter la taille du pot de devinettes de mots-clés, -R pour supprimer les anciennes entrées du dictionnaire, et -Y pour inhiber le test coûteux $mot-clé.$extension.
Skipfish propose également un mécanisme de remplissage automatique de formulaires afin de maximiser la couverture de l'analyse. Les valeurs doivent être non malveillantes, car elles ne sont pas destinées à implémenter des vérifications de sécurité - mais plutôt à passer outre la logique de validation d'entrée. Vous pouvez définir des règles supplémentaires, ou remplacer les règles existantes, avec l'option -T (-T nom_champ_formulaire=valeur_champ, par exemple -T login=test123 -T password=test321 - bien que noter que -C et -A sont une bien meilleure méthode pour se connecter).Il existe également une poignée d'options liées aux performances. Utilisez -g pour définir le nombre maximum de connexions à maintenir, globalement, pour toutes les cibles (il est raisonnable de garder cela en dessous de 50 environ pour ne pas submerger la pile TCP/IP de votre système ou des périphériques NAT/pare-feu à proximité) ; et -m pour définir la limite par IP (expérimentez un peu : 2-4 est généralement bon pour localhost, 4-8 pour les réseaux locaux, 10-20 pour les cibles externes, 30+ pour les hôtes très lents ou sans keep-alive). Vous pouvez également utiliser -w pour définir le délai d'attente d'E/S (c'est-à-dire que skipfish n'attendra qu'un certain temps pour une lecture ou une écriture individuelle), et -t pour définir le délai d'attente total de la requête, pour tenir compte des sites vraiment lents ou vraiment rapides.
Enfin, -f contrôle le nombre maximum d'erreurs HTTP consécutives que vous êtes prêt à voir avant d'abandonner l'analyse ; et -s définit la longueur maximale d'une réponse à récupérer et à analyser (les réponses plus longues seront tronquées).
Lors de l'analyse de sites volumineux et riches en contenu multimédia, vous pouvez également spécifier -e. Cela empêche la conservation en mémoire des documents binaires à des fins de rapport, et libère beaucoup de RAM.
Un contrôle supplémentaire du débit est possible via des outils en mode utilisateur tiers comme trickle, ou la régulation du trafic au niveau du noyau.
Oh, et les statistiques d'analyse en temps réel peuvent être supprimées avec -u.
Une analyse standard et authentifiée d'un site bien conçu et autonome (avertit de tous les liens externes, e-mails, contenu mixte et problèmes d'en-têtes de cache), incluant une force brute douce :
$ touch new_dict.wl
$ ./skipfish -MEU -S dictionaries/minimal.wl -W new_dict.wl
-C "AuthCookie=value" -X /logout.aspx -o output_dir
http://www.example.com/
Analyse avec cinq connexions, mais sans force brute ; se faire passer pour MSIE et faire confiance au contenu de example.com :
$ ./skipfish -m 5 -L -W- -o output_dir -b ie -B example.com
http://www.example.com/
Force brute lourde uniquement (pas d'extraction de liens HTML), limitée à un seul répertoire et expirant après 5 secondes :
$ touch new_dict.wl
$ ./skipfish -S dictionaries/complete.wl -W new_dict.wl
-P -I http://www.example.com/dir1/ -o output_dir -t 5 -I
http://www.example.com/dir1/
Pour une brève liste de toutes les options de ligne de commande, essayez ./skipfish -h.
La plupart des problèmes signalés par skipfish devraient être explicites, en supposant que vous ayez une bonne maîtrise des fondamentaux de la sécurité web. Si vous avez besoin d'un rappel rapide sur certains sujets plus complexes, comme le MIME sniffing, vous pouvez consulter notre manuel complet Browser Security Handbook comme point de départ :
Si vous avez toujours besoin d'aide, plusieurs organisations consacrent des efforts considérables à documenter et expliquer de nombreuses menaces courantes de sécurité web, et à conseiller le public sur la manière de les traiter. Je vous encourage à consulter les documents publiés par l'OWASP et le Web Application Security Consortium, entre autres :
Bien que je sois heureux de diagnostiquer les problèmes du scanner lui-même, je ne peux malheureusement pas offrir d'assistance concernant le fonctionnement interne des applications web tierces.
Voici une liste de fonctionnalités actuellement manquantes dans skipfish. Si vous souhaitez améliorer l'outil en contribuant du code dans l'un de ces domaines, veuillez me le faire savoir :
Vérifications des débordements de tampon : après mûre réflexion, je soupçonne qu'il n'y a pas de moyen fiable de tester les débordements de tampon à distance. Tout comme la condition de défaut réelle que nous recherchons, des vérifications appropriées de la taille des tampons peuvent également entraîner des exceptions non interceptées, des messages 500, etc. J'aimerais cependant me tromper.
Détection complète des XSS en JavaScript : quelques vérifications rudimentaires sont présentes dans le code, mais il n'y a pas de véritable moteur de script pour évaluer les expressions et l'accès au DOM.
Bogues d'injection / de consommation de caractères à encodage variable : ces problèmes semblent désormais largement traités au niveau du navigateur, ils étaient donc de priorité bien moindre au moment de la rédaction de ce document.
Vérifications de sécurité et extraction de liens pour le contenu tiers basé sur des plugins (Flash, Java, PDF, etc.).
Sondes de force brute sur les mots de passe et les noms de fichiers numériques.
Intégration avec les moteurs de recherche (vhosts, chemins de départ).
Décodage de VIEWSTATE.
Authentification NTLM et Digest.
Tests PHP plus spécifiques (injection eval, RFI).
Support proxy : un support expérimental du proxy HTTP est disponible via une directive #define dans config.h. Ajouter le support du proxy HTTPS est plus compliqué et toujours en cours.
Option de reprise d'analyse, meilleures informations en cours d'exécution.
Support d'installation autonome (make install).
Interface web de planification et de gestion.
Il n'existe pas d'explorateur web si bon qu'un framework web ne puisse un jour le mettre à feu. Si vous rencontrez ce qui semble être un mauvais comportement (par exemple, une analyse qui prend une éternité et génère trop de requêtes, des nœuds complètement farfelus dans la sortie d'analyse, ou des crashs purs et simples), veuillez d'abord consulter notre page des problèmes connus :
Si vous n'y trouvez pas de réponse satisfaisante, recompilez le scanner avec :
$ make clean debug
... et exécutez-le à nouveau de cette façon :
$ ./skipfish [...options précédentes...] 2>logfile.txt
Vous pouvez ensuite inspecter logfile.txt pour avoir une idée de ce qui a mal tourné ; si cela ressemble à un problème du scanner, veuillez supprimer toute information sensible du fichier journal et l'envoyer à l'auteur.
Si le scanner a planté, veuillez le recompiler comme indiqué ci-dessus, puis tapez :
$ ulimit -c unlimited $ ./skipfish [...options précédentes...] 2>logfile.txt $ gdb --batch -ex back ./skipfish core
... et assurez-vous d'envoyer également à l'auteur la sortie de cette dernière commande.
Skipfish est rendu possible grâce aux contributions et aux précieux retours de l'équipe d'ingénierie de sécurité de l'information de Google.
Si vous avez des rapports de bogues, des questions, des suggestions ou des préoccupations concernant l'application, l'auteur principal peut être joint à [email protected].
