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: