Outils de test de pénétration [fermé]

https://stackoverflow.com/questions/72166

09-06-2019
|

Question

Nous avons des centaines de sites Web développés en asp, .net et java et nous payons beaucoup pour qu'un organisme externe réalise des tests d'intrusion sur nos sites afin de vérifier les failles de sécurité. Existe-t-il un (bon) logiciel (payant ou gratuit) pour le faire?

ou .. existe-t-il des articles techniques qui peuvent m'aider à développer cet outil?

La solution

Les outils de test automatisés pour les applications Web vous permettent de vous orienter de différentes manières.

Il existe tout d'abord les scanners Web commerciaux , parmi lesquels HP WebInspect et Rational AppScan sont les plus populaires. Ce sont des "tout-en-un", "feu et oublie". les outils que vous téléchargez et installez sur un bureau Windows interne, puis donnez une URL à spider de votre site, recherchez les vulnérabilités connues (c'est-à-dire les choses qui ont frappé Bugtraq) et testez les vulnérabilités de script intersite et d'injection SQL.

Deuxièmement, il existe les outils d'analyse du code source , parmi lesquels Coverity et Fortify sont probablement les deux mieux connus. Ce sont des outils que vous installez sur le bureau du développeur pour traiter votre code source Java ou C # et rechercher des modèles connus de code non sécurisé, comme une validation de saisie médiocre.

Enfin, il existe les outils de test de pénétration . Burp Suite est de loin l'outil de test d'intrusion d'applications Web le plus populaire parmi les professionnels de la sécurité. Vous pouvez le trouver à l'adresse http: // www. .portswigger.net / proxy . D'autres incluent Spike Proxy et OWASP WebScarab. Encore une fois, vous allez l'installer sur un bureau Windows interne. Il fonctionnera sous la forme d'un proxy HTTP et vous dirigerez votre navigateur vers celui-ci. Vous utiliserez vos applications comme un utilisateur normal, tout en enregistrant vos actions. Vous pouvez ensuite revenir à chaque page ou action HTTP et rechercher des problèmes de sécurité.

Dans un environnement complexe, et particulièrement si vous envisagez une activité de bricolage, je vous recommande vivement les outils de test de pénétration . Voici pourquoi:

Les scanners Web commerciaux offrent beaucoup de "largeur", ainsi que d'excellents rapports. Cependant:

Ils ont tendance à rater des choses, car chaque application est différente.
Ils sont chers (WebInspect commence par dizaines de milliers).
Vous payez pour des choses dont vous n’avez pas besoin (comme des bases de données de mauvais CGI connus des années 90).
Ils sont difficiles à personnaliser.
Ils peuvent produire des résultats bruyants.

Les scanners de code source sont plus complets que les scanners Web. Cependant:

Ils sont encore plus chers que les scanners Web.
Ils ont besoin du code source pour fonctionner.
Pour être efficaces, ils vous obligent souvent à annoter votre code source (par exemple, pour sélectionner les chemins d'entrée).
Ils ont tendance à produire des faux positifs.

Les scanners commerciaux et les scanners de code source ont la mauvaise habitude de devenir des étagères. Pire encore, même si elles fonctionnent, leur coût est comparable à celui d’une ou deux applications entières auditées par un cabinet de conseil; si vous faites confiance à vos consultants, vous êtes assuré d'obtenir de meilleurs résultats que des outils.

Les outils de test de pénétration présentent également des inconvénients:

Ils sont beaucoup plus difficiles à utiliser que les scanners commerciaux "feu-et-oublie".
Ils assument une certaine expertise des vulnérabilités des applications Web - vous devez savoir ce que vous recherchez.
Ils produisent peu ou pas de rapports officiels.

D'autre part:

Ils sont beaucoup, beaucoup moins chers - le meilleur du lot, Burp Suite, ne coûte que 99 EUR et possède une version gratuite.
Ils sont faciles à personnaliser et à ajouter à un flux de travail de test.
Ils sont beaucoup mieux à même de vous aider à "apprendre à connaître". vos applications de l'intérieur.

Voici quelque chose que vous feriez avec un outil de test de stylo pour une application Web de base:

Connectez-vous à l'application via le proxy
Créer une "liste de résultats" " des principaux domaines fonctionnels de l'application et exercez-vous une fois.
Utilisez le " araignée " outil dans votre application de test test pour trouver toutes les pages, actions et gestionnaires de l'application.
Pour chaque page dynamique et chaque formulaire HTML mis à jour par l'araignée, utilisez l'option "fuzzer". outil (Burp l’appelle un "intrus") pour exercer chaque paramètre avec des entrées non valides. La plupart des fuzzers sont livrés avec des chaînes de test de base comprenant:
- Métacaractères SQL
- HTML / Javascript échappe et métacaractères
- Variantes internationalisées de celles-ci pour échapper aux filtres d'entrée
- Noms et valeurs de champs de formulaire par défaut bien connus
- Noms de répertoire, noms de fichier et verbes de gestionnaire connus
Passez plusieurs heures à filtrer les erreurs résultantes (une exécution typique de fuzz pour un formulaire peut en générer 1 000) à la recherche de réponses suspectes.

Il s’agit d’un "métal nu" à forte intensité de main-d’œuvre; approche. Mais lorsque votre entreprise est propriétaire des applications réelles, l’approche «nu-métal» porte ses fruits, car elle permet de créer des suites de tests de régression qui fonctionneront comme des horloges à chaque cycle de développement pour chaque application. C'est une victoire pour un tas de raisons:

Vos tests de sécurité prendront une quantité prévisible de temps et de ressources par application, ce qui vous permettra d'établir un budget et de trier.
Votre équipe obtiendra des résultats extrêmement précis et complets, car vos tests seront adaptés à vos applications.
Cela coûtera moins cher que les scanners commerciaux et moins que les consultants.

Bien sûr, si vous choisissez cette voie, vous devenez essentiellement un consultant en sécurité pour votre entreprise. Je ne pense pas que ce soit une mauvaise chose Si vous ne voulez pas cette expertise, WebInspect ou Fortify ne vous aidera pas beaucoup de toute façon.

Autres conseils

Je sais que vous avez posé une question spécifique sur les outils de pentestage, mais puisque ceux-ci ont été amplement répondus (j'utilise généralement un mélange d'AppScan et de pentester formé), il est important de souligner que le pentestage n'est pas le seul moyen pour "vérifier les failles de sécurité" et n'est souvent pas le plus efficace .

Les outils de révision de code source peuvent vous fournir une visibilité bien meilleure sur votre base de code et trouver de nombreux défauts que l’essayage n’aura pas.

Cela comprend Fortify et OunceLabs (coûteux et pour de nombreuses langues), VisualStudio.NET CodeAnalysis (pour .NET et C ++, gratuit avec VSTS, correct mais pas génial), LAPSE for Java de OWASP (gratuit, correct, pas génial), CheckMarx (pas bon marché, outil fanTASTic pour .NET et Java, mais des frais généraux élevés), et bien d’autres encore.

Un point important que vous devez noter - (la plupart des) outils automatisés ne trouvent pas toutes les vulnérabilités, pas même proches. Vous pouvez vous attendre à ce que les outils automatisés détectent environ 35 à 40% des secbugs détectés par un pentester professionnel. il en va de même pour l'examen automatisé ou manuel du code source.

Et bien sûr, un cycle de développement de la sécurité (SDLC) approprié, comprenant la modélisation des menaces, la révision de la conception, etc., aidera encore plus ...

McAfee Secure n'est pas une solution. Le service qu'ils fournissent est une blague.

Voir ci-dessous:

http://blogs.zdnet.com/security/?p=1092& ; tag = rbxccnbzd1
http://blogs.zdnet.com/security/?p=1068&tag= rbxccnbzd1
http://blogs.zdnet.com/security/?p=1114&tag= rbxccnbzd1

J'ai entendu de bonnes choses à propos de SpiDynamics WebInspect en ce qui concerne les solutions payantes, ainsi que Nikto (pour une solution gratuite) et d'autres outils open source. Nessus est un excellent outil d’infrastructure si vous devez également vérifier cette couche. Vous pouvez choisir un cd live contenant plusieurs outils, appelé Nubuntu (Auditor, Helix ou toute autre distribution basée sur la sécurité, fonctionne également), puis Google quelques didacticiels pour cet outil. Assurez-vous toujours de numériser depuis le réseau local. Vous risquez de vous faire bloquer par le centre de données si vous analysez une boîte du WAN sans autorisation. Leçon apprise à la dure. ;)

Skipfish, W3af, Arachni, Ratproxy, ZAP, WebScarab: tous gratuits et très bons IMO

http://www.nessus.org/nessus/ - Nessus vous aidera à suggérer façons d'améliorer vos serveurs. Il ne peut pas vraiment tester des applications personnalisées en soi, bien que je pense que les plugins sont relativement faciles à créer par vous-même.

Jetez un coup d’œil à Analyse Rational App (auparavant appelée Watchfire). Ce n’est pas gratuit, mais il a une belle interface utilisateur, est extrêmement puissant, génère des rapports (sur mesure et contre les cadres de conformité standard tels que Basel2) et je pense que vous pouvez l’utiliser dans votre build CI.

Que diriez-vous de nikto ?

Pour ce type de test, vous voulez vraiment utiliser un type de testeur de fuzz. Le proxy SPIKE est l'un des deux testeurs fuzz pour les applications Web. Il est open source et écrit en Python. Je pense qu'il existe quelques vidéos de BlackHat ou de DefCON sur l'utilisation de SPIKE quelque part, mais j'ai du mal à les localiser.

Il existe quelques logiciels professionnels haut de gamme qui permettront de tester les applications Web et bien plus encore. Un des outils les plus populaires serait CoreImpact

Si vous envisagez de passer par le test du stylo vous-même, je vous recommande vivement de lire la majeure partie du Documentation du projet OWASP . Plus précisément, les guides de vérification, de test et de développement de la sécurité des applications OWASP. L’état d’esprit dont vous avez besoin pour bien tester votre application est un peu différent de votre état d’esprit habituel en matière de développement (non pas qu’elle DEVRAIT être différente, mais c’est généralement le cas).

Qu'en est-il du proxy du rat ?

Un web semi-automatisé et en grande partie passif   outil d'audit de la sécurité des applications,   optimisé pour une précision et   détection sensible, et automatique   annotation, des problèmes potentiels et   modèles de conception pertinents pour la sécurité   sur la base de l'observation de l'existant,   trafic initié par l'utilisateur sur des sites Web complexes   2.0 environnements.

Détecte et hiérarchise les grandes classes   de problèmes de sécurité, tels que dynamique   considérations relatives au modèle de confiance intersite,   problèmes d'inclusion de script, contenu   problèmes de service, XSRF insuffisant   et les défenses XSS, et bien plus encore

On pense actuellement que Ratproxy supporte les environnements Linux, FreeBSD, MacOS X et Windows (Cygwin).

Je sais que vous avez spécifiquement posé des questions sur les outils de test, mais depuis que ceux-ci ont été amplement répondus (j’utilise généralement un mélange d’AppScan et de pentesters formés), il est important de souligner que le test de test n’est pas le seul moyen de " vérifiez les failles de sécurité "et n’est souvent pas la plus efficace.

Les outils de révision de code source peuvent vous fournir une visibilité bien meilleure sur votre base de code et trouver de nombreux défauts que le test d’application ne permettra pas.

Et bien sûr, un cycle de développement de la sécurité (SDLC) approprié, comprenant la modélisation des menaces, la révision de la conception, etc., aidera encore plus ...

anciennement McAfee Secure, un hackersafe, .

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow