Some thoughts on the JSON CSRF

CSRF as a common vulnerability, has been the focus of attention and research, JSON is a widely used lightweight data interchange format, when CSRF to post a JSON, the situation may become somewhat different; this time in a special case of the CSRF analysis, the right to be a catalyst.

Encountered a csrf that did not verify tokens and referer at one time.

Its original packet is:

POST /webnet/edit HTTP/1.1Host: www.xxx.comUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0Accept: */*Accept-Language: zh-CN,zh;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding: gzip, deflateContent-Type: application/json; charset=utf-8Content-Length: 85Cookie: testcookie=yes; ASP.NET_SessionId=5udmqb45qoypdc55mfp1w4vy{"pSpotId":"120201","pSignTimes":"70","pModuleID":"207","pSceneid":"120201007000046"}

Obviously, this is an operation to edit some kind of information, post is a JSON, and there is no validation of tokens and Referer

Submit using Form, the POC is as follows, the name is set to a JSON, its value is null:

However, the post data packet will have a "=", because although we set the value to NULL, then the "Name=" will still appear.

In this case, the JSON parser on the server might reject this JSON because it does not conform to the JSON data format. Referring to the practice of foreign Yankees, we can assign values to the value of this "=" to complement the data, so that it constitutes a complete JSON format, to avoid the parser error (JSON Padding).

The POC is as follows:

The resulting post package, which constructs a standard-compliant JSON data format to avoid errors:

It should be noted that in the original packet Content-type value is Application/json, and the form to submit is not able to set Enctype to Application/json, where it is set to Text/plain, So how do you set the value of Content-type?

    So we need to use XHR to submit, the background knowledge about XHR no longer repeat: https://en.wikipedia.org/wiki/XMLHttpRequest. The POC is as follows (where Content-type is set to Application/json):

In the Cors Standard, a new HTTP message header Access-control-allow-origin is defined, allowing the server to define a collection of domains that are allowed to be requested by the browser. In addition, the standard defines the request method that the browser sends a PREFLIGHT request (options request) to the server to solicit support when the cross-domain affects user data HTTP requests (such as sending a post with XMLHttpRequest), and then sends a real request based on the service-side response permission.

In some cases, if the server verifies the Content-type, it will not respond to the options request, thereby exploiting the failure, but in many cases the server may not validate the content-type. Or does not strictly check whether Content-type is Application/json, so in many cases this is available.

Some thoughts on the JSON CSRF