Today, I finally looked at Wapiti, which is a web application vulnerability scanner. It operates on a black box basis (i.e. it doesn’t see the underlying PHP/ASP/Java source code), and effectively tries to ‘break’ any forms on a page.
In order to get it to do anything useful, you’ll probably need to provide it with a cookie file to use. Unfortunately, I couldn’t originally get the provided ‘getcookie.py’ file to work, as the application in question just posted the login form details to ” (i.e. <form action=” method=’post’>)…. after a bit of hacking I fixed this, but it took some time.
Installation is relatively easy – download the .zip file, extract it and change directory into it (e.g. cd wapiti-2.0.X)
Anyway, given we have “webapp” installed at http://orange/webapp, and we wish to test it, we might do something like the following :
- cd src/net
- python getcookie.py ~/cookie.txt http://orange/webapp/login.php
- Enter username/password etc as required to complete the login form
- Script exists, check the contents of ~/cookie.txt – it will look something like :
#LWP-Cookies-2.0
Set-Cookie3: PHPSESSID=3d20841af5de43c718732d80e5d78fe3; path=”/”; domain=”orange”; path_spec; expires=”2010-01-04 22:42:47Z”; version=0
Now we can use wapiti to test any urls ‘behind’ the login screen (as it were) :
wapiti http://orange/webapp/search.php –cookie ~/cookie.txt -v 2 -o ~/report -x http://orange/webapp/logout.php
(We need to exclude the logout page, else our session will get destroyed when wapiti spiders that page…)
Depending on how good the application is, you may see output like :
Found permament XSS in http://orange/webapp/search.php
attacked by http://orange/webapp/search.php?area=on&client_id=on&county=on with fields county=crzbl79tqr&status=x57cjl7m14&website=vk59qqbgmp&name=<script>alert(’11byq04xd1′)</script>&client_id=on®ion=on
and similar for the other vulnerabilities.
If I point my web browser at file:///home/david/report I’ll see a nice HTML report listing the vulnerabilites and so on – similar to the below…
Wapiti appears to detect:
- SQL Injection holes
- Cross Site Scripting (XSS) holes
- File inclusion (local/remote)
- Command execution vulnerabilities
- and others
I’m a bit annoyed I’ve only found this tool now – but also glad I’ve finally found it. I’ve been looking for something that can pick up XSS holes for ages (SQL Injection stuff I could already test using SQLMap, and ensuring I only ever used prepared statements).
Update (July 2011) – cookie file format has changed to xml –
<?xml version="1.0" encoding="UTF-8"?> <cookies> <domain name="uk"> <domain name="co"> <domain name="palepurple"> <domain name="david"> <cookie name="PHPSESSID" path="/" value="vmabdv5giph334aq33vb0add67" version="0"/> <cookie name="globdisc" path="/" value="yes" version="0"/> </domain> </domain> </domain> </domain> </cookies>