Penetration-testing-tools

Es gibt ein paar verschiedene Richtungen gehen kann mit automatisierten Test-tools für web-Anwendungen.

Zunächst gibt es die kommerzielle web-Scanner, von denen HP WebInspect und Rational AppScan sind die beiden beliebtesten. Dies sind die "all-in-one", "fire-and-forget" - tools, die Sie herunterladen und installieren auf einem internen Windows-desktop und geben Sie eine URL-spider Ihre Website, Suche nach bekannten Schwachstellen (also die Dinge, die Treffer Bugtraq), und einer Sonde für cross-site-scripting-und SQL-injection-Schwachstellen.

Zweitens gibt es die source-code-scan-tools, von denen Coverity und Stärken sind wohl die beiden bekanntesten. Dies sind die Werkzeuge, die Sie installieren auf einem Entwickler-desktop, um Ihre Java-oder C# - source-code und suchen Sie nach bekannten Muster der unsicheren code, wie mangelnde überprüfung der Eingaben.

Schließlich gibt es die - penetration-test-tools. Bei weitem die beliebteste web-app penetration testing tool unter Sicherheitsexperten ist Burp Suite, die Sie hier finden können in http://www.portswigger.net/proxy. Andere sind Spike Proxy und OWASP WebScarab. Wieder, installieren Sie diese auf einem internen Windows-desktop. Es wird laufen wie ein HTTP-proxy, und Sie werden mit Ihrem browser an. Verwenden Sie Ihre Anwendungen wie ein normaler user wäre, während es Aufzeichnungen Ihrer Aktionen. Sie können dann gehen Sie zurück, um jede einzelne Seite oder HTTP-Aktion und Sonde für die Sicherheit Probleme.

In einem komplexen Umfeld, und vor allem, wenn Sie erwägen, etwas DIY, ich empfehle das penetration-testing-tools. Ist hier, warum:

Kommerzielle web-Scanner bieten eine Menge "Breite", zusammen mit ausgezeichneten Berichterstattung. Allerdings:

• Neigen Sie dazu, zu miss Dinge, da jede Anwendung unterschiedlich ist.

