They all catch different things.

I use the paid version of BurpSuite primarily.  Then I use skipfish and
arachni.

Netsparker is good, bur pricey.

W3AF is good when it works, but I've had some very annoying crashes with
it... and a crash after running for eight hours is very irritating.

-Josh More

On Mon, May 2, 2011 at 9:22 PM, 孙松柏 lukesun629@gmail.com wrote:

What do you mean? netsparker is not for free...

--- El mar, 3/5/11, jacorream@gmail.com jacorream@gmail.com escribió:

Best for what?
I'd recommend to check out this research:
http://sectooladdict.blogspot.com/2010/12/web-application-scanner-benchmark.html

More stuff on scanner comparison efforts could be found here:
http://andrewpetukhov.blogspot.com/2011/01/web-application-scanner-comparison.html

Best of luck!

~Andrew

5/3/11 6:22 AM, 孙松柏 пишет:

On Mon, May 2, 2011 at 7:22 PM, 孙松柏 lukesun629@gmail.com wrote:

The WebUI is nice. Written in Ruby and requires Rails. Best installed
using RVM. Doesn't really stand out yet otherwise.

You can take the lists from tools like JBroFuzz, fuzzdb, DirBuster,
and admin-scan.py -- combine them (sort + uniq) -- and then run them
through a single-pane-of-glass tool like Burp Suite Professional (or
Fiddler, et al) or a command-line tool such as dirb. This is a very
common penetration-testing tactic.

There is a Google Chrome/Chromium extension/app. This tool is best
used when customized internally, which requires heavy knowledge of
Javascript, especially as a browser/application driver (which is a
rare skillset to have).

This tool is mentioned along with others in the book, "Backtrack 4:
Assuring Security by Penetration Testing". There are some clear
examples of running the tool as well as anecdotes about its
usefulness. I highly encourage you to check out this book for other
non-obvious reasons that will perhaps become obvious after you read
it.

Great tool, but works only in certain situations. Probably a good tool
to combine with other tools that can rewrite headers and perform
passive analysis, such as Burp Suite Professional or Fiddler with
Casaba Watcher. I especially like how Wapiti can specify POST-only
attacks. It's written in Python.

This is one of the best tools because it stands alone in its support
of key innovations in webappsec technology. It has the best
open-source crawler, as seen from the wivet.googlecode.com results.
Many people think that W3AF is all Python, but it's really a mix of
languages -- especially not that it's founders and developers work for
Rapid7 (classically known to be a Ruby appdev shop). My favorite
features of W3AF are the spiderMan discovery plugin, all of the grep
plugins (which can be imported into Burp via the Burp Python extension
API), and some of the attack/evasion plugins. The emailReport plugin
is handy, the XML output is excellent (and it has its own XSD), and
the Export Request Tool feature is one of my favorites -- allowing
export of attacks to various languages, including HTML, Ajax, Python,
and Ruby (note that these are best when imported into HtmlFixture in
FitNesse, or used on a build/CI server as integration tests).

It's written in C and super-fast, with some really interesting
capabilities. The crawler isn't bad, but it's not quite as good as
W3AF (or some commercial tools). I like the "-D" flag the most, and
the ability for this tool to go through those
JBroFuzz/fuzzdb/admin-scan.py/DirBuster lists is unmatched --
especially given its other capabilities to lean on dictionaries for
predictable-resource-location attacks.

Terrible performance, scalability, and usability. I don't believe the
author promotes its usage anymore.

I've always liked this tool, but it's a bit of a project; almost
academic. The author went on to do more with Python, such as the
BlackSheep browser that performs security testing.

I'm not sure this is supported anymore -- it was replaced by Suru many
years ago, which itself has not been updated in some time. Many of the
search/dorking capabilities are replaced by newer tools such as
SeachDiggity.

==
My personal recommendation is to learn the concepts in Tamper Data and
to build on webappsec knowledge in order to write your own scanner(s).
The ones that you build for yourself will always be "the best",
because you're the customer (and you know yourself and your testing
capabilities, especially test case design and test case organization
along with time management and other principles).

The commercial tools are a waste of time, money, and I'd like to say
many other bad things about them. However, both Netsparker and
WebInspect have crawlers and manual modes that can be useful in rare
circumstances -- so I add them to my toolchain, which is usually
dominated by Tamper Data, Burp Suite Professional, W3AF, and Fiddler
with Casaba Watcher and x5s. However, I find many other tools useful
at times.

It didn't occur to me before but I think you're asking the wrong question.
You're working backwards...you first need to figure out what you want
to do and then find a scanner that does those things well.

So...what are you looking for?

On 05/03/2011 03:22 AM, 孙松柏 wrote:

Has anyone used the free version of Acunetix lately? The free version
only scans for XSS but version 7 does not seem to identify ANY XSS
vulnerabilities. I still have version 6.5 and it finds many XSS in my
test app, but version 7 finds zero.

On 5/3/11 2:14 PM, Andre Gironda wrote:

--
Steve Lockwood
LochNET Systems, LLC.
Mobile: (727) 512-8408
Email: steve@lochnetsystems.com
http://www.lochnetsystems.com

