

Closer look at IIScan - Traces a web scan leaves in your logs - j_lagof
http://blog.sucuri.net/2010/01/closer-look-at-iiscan.html

======
dan_sim
Is this me or I would expect a scan to be more complete than that.

~~~
ddbb
I was going to say the same thing...

I expected a scan to go through the site looking at every possible bug, not
just that 200/300 checks.

Looking at the full disclosure archives, lots of users mentioned that it is
actually common for web scans to be that simple. I guess the technology is
still new and most people don't care (as long as the result is a BIG GREEN -
no bugs found).

~~~
rdj
Scanners cannot look for every possible bug. They can however, look for
_known_ bugs. And that's what most attempt to accomplish.

In a nutshell: The scanner looks for known files (thus you see a lot of
404's). If it finds these files, it may try another check (some query string
or POST) to determine if it is the vulnerable version. The scanner then tries
to inject some javascript for the XSS. If it sees the injected string in the
body of the response, it may start modifiying the request until the javascript
is actually valid, resulting in an alert window. If it doesn't see a response
weith the injected code, the test is complete, move to the next. Finally, the
scanner may look for backup files by taking the list of pages from the crawled
site and appending things like .bak, .orig, etc.

If you were to take this scanner and run it against a site that returns status
code 200 for every request, and echo's back the query string, I suspect you
will see a more extensive list of checks that are performed.

~~~
dan_sim
What I would expect from this kind of scanner is that it takes every form on
my website and try XSS with the actual parameters that I use, not just
parameters that I probably would use.

~~~
rdj
That seems like a reasonable expectation. I guess I need to look at this
article and scanner a little closer before I comment on what this particular
tool does (or doesn't).

