XMLHttpRequest Based CSRF Test 1.0

Tushar Adhikary
By Tushar Adhikary

December 15, 2015

Overview

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.

XHR is a tool using JavaScript that allows one to make web calls. The possibility of custom web-requests is an additional benefit of using XHR. This is made possible because additional request headers can be added to a web request. Although this technique increases flexibility, it also creates a security risk that can be exploited in a digital attack.

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.

Also, check out how a Managed Detection and Response (MDR) service uses Artificial Intelligence (AI) techniques and machine learning to provide high speed cyber defense

Basic CSRF Test Case

Let’s start things off with a simple scenario where the request does not have a token and it utilizes a basic POST request. The JavaScript code developed to make this attack possible is shown below:

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.

Prevention Techniques against CSRF Attacks and XHR Limitation

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-Requested-With
  • Accept
  • X-<arbitrary name>

All these request headers were added to a web request and the values of these fields were identical. This posed a security risk. As previously, if we were to conduct an XHR enabled CSRF attack, we would craft the JavaScript code as follows:

XHR enabled CSRF attack

The use of setRequestHeader allows XHR to add request headers. In this scenario, we are adding a header called Content-type with the contents being “application/x-www-form-urlencoded”. This attack was previously possible, but now it will not function as expected. When the above JavaScript code executes, the following sequence of steps will take place:

  • 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.
  • If the headers contains a value “*” or the domain form where we are making the JavaScript call, only then will it execute the POST request to com with our custom header.

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:

  • PUT
  • DELETE
  • TRACE

These requests cannot be executed via cross domain, meaning a JavaScript code present at attacker.com simply cannot make an XHR call to victim.com. To effectively carry out such calls, Cross Origin Resource Sharing (CORS) has to be implemented.

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

Tags: blog, XHR, XHR Limitation, XMLHttpRequest Based CSRF Test, CSRF, productId