CSRF Vulnerability Detection with Web Applications
Traditional CSRF vulnerabilities can be identified by analyzing each important get and post request going to the application. If an attacker can reproduce a get or post request, this can lead to CSRF. If a specific get or post request on an application throws some magic number that cannot be guessed easily, this can act as a token to guard against a CSRF attack vector. This magic token can be part of a querystring in a GET request while in a data buffer as part of a posT request. These tokens are compared on the server side before executing the requests. This provides protection against the CSRF vector. As far as CSRF is concerned, little has changed for Web 2.0 other than the delivery of requests.
HTTP requests going through XHR may be in the form of JSON or XML, and one needs to make sure these requests do have magic tokens with them for most sensitive HTTP requests such as changing a password or placing a buy order. The NetFlix application was vulnerable to this attack, and it was possible for an attacker to place an order on behalf of a user by forcing a post/get request to the server.
We covered CSRF in detail in previous chapters, where we have a sample XML going to the trading application for a purchase:
<methodCall>
<methodName>
<symbol>MSFT</symbol>
</methodName>
</methodCall>
There is no specific token here, and it is possible for an attacker to force this request from a browser. Here is a sample JSON call going to the server for a purchase:
{"symbol": "MSFT", "units": "20", "comment": "none"}
There is no token in this block either. These two requests can be victims of CSRF. Though it is difficult to simulate an actual request sent by an XHR call, it is similar to the native browser's post call. As we saw in Chapter 8, the only difference is their content type. An XHR call sends its request to the application with text/xml, but a browser would send it text/plain. Hence, one of the important checks, the text/xml type, is required on the application sides, which serve the XHR. For a Web 2.0 request, it is important that a text/xml check be made before processing an
XML/JSON stream. If a resource or framework process XML/JSON's content type is text/plain, this may cause CSRF. This is an additional check over a token embedded in XML or JSON as shown below:
{Transaction:"120934KLA23","symbol": "MSFT", "units": "20", "comment": "none"}
This way it is possible to guard assets against a CSRF vector by implementing a scanning test for each JSON- and XML-based stream.
Post a comment