[WEB SECURITY] which is the best web application vulnerabilityscanner
ryandewhurst at gmail.com
Wed May 4 17:44:18 EDT 2011
I've never had any problems running parallel scans, maybe I have just been
lucky. By 'parallel' I mean running two scanners at the same time against
the same application, not necessarily running the scanners from the same
Not disagreeing here, just generally interested...
Shouldn't every injection payload have a unique identifier associated with
it? Making it distinguishable between scanners?!
What do you mean by 'wrangle responses'? Every HTTP request/response goes
back to the scanner that initiated the TCP connection.
What do you mean by 'persistent fields'? I your thinking persistent XSS type
injection, again, each payload should be uniquely identifiable to the
scanner that sent it. Example: <script>alert(Scanner1)</script>,
State should not be a problem?! Give each scanner a different user.
Threading?! On the client?!
My original 'run multiple scanners' comment meant running, Nikto alongside,
DirBuster for example. Not Netsparker and Acunetix. But even though I still
don't see that much of a problem.
To be honest, I need to do some research in order to verify my assumptions,
but my initial thoughts are that there should be no problems.
projects www.dvwa.co.uk | www.webwordcount.com
On Wed, May 4, 2011 at 9:35 PM, Arian J. Evans
<arian.evans at anachronic.com>wrote:
> "Nothing is stopping you two firing two scanners at the same time"
> As someone who has tried this many, many times I can tell you with
> conviction it just doesn't work. Anyone who has tried this with any
> meaningful scanner configuration knows this won't work for obvious
> The most obvious reason this "run multiple scanners in parallel"
> doesn't work is that their test injections will stomp all over each
> other and also wrangle responses. Especially in persistent fields.
> You will get both false positives and false negatives.
> Then we get to scanner state and timeout issues, and threading issues.
> But I will stop my list there unless you want me to go on.
> I simply share this wisdom to help any new folks on this list avoid
> the headache that will ensure should they download and fire up 2-4
> scanners in parallel on websites with lots of persistent data inputs.
> For unauth brochureware, sure, have at it, at least until the app falls
> Arian Evans
> Software Security Scanner Singularities
> On Wed, May 4, 2011 at 12:55 PM, Michal Zalewski <lcamtuf at coredump.cx>
> >> 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.
> > If corporate "security" policies prevent the actual security team from
> > leveraging security testing tools, then... you probably have a problem
> > more significant than selecting the right tool ;-)
> >> 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.
> > Ditto if you whitelist access to your systems based on HTTP header layout
> > /mz
> > _______________________________________________
> > The Web Security Mailing List
> > WebSecurity RSS Feed
> > http://www.webappsec.org/rss/websecurity.rss
> > Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> > WASC on Twitter
> > http://twitter.com/wascupdates
> > websecurity at lists.webappsec.org
> The Web Security Mailing List
> WebSecurity RSS Feed
> Join WASC on LinkedIn http://www.linkedin.com/e/gis/83336/4B20E4374DBA
> WASC on Twitter
> websecurity at lists.webappsec.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the websecurity