Hackers are continuously looking to find vulnerabilities in systems and exploit them for nefarious gains. Over the years, there have been thousands of attacks targeting multiple weaknesses that coders and developers inadvertently wrote in their programs. One such example which we will analyze in detail in this post is a cross-site request forgery (CSRF) attack exploiting a weakness in a XMLHttpRequest (XHR) technology.
In this two part series, we will first present to you cases which will illustrate how XHR requests can be made and how CSRF attacks can take advantage of XHR coding, highlighting preventative measures and XHR limitations. In the second part of the series, we present how an alternative approach to preventing CSRF attacks can reduce your website’s vulnerability.
We hope these two articles will give you a basic understanding of this vulnerability and assist you in preventing such attacks within your system and organization.
Basic CSRF Test Case
In this example, a POST request is made to www.example.com for a product update. The parameters being modified in the request are productId and vote. If a user is logged into www.example.com, the relevant cookie associated with that domain will also be sent due to the clause “withCredentials=true”. This is how a CSRF attack can be easily crafted via XHR.
Prevention Techniques against CSRF Attacks and XHR Limitation
As CSRF attacks increased in prevalence and became a serious security threat, multiple solutions were presented to block the attacks. The first solutions suggested by developers included the use of custom request headers and token data with every request. Yet, only one of two factors was required to fulfill the request. At the time, the addition of request headers via web forms was not possible. Hence, this strategy mitigated CSRF attacks for a while. Unfortunately as previously stated, XHR permits the use of custom request headers which created another issue. The next coding sample is vulnerable to a CSRF attack even though it is using a custom header to validate each request.
Here all HTTP requests are validated by the header, “Content-Type: application/x-www-form-urlencoded”. If this request header is not present, then the server will refuse to fulfill the request. Some other request headers which were used to validate or prevent CSRF attacks were:
- X-<arbitrary name>
- The web browser sends a query with an OPTIONS request to example.com.
- The web browser checks the response from com.
- The response header Allow-Access-From is checked to ensure we are able to make cross domain calls.
- If the header is not present, the POST request is never made.
This limitation for XHR by the browser was made because it presented a security issue. Denying XHR to make such custom calls protected Web Applications from various attacks. Some of the HTTP METHODS which are blocked by default are as follows:
In the next part [link to second part of the article] of this series we will analyze how a different approach to CSRF attacks can be helpful.
About the Author
Tushar Adhikary is an information security enthusiast. A novice in the cyber security world, he is keen on exploring the uncharted and unnamed in the field of network and application security.
He is an active bug bounty participant with numerous ‘Hall of Fames’ for companies like Twitter, Yahoo, Basecamp, Vimeo, and much more.
He is currently working as a Security Analyst & a Tech Specialist at Paladion Network Pvt. Ltd. Part of his job includes conducting vulnerability assessments, penetration tests, web application security tests and much more.Speak to our application security experts