Sometimes a blog post is better than memory.
mkdir -p src/w3af cd src/w3af git clone --depth 1 https://github.com/andresriancho/w3af.git . virtualenv venv # It does seem to be necessary to do this rather than just using the bins. ./venv/bin/activate ./w3af_console # This is generated by the consolescript . /tmp/w3af_dependency_install.sh
Next we’ll create a usable profile to spider a website and try to xss it.
./venv/bin/python ./w3af_console w3af>>> plugins w3af/plugins>>> list crawl (snip) w3af/plugins>>> crawl web_spider w3af/plugins>>> audit xss w3af>>> profiles w3af/profiles>>> save_as spider-xss Profile saved.
(To disable a plugin later use
type !plugin, e.g.
When you next use w3af you can run
profile use spider-xss.
Now exploit some things:
w3af>>> target set target https://site-you-own.example.com The configuration has been saved. w3af>>> w3af>>> start New URL found by web_spider plugin: "https://site-you-own.example.com/" (...)
Pressing enter will give you a quick status on what it’s doing.
Note that in my version the console will hang if you haven’t yet set a target which will mean you have to reconfigure everything so take care to avoid this.
Wait a very long time and you’ll get a report. Any found exploits will be printed out in real time.
It’s a good idea to test your profile like this:
w3af>>> plugins audit xss w3af>>> plugins crawl web_spider w3af>>> target set target http://localhost/inject-me.php w3af>>> plugins crawl config web_spider w3af/plugins/crawl/config:web_spider>>> set only_forward True w3af/plugins/crawl/config:web_spider>>> back The configuration has been saved. w3af>>> start
Here’s the exploitable script:
<html> <head> </head> <body> <?php echo @$_GET['text']; ?> <form method="GET"> <input type="text" name="text"> <input type="submit" value="go"> </form>
w3af>>> start New URL found by web_spider plugin: "http://localhost/inject-me.php" A Cross Site Scripting vulnerability was found at: "http://localhost/inject-me.php", using HTTP method GET. The sent data was: "text=" The modified parameter was "text". This vulnerability was found in the request with id 37. Found 1 URLs and 2 different injections points. The URL list is: - http://localhost/inject-me.php The list of fuzzable requests is: - Method: GET | http://localhost/inject-me.php/inject-me.php - Method: GET | http://localhost/inject-me.php/inject-me.php | URL encoded form: (text) Scan finished in 1 second. Stopping the core...
The output plugins are also useful.
plugins output text_file output config text_file set output_file output-w3af.txt set verbose True back
The above will produce more greppable output. Useful if you’re spidering a whole site with thousands of pages.
$ grep ' vulnerability\]' output-w3af.txt [Wed Aug 10 14:09:36 2016 - vulnerability] A Cross Site Scripting vulnerability was found at: "http://localhost/inject-me.php", using HTTP method GET. The sent data was: "text=" The modified parameter was "text". This vulnerability was found in the request with id 37.
Not sure why it tells you that the sent data was “text=”. It looks from the request log like it actually sent something else entirely. I think the problem may be that it’s looking for the string
=" in the document.
So over all I’m not too impressed with the xss detection. There are far to many false positives, the UI is rather buggy, and it’s difficult to understand exactly why it reports empty strings as injections. Hopefully someone will find this braindump more useful though.