Once we have the code in the server, we can browse the web service client at http://192.168.56.11/dvwebservices/vulnerabilities/cors/client.php and start our exercise. Remember to have a proxy such as Burp Suite or ZAP recording all the requests:
- First, let's take a look at the normal operation, by browsing to client.php. It shows a secret word generated by the server.
- If we go to the proxy, Burp Suite, in this case, we can see that the client makes a POST request to server.php. There are a few things to notice in this request, exemplified in the following screenshot:
- The Content-Type header is application/json, which means that the body is in the JSON format.
- The request's body is not in the standard HTTP request format (param1=value¶m2=value), but as a JSON object definition, as specified by the header:
- Suppose we want to do a CSRF attack over that request. If we want an HTML page to make a request in JSON format, we cannot use an HTML form; we need to use JavaScript. Create an HTML file, CORS-json-request.html in this example, with the following code:
<html>
<script>
function submit_request()
{
xmlhttp=new XMLHttpRequest();
xmlhttp.open("POST","http://192.168.56.11/dvwebservices/vulnerabilities/cors/server.php", true);
xmlhttp.onreadystatechange=function()
{
if(xmlhttp.readyState==4 && xmlhttp.status == 200 )
{
document.write(xmlhttp.responseText);
}
}
xmlhttp.send('{"searchterm":"secretword:one"}');
}
</script>
<body>
<input type="button" onclick="submit_request()" value="Submit request">
</body>
</html>
- The preceding code replicates the request made by client.php. Open it in the browser and click on Submit request. Nothing will happen, and the following screenshot shows why:
According to the preceding error, the request is blocked by the browser because the server doesn't specify the allowed origins in its Access-Control-Allow-Origin header. This happened because we are requesting a resource (server.php) from an origin external to the server, a local file in our Kali VM.
- The easiest way to work around this restriction is to create an HTML page that sends the same parameters in a POST request generated by an HTML form, as browsers do not check the CORS policy when submitting forms. Create another HTML file, CORS-form-request.html, with the following content:
<html>
<body>
<form method="POST" action="http://192.168.56.11/dvwebservices/vulnerabilities/cors/server.php">
Search term: <input type="text" name="searchterm" value="secretword:one">
<input type="submit" value="Submit form">
</form>
</body>
</html>
Browsers do not check CORS policy when submitting HTML forms; however, only GET and POST methods can be used in forms, which leaves out other common methods implemented in web services, such as PUT and DELETE.
- Load CORS-form-request.html in the browser; it should look as follows:
- Click on Submit form request and take a look at how the server responds with a JSON object containing the secret word:
- Check the request in Burp Suite and verify that the Content-Type header is application/x-www-form-urlencoded.