Closer look at IIScan - Traces a web scan leaves in your logs(blog.sucuri.net)
blog.sucuri.net
Closer look at IIScan - Traces a web scan leaves in your logs
http://blog.sucuri.net/2010/01/closer-look-at-iiscan.html
1 comments
Is this me or I would expect a scan to be more complete than that.
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).
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).
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.
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.
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.
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).