I agree with  'the ones that you build for yourself will always be
"the best" '  :)
(I find most to be useless for my needs).

Hi,

I would also recommend WATOBO (Web Application Toolbox).
WATOBO is focused on manual pentesting but has also some automated
scanning capabilities, e.g. SQL, XSS,..
It acts as a local proxy, similar to Webscarab, Paros or BurpSuite.

The most important advantages are:

• Testing of CSRF protected webapps!
• It has Session Management capabilities! You can define login scripts
  as well as logout signatures. So you don’t have to login manually each
  time you get logged out.
• Can perform vulnerability checks out of the box.
• It supports Inline De-/Encoding, so you don’t have to copy strings to
  a transcoder and back again. Just do it inside the request/response
  window with a simple mouse click.
• It has smart filter functions, so you can find and navigate to the
  most interesting parts of the application easily.
• It's written in (FX)Ruby and enables you to define your own checks
• WATOBO is free software ( licensed under the GNU General Public
  License Version 2)

More information you can find at the project page
http://watobo.sourceforge.net

There's also a very good manual including tutorials here:
http://www.aldeid.com/index.php/Watobo - Thanks to Sebastien!

regards,

andy

Am 03.05.2011 04:22, schrieb 孙松柏:

On Tue, May 3, 2011 at 12:06 PM, Arian J. Evans
arian.evans@anachronic.com wrote:

There appears to be some confusion about what I recommended to the
list, so I'm going to take the time to clarify it here. It wasn't
meant to be humorous at all -- or provide answers to anything except
for the original author's question.

I didn't say "replace web app scanners with Tamper Data", nor did I
imply that notion. I said to learn the concepts of webappsec using
Tamper Data -- i.e. in a lab setting, on your own hours/time, and at
your own learning pace.

The concept that application developers be capable of writing their
own test code, including a full test harness is not a new concept.
Developers have been applying these principles for over 40 years. Full
knowledge access is a general requirement for testing, which involves
a "whole system": source code, along with the build/compile
information, and the runtime. The capability to create code-aware
instrumentation available at runtime has been discussed in the
literature in early versions of Knuth's The Art of Computer
Programming -- long before the web (and most compilers) ever existed.

Crawlers are sometimes a good way to enhance test knowledge, but they
are not good at running test cases against a bespoke app. App scanners
usually have a crawling component, but they also have results-tables,
typically data-driven, and implemented in an HTTP state machine and/or
HTML/Javascript/etc parsing engine(s). This is typically known as a
protocol (HTTP) or application (DOM and plugins) driver.

While a quality front-end to an protocol driver can be found in Burp
Suite Professional -- it lacks the capability of a full browser
(Fiddler OTOH can hook into the browser's network traffic at a lower
interface -- in order to exist outside of the browser). This doesn't
make Burp Suite Professional useless by any means, but it does require
the same level-of-effort in terms of context provisioning that Fiddler
(or any tool) would. Typically, this is programmatically affected
using Burp or Fiddler extensions/plugins. This is where developing
your own scanner comes into play, especially useful for large and/or
bespoke applications. I don't know anyone outside of scanner vendors
(including SaaS scanner vendors) who don't promote this method -- and
I believe the scanner vendors only do so because they want to sell
more products.

Fortunately, for the people who don't want to build a scanner and do
not have large or bespoke apps -- they can utilize W3AF as suggested
by SAFEcode guidance. There are additional benefits to using W3AF, but
these typically require more than a point-and-shoot configuration
(note: it helps to have HTML, Ajax, Python, and Ruby knowledge at a
basic level -- as well as some basic Linux or Windows command line
skills). If you really want a point-and-shoot solution, then Arachni
will probably be a good fit.

Not one of them is best at everything. Each is different. Use as many as
possible (to a degree).

Ryan Dewhurst

blog www.ethicalhack3r.co.uk
projects www.dvwa.co.uk | www.webwordcount.com
twitter www.twitter.com/ethicalhack3r

On Wed, May 4, 2011 at 5:42 AM, dave b db.pub.mail@gmail.com wrote:

I'm sorry, but I have to disagree.

"Use as many as possible (to a degree)." was my original quote.

I'm not saying use every scanner at your disposal, pick 3 or 4 which you
find work best for you. Never rely on just one automated blackbox web
application scanner.

It is true in a commercial environment you are restricted by time and scope.
But nothing is stopping you from firing two scanners at a time. You will
spend slightly more time validating the scanner results but the benefits
outweigh this by a long shot. You still only have to write one report from
the results.

"What if you find 10. Vulns in Webinspect, 5 in AppScan and 3 in Acunetix"

Then you have 18 potential vulnerabilities to investigate, if they are all
unique, some (most) will probably be the same vulnerability, but one or two
may not be.

For example:
I always run Nikto on every test, as well as, Dirbuster as well as w3af, as
well as a local proxy tool and lots of other tools which aid me in my work.

And of course, don't ever just rely on automated blackbox scanners.

