In these 2 articles, I will be detailing the new functionality introduced in Acunetix WVS version 9.5.
An important update introduced in the new version of Acunetix WVS is full JSON and XML support. If you are scanning a web application that is exchanging data using the JSON or XML formats, WVS can now split the data into individual parts and manipulate each part individually, and will check each part for vulnerabilities.
Here is an example web application that performs user authentication via AJAX, sending the data formatted as JSON. Snippets of the code are displayed below:
The JavaScript code sends the username and password provided by the user to the web server encoded using JSON. If the username and password are correct, the web server will set a cookie and the browser will redirect the authenticated user to the main page.
Using DeepScan technology, the Crawler can detect the AJAX request and prepare an input scheme for the scanner. In addtion, we can now identify that this AJAX request contains data that is formatted as JSON and split the data into individual parts that will be manipulated individually. So, the crawler will generate a new type of input scheme, a JSON input scheme.
The scanner then proceeds to test each input schemes discovered by the crawler for vulnerabilities.
In our example code, while manipulating the JSON scheme, Acunetix finds an SQL injection vulnerability on the JSON input password and is capable of extracting data from the database. The alert produced for such a vulnerability is shown in the screenshot. If the POST request is not tested as a JSON entity no vulnerabilities would be found.
The full HTTP request is:
POST /json_decode/login.php HTTP/1.1
Content-Type: application/json
Content-Length: 299
Host: test
Connection: Keep-alive
Accept-Encoding: gzip,deflate
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36
Accept: */*
{"password":"'and(select 1 from(select count(*),concat((select concat(CHAR(52),CHAR(67),CHAR(117),CHAR(97),CHAR(110),CHAR(65),CHAR(72),CHAR(86),CHAR(70),CHAR(105),CHAR(50)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'","username":"e"}
The new version is even smarter. It can detect and test the JSON/XML data formats even if they are Base64 encoded. Let’s use another example and see how it works. If the crawler finds this link:
login.php?json=eyJwYXNzd29yZCI6InRlc3QiLCJ1c2VybmFtZSI6InRlc3QifQ%3d%3d
It will first perform URL decoding on the parameter value and the string now looks like:
login.php?json=eyJwYXNzd29yZCI6InRlc3QiLCJ1c2VybmFtZSI6InRlc3QifQ==
The value ends with the == characters, that’s usually a padding for Base64 encoded string.
So, the crawler will continue and try to see of the parameter value it’s encoded Base64.
eyJwYXNzd29yZCI6InRlc3QiLCJ1c2VybmFtZSI6InRlc3QifQ== is decoded to {“password”:”test”,”username”:”test”}, so the decoded link looks as follows:
login.php?json={“password”:”test”,”username”:”test”}
The crawler is able to identify that this is a JSON formatted request that is being Base64 encoded. The crawler will make a JSON scheme and mark it as Base64 encoded, causing the scanner to manipulate the data using JSON and encode it using Base64.
As a result, the scanner can find vulnerabilities from the manipulation of this scheme.
An SQL injection alert is reported for this link and the scanner was able to extract data from the database. The full URL is:
login.php?json=eyJwYXNzd29yZCI6IidhbmQoc2VsZWN0IDEgZnJvbShzZWxlY3QgY291bnQoKiksY29
uY2F0KChzZWxlY3QgY29uY2F0KENIQVIoNTIpLENIQVIoNjcpLENIQVIoMTE3KSxDSEFSKDEyMiksQ0hBUigxMDkpLENIQ
VIoMTA4KSxDSEFSKDEyMCksQ0hBUigxMTEpLENIQVIoMTE5KSxDSEFSKDExNSksQ0hBUig3NSkpIGZyb20gaW5mb3JtYXR
pb25fc2NoZW1hLnRhYmxlcyBsaW1pdCAwLDEpLGZsb29yKHJhbmQoMCkqMikpeCBmcm9tIGluZm9ybWF0aW9uX3NjaGVtY
S50YWJsZXMgZ3JvdXAgYnkgeClhKWFuZCciLCJ1c2VybmFtZSI6InRlc3QifQ%3d%3d
If you URL and Base64 decode this URL you will obtain the complete payload:
login.php?json={“password”:”‘and(select 1 from(select count(*),concat((select concat(CHAR(52),CHAR(67),CHAR(117),CHAR(122),CHAR(109),CHAR(108),CHAR(120),CHAR(111),CHAR(119),CHAR(115),CHAR(75)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'”,”username”:”test”}
In this case, the scanner found a vulnerability in the JSON password input that was Base64 encoded.
Similar to the JSON format, the new version of Acunetix WVS can parse and test XML formatted data. All individual XML nodes will be tested for vulnerabilities. In this case an XML input scheme will be generated and each xml node will be named based on its position in the XML data.
For example, the XML data <auth><username>user</username><password>pass</password></auth> will generate an XML input scheme with two inputs: auth.username#text and auth.password#text.
When we scan a test web application with the new version an SQL injection is reported for the XML input auth.username#text. The full HTTP request follows:
POST /xml_decode/login.php HTTP/1.1 Content-Length: 338 Content-Type: application/xml Host: bld01 Connection: Keep-alive Accept-Encoding: gzip,deflate User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.63 Safari/537.36 Accept: */* <auth><username>'and(select 1 from(select count(*),concat((select concat(CHAR(52),CHAR(67),CHAR(117),CHAR(74),CHAR(88),CHAR(112),CHAR(104),CHAR(104),CHAR(118),CHAR(51),CHAR(106)) from information_schema.tables limit 0,1),floor(rand(0)*2))x from information_schema.tables group by x)a)and'</username><password>e</password></auth>
In this case, another vulnerability has been detected using AcuMonitor technology. The web application was also vulnerable to XXE because it is parsing the XML data on the server side and External Entities processing was not disabled.
Check out the second part of this article for additional information on the updates introduced in Acunetix WVS v9.5
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Comments are closed.