• Sind Sie teuer (WebInspect beginnt in den 10 ' s von tausenden).

• Sind Sie zahlen für Sachen, die Sie nicht brauchen (wie die Datenbanken der bekannten schlechten CGIs aus den 90er Jahren).

• Dass Sie schwer zu passen.

• Können Sie produzieren laute Ergebnisse.

Source code Scanner sind gründlicher als web-Scanner. Allerdings:

• Sind Sie sogar teurer als der web-Scanner.

• Benötigen Sie source-code zu bedienen.

• Effektiv zu sein, benötigen Sie Häufig Sie, um Anmerkungen in Ihren source-code (zum Beispiel, zu pick out input pathways).

• Dazu neigen, Fehlalarme zu erzeugen.

Sowohl kommerzielle Scanner und source-code-Scanner haben eine schlechte Angewohnheit, immer shelfware. Schlimmer noch, auch wenn Sie arbeiten, Ihre Kosten sind vergleichbar mit immer 1 oder 2 ganze Anwendungen geprüft von einem Berater, wenn Sie Vertrauen in Ihre Berater, Sie werden garantiert to get bessere Ergebnisse von Ihnen als von den tools.

Penetration-testing-tools haben Nachteile auch:

• Sind Sie viel schwieriger zu benutzen als fire-and-forget-kommerziellen Scannern.

• Übernehmen Sie einige know-how in web application vulnerabilities --- Sie müssen wissen, was Sie suchen.

• Sie produzieren wenig oder keine formale Berichterstattung.

Auf der anderen Seite:

• Sind Sie viel, viel billiger --- der beste von der Menge, Burp Suite, kostet nur 99EU, und hat eine Kostenlose version.

• Sie sind einfach zu passen, und fügen Sie eine Test-workflow.

• Sind Sie viel besser zu helfen, Sie "kennen" Ihre Anwendungen von innen.

Hier ist etwas, was Sie tun würde, mit einer pen-test-tool für eine einfache Webanwendung:

1. Sich in der Anwendung über den proxy

2. Erstellen Sie eine "Hitliste" der wichtigsten funktionalen Bereiche der Anwendung, und übung jedes mal.

3. Verwenden Sie die "spider" - Werkzeug in der pen-test-Anwendung, um alle Seiten finden und Handlungen und Prozeduren in der Anwendung.

4. Für jede dynamische Seite und jedes HTML-Formular die Spinne deckt, verwenden Sie die "fuzzer" - tool (Rülpsen nennt es ein "Eindringling") zur Ausübung jeder parameter mit ungültigen Eingaben. Die meisten Fuzzer kommen mit basic-test-strings, die einschließen:

   • SQL-Metazeichen

   • HTML/Javascript entweicht und Metazeichen

   • Internationalisierte Varianten dieser zu entziehen input Filter

   • Bekannten Standard-Formular-Feldnamen und Werte

   • Bekannten directory-Namen, Datei-Namen und-handler Verben

5. Verbringen mehrere Stunden filtern der resultierenden Fehler (ein typischer fuzz-Lauf für ein Formular generiert möglicherweise 1000 von Ihnen) auf der Suche nach verdächtigen Antworten.

Dies ist eine arbeitsintensive, "bare-metal" - Ansatz. Aber, wenn Ihr Unternehmen besitzt die eigentlichen Anwendungen, die bare-metal-Ansatz zahlt sich aus, denn Sie können es verwenden, um zu bauen, regression-test-Suiten, die laufen wie ein Uhrwerk bei jedem dev-Zyklus für jede app. Dies ist ein Gewinn für eine Reihe von Gründen:

• Ihre Sicherheit testen wird eine vorhersagbare Menge an Zeit und Ressourcen für jede Anwendung, die Ihnen ermöglicht, budget und triage.

• Ihr team erhalten maximal genaue Ergebnisse, da Sie Ihre Tests sein wird, abgestimmt auf Ihre Anwendungen.

• Es wird weniger Kosten, als es bei kommerziellen Scannern und weniger als Berater.

Natürlich, wenn Sie diesen Weg gehen, du bist im Grunde drehen sich in eine Sicherheits-Berater für Ihr Unternehmen. Ich glaube nicht, dass das eine schlechte Sache, wenn Sie nicht wollen, dass know-how, oder Fortify WebInspect ist nicht zu helfen, Sie viel sowieso.

McAfee Secure ist auch keine Lösung. Den service, den Sie bieten ist ein Witz.

Siehe unten:

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

Skipfish, w3af, arachni, ratproxy, ZAP, WebScarab : alle kostenlos und sehr gut ist IMO

Werfen Sie einen Blick auf Rational App Scan (hieß früher Watchfire). Seine nicht kostenlos, aber hat eine schöne Benutzeroberfläche, tot ist mächtig, generiert Berichte (individuelle und gegen standard-compliance-frameworks wie Basel2) und ich glaube, Sie können ein Skript in Ihrem CI erstellen.

Für diese Art von Tests, die Sie wirklich wollen, zu betrachten, die irgendeine Art von fuzz tester. SPIKE Proxy ist einer von ein paar fuzz-Tester für web-apps. Es ist open source und in Python geschrieben. Ich glaube, es gibt ein paar videos von BlackHat oder DefCON auf mit SPIKE draußen irgendwo, aber ich bin habend Schwierigkeit der Suche nach Ihnen.

Gibt es ein paar high-end-Profi-software-Pakete, die web-app testen und vieles mehr. Eines der beliebtesten tools wäre CoreImpact

Wenn Sie planen, gehen durch die mit dem Pen-Tests auf Ihre eigenen, empfehle ich Ihnen zu Lesen, die durch viel von der OWASP Projekt-Dokumentation. Speziell der OWASP Application Security Verification und Test/Entwicklung-guides. Die Denkweise, die Sie brauchen, um gründlich testen Sie Ihre Anwendung ist ein wenig anders als Ihre normale Entwicklung der Denkweise (nicht, dass es anders sein SOLLTE, aber es normalerweise der Fall ist).

Ich weiß, Sie fragte, speziell über pentesting-tools, aber da diese wurden ausführlich beantwortet (normalerweise gehe ich mit einer Mischung von AppScan und ausgebildet pentester), ich denke, es ist wichtig zu betonen, dass pentesting ist nicht der einzige Weg, zu prüfen, "für Sicherheitslücken", und das ist oft nicht der effektivste.

Source-code-review-tools können Sie mit viel besseren Einblick in Ihre Codebasis, und finden Sie viele Schwächen, die pentesting nicht.

Dazu gehören Stärken und OunceLabs (teuer und für viele Sprachen), VisualStudio.NET CodeAnalysis (für .NET und C++, kostenlos mit VSTS, anständig, aber nicht groß), OWASP der ABLAUF für Java (kostenlos, anständige nicht groß), CheckMarx (nicht Billig, fantastisches tool für .NET und Java, aber hoher Aufwand), und viele mehr.

Einen wichtigen Punkt müssen Sie beachten - die (meisten) automatisierte tools finden nicht alle Schwachstellen, die nicht einmal in der Nähe. Sie können erwarten, dass die automatisierten tools, um etwa 35-40% der secbugs, die gefunden werden würde, der von einem professionellen pentester; das gleiche gilt für automatisierte vs. manuelle source-code-review.

Und natürlich eine richtige SDLC (Security Development Lifecycle), einschließlich " Threat Modeling, Design Review, etc, wird noch mehr helfen...