My original point was, use whatever tools and as many tools that are going
to aid you in finding and exploiting bugs (vulnerabilities).

Ryan Dewhurst

blog www.ethicalhack3r.co.uk
projects www.dvwa.co.uk | www.webwordcount.com
twitter www.twitter.com/ethicalhack3r

On Wed, May 4, 2011 at 6:40 PM, neza0x@gmail.com wrote:

On Wed, May 4, 2011 at 10:40 AM,  neza0x@gmail.com wrote:

This is not true at all. There are many ways to aggregate/consolidate
scans and data from scans. Burp Suite Professional, along with Buby,
provide this capability in their combined API through the "send to
[rprogram]" interface. It's certainly possible to generate a single
report -- and The Dradis Framework provides hooks into HTML, MS Word,
PDF generation, Mediawiki, et al. This would only serve to make the
data MORE consistent and valuable.

You obviously need to work better with app developers if they are
directing this language towards you.

The manual modes in WebInspect and Netsparker mimic what is capable
with Burp Suite Professional Scanner (including and especially the
passive scanner). However, free tools such as W3AF, Casaba Watcher,
and Watobo also do this. You could always use a browser macro
language/framework (e.g. iMacros, Selenium IDE, Selenium-RC/WebDriver,
Geb, Watir/WatiN/Watij, etc) do drive the browser through a passive,
local web proxy. This may give better results depending on the target
app. It even works well with Tamper Data since this add-on maintains a
list of URIs, parameters, headers in addition to timestamps (all
available from XML). I'm sure you will find that this methodology is
better than using an app scanner. It's not as scaleable today, but it
is more viable in the long-term. Have you seen the hardware
requirements for WI/AMP though? Talk about scalability issues...

"Nothing is stopping you two firing two scanners at the same time",
Let me give you 3 examples of someone stopping me/all:

1. In corporate environments you cannot only download any tool (specially freeware ones) and run it, those need to be  approved tools or at least it should be that away, I cannot imagine a Company allowing its users to download/run anything they want.

2. Dedicated scanners: some companies have dedicated servers to install/run scans, by adding a new tool, you might want to add a new server if you want to fire up two scans at the same time. Money wise.

3. Scanners run in a Corporate environment must be allowed by IDS/IPS, WAF, so on to go through and reach the target, as you know, every scanner has a http header that identifies it with the Network, with your approach, the Networking Team, will need to allow different scanners in the network, by the way, also those could be the ones from malicious guys.

Bottom line, it depends on your environment, for Corporate ones, at least in the three 500-Fortune Companies I have worked for, does not work that way.
Sent via BlackBerry from Danux Network

-----Original Message-----
From: Ryan Dewhurst ryandewhurst@gmail.com
Date: Wed, 4 May 2011 18:54:46
To: neza0x@gmail.com
Cc: websecurity-bounces@lists.webappsec.org; dave bdb.pub.mail@gmail.com; websecurity@webappsec.org
Subject: Re: [WEB SECURITY] which is the best web application vulnerabilityscanner

I'm sorry, but I have to disagree.

"Use as many as possible (to a degree)." was my original quote.

I'm not saying use every scanner at your disposal, pick 3 or 4 which you
find work best for you. Never rely on just one automated blackbox web
application scanner.

It is true in a commercial environment you are restricted by time and scope.
But nothing is stopping you from firing two scanners at a time. You will
spend slightly more time validating the scanner results but the benefits
outweigh this by a long shot. You still only have to write one report from
the results.

"What if you find 10. Vulns in Webinspect, 5 in AppScan and 3 in Acunetix"

Then you have 18 potential vulnerabilities to investigate, if they are all
unique, some (most) will probably be the same vulnerability, but one or two
may not be.

For example:
I always run Nikto on every test, as well as, Dirbuster as well as w3af, as
well as a local proxy tool and lots of other tools which aid me in my work.

And of course, don't ever just rely on automated blackbox scanners.

My original point was, use whatever tools and as many tools that are going
to aid you in finding and exploiting bugs (vulnerabilities).

Ryan Dewhurst

blog www.ethicalhack3r.co.uk
projects www.dvwa.co.uk | www.webwordcount.com
twitter www.twitter.com/ethicalhack3r

On Wed, May 4, 2011 at 6:40 PM, neza0x@gmail.com wrote:

responding to your statements below:

None of the scanners provide meaningful depth/coverage
run in point-and-shoot mode. In addition, their tests will
stomp all over each other and conflict if run concurrently.

So, the "run a bunch of different scanners" and "you
can run them in parallel" advice does not work beyond
testing simple, unauth brochureware.

This is despite the obvious fact that few people have
time to effectively run one DAST or SAST scanner
on all their apps when they need to/when their code
changes. Adding more tools will not help, but I digress.

I can see the more limited use-case where a consultant
on a pen-test engagement with enough time may choose
to run more than one tool. But that doesn't translate over
to corporate application security.

Arian Evans
Software Security Scanning Stuff

On Wed, May 4, 2011 at 10:54 AM, Ryan Dewhurst ryandewhurst@gmail.com wrote: