Understanding Wapiti results

I ran Wapiti on my webserver. I dump the database before and after, deleted the last line which开发者_开发问答 is the timestamp and found both files have me the same hash value so i know the database hasnt been changed.

But according to the report i failed a number of test. And this is the data in the info

500 HTTP Error code.
Internal Server Error. The server encountered an unexpected condition which prevented it from fulfilling the request.

    * World Wide Web Consortium: HTTP/1.1 Status Code Definitions
    * Wikipedia: List of HTTP status codes 

It appears each and every one of these are caused by ill-formed strings that ASP.NET does not like (note i use a debian machine with xsp to host. It works well).

Should i not care what the generated reports say? should i only check if anything was changed or anything was corrupted by manually looking through the pages?

    SQL Injection (1)   Blind SQL Injection (2)     File Handling (3)   Cross Site Scripting (4)    CRLF (5)    Commands execution (6)  Resource consumption (7)    Htaccess Bypass (8)     Backup file (9)     Potentially dangerous file (10) 
High    14  14  13  0   0   14  0   0   0   0
Medium  0   0   0   0   0   0   0   0   0   0
Low     0   0   0   0   0   0   0   0   0   0

The database restoration is a very good idea. You do need a populated database to get proper code coverage. You also need to make sure that error reporting is enabled, nasty input must cause a sql error or wapiti might not find it. Wapiti does have blind sql injection testing, but its not as accurate.

I would look at the normal output from a ./wapiti.py http://yourdomain.com, this will list all of the vulnerabilities found and then you can patch them. After you do your first round of patching, re-run wapiti to make sure the patches work. The reports it generates are mostly meant for managers and the like who don't know what vulnerability is, they just want to know if they are safe or not. SQL Injection probably won't corrupt the database or any of the pages, Wapiti does do stored xss testing and this will corrupt a page, but if you are restoring the database then everything should be fine.

If you want to test for sql injection, I recommend using a tool which is particularly good at it. Namely:

sqlmap

http://sqlmap.sourceforge.net/

Note, the debian repository version is horribly out of date.