The json security defense technology

By Ashley Cooper,2015-07-01 23:18
28 views 0
The json security defense technology

     The json security defense technology

    About the json

    The JSON full name is the JSON with Padding, is based on the JSON format to solve the cross-domain resources request solution.Its basic principle is to use HTML element tag, remote call JSON file to achieve data transmission.If you want to be under the domain to obtain the JSON data under the (getUsers. JSON) :

    You can first through the JSON the getUsers "Padding". The JSON output is:

    For practical application in the process of the name of the callback, the background is dynamic output.The above example using PHP implementation is as follows:

    At then use the < script > remote calls, can be directly in the jQuery calls like this:

    Security issues, however, has been accompanied by business development, the json also bring all kinds of security problems.This paper combs the json security attack and defense in the process of implementation.

    JSON hijacked

    JSON hijacked say again "JSON about, 2008 foreign security researchers have been mentioned by the risks of the JSON.This problem belongs to CSRF (Cross site request

    forgery cross-site request forgery) attack category, when a web site through the json cross-domain (general subdomains) as the sensitive information after the user authentication is passed, the attacker can construct a malicious json call page, induced by the attacker to access, to achieve the goal of intercepting user sensitive information.A typical JSON about attack code is as follows:

    This is the dark clouds on the report of a case against (WooYun - 2012-2012), when the attacker 360 website login and access the web page, personal privacy data (such as user name, email, etc.) may be captured by an attacker.

    Although the attack has been for many years, but it is common in large portal site also, and because the safety consciousness weak, many enterprises did not realize the importance of this problem.

    But many party a company began to attach importance to these security issues, working on the solution.One solution is to verify the source of the JSON file calls (Referer).It mainly use the < script > remote loading JSON files when sending Referer mechanism, output JSON data on its web site, to determine whether a Referer included in the white list.This method is feasible in theory, but the specific implementation process prone to two logical problem.

     Referer filter (regular) loosely

    For example, = cb this URL output data, use the Referer filtering.But unfortunately only filter contains such keywords, and the attacker can, by constructing a URL (such as or to bypass the Referer defense.

     empty Referer

    In many cases, the developers to deploy filtering Referer source, ignore the empty Referer filtering.Browser normally have direct access to a particular URL is without Referer, so a lot of empty Referer defenses allowed.Precisely because of the negligence, lead to the entire defense system collapses, because in the invoke JavaScript, by agreement across the HTTP requests sent in Referer is empty.Across the agreement calls a simple example is as follows:

    JavaScript code we use the < iframe > call pseudo protocol to implement empty Referer call JSON file.

    Another way is by random token defense, this technology widely applied on tencent's website, for example through = [QQ number] & g_tk = [random token] output JSON.This scheme is effective, but also defense not achieve rigorous problems.For example this token to brute force by the following way:

    Of course, all of these are pure offensive against "JSON hijacked" itself.In reality, many holes are mutually cooperate to achieve breakthrough.Such as the above mentioned limits Referer + deployment random token is perfect, perfect in theory, but as long as the website exists XSS holes, can instantly make your defense system crashes!More than by the way, here are some general implementation "JSON hijacked" approach, but in reality, some special processing mechanism of some browsers (such as CSS load, error message display, etc.), also can cause similar "JSON hijacked" (attack object is not necessarily the JSON) attack.

    The callback can define cause security problems

    In order to facilitate the front-end development calls, the output is usually can be defined, mentioned above the PHP code:

    Because can define callback dots, led to a variety of security issues., of course, strictly speaking, the mention of specific data output is also available, just this paper stressed the callback the dots.

    "The content-type and XSS holes"

    In JSON has just emerged, most developers have not good coding habits.Output JSON, not strictly define the content-type (the content-type: application/JSON), plus the callback dots without filtering, led directly to a typical XSS holes, the above demonstration getUsers. PHP is the question:

    Early for the content-type, there are some people prefer to use the application/javascript, and the head in IE browsers can parse HTML cause XSS holes.For this type of vulnerability, defense mainly from the following two points.

    A. strictly defined the content-type: application/json

    The defense mechanisms leading to the browser does not parse XSS insert malicious code (direct access to the file download).But there are exceptions, in the process of the evolution of the IE appeared through a few skill, and can bypass the content-type defense parsing HTML events, such as in Internet explorer 6, 7 version request the URL of the file after adding a/x.h HTML can parse HTML ( < script > alert (/ XSS) < / script >), specific for reference.

    B. filter callback and JSON data output

    Of attack and defense of this mechanism is a more traditional thinking, to XSS filter output point, again a look very perfect solution, but often "counterproductive".In 2011, a utf7 raised n XSS holes - BOM.The means of attack is mainly exists in Internet explorer (IE has repair) the new, when we are in the callback point o + / v8 utf7 - BOM, IE browser will think of the currently executing code as utf7, so we submitted by utf7 XSS code will be automatically decoding and executed.Such as:

    Among them:

    URLdecode as follows:

    + / v8 utf7 - BOM, then as we injected through utf 7 encoded XSS code:



    About this case may refer to for details.

    Using utf7 - BOM is a very typical general method, in addition to defense upgrade the IE, developers also can specify the content-type coding directly (the content-type: application/json; charset = utf-8).In spite of this, however, still has the potential to bypass these defensive measures.

    Above mentioned a and b both defense of a possible problem, then we use "a + b" whether is safe?Everything is possible, we wait and see.

    Other file formats (the content-type) with JSON

     MHTML and json

    In 2011, IE appeared a MHTML protocol parsing through cross-domain: MHTML Mime - Formatted Request Vulnerability (CVE - 2011-0096, a time when the attack method is a common use of the json call the callback function name dots in the mechanism:

    About this case, see "Hacking with MHTML Protocol Handler"


    It made full use of the callback dots directly output MHTML file format, and then use the < iframe > call MHTML parse and execute your HTML and JavaScript code, this is also a

    general XSS holes (UXSS), later Microsoft introduced a solution for emergency and loophole patch.Before Microsoft introduced security patches, this vulnerability has affects large sites such as Google, then Google for defensive measures of this kind of attack is enabled, the JSON output callback, and increasing the multiple line breaks at the beginning of the file, make remote MHTML call resolution fail.

    In the Angle of attack, it makes full use of the computer system of various file format recognition mechanism.Under the guidance of this thinking, also appeared many times by the file format after loading of security problems, for example a CSS file format to load caused by class "JSON hijacked," JavaScript to load and various file format code security problem and so on.History often appear all sorts of uncanny similarity to the json legend also staged with file format.

    The FLASH with the json

    Who is coming will come, just didn't expect a similar scene so fast.As recently as a Flash security updates (security bulletin APSB14-17) in fixed a security vulnerability:

    These updates include additional validation checks to ensure that Flash Player rejects malicious content from vulnerable JSONP callback APIs (CVE-2014-4671).

    The hole due to the effects such as Google, Facebook, bursts of web sites and media attention.The attack technology is closely related to the json callback points.Through this problem mainly in HTML < embed >, < object > call remote Flash files, will ignore the content-type directly, as the json output callback, usually at the beginning of the file, then the point can completely through the callback output a SWF file, then remote HTML call and run a SWF file.Such as:

    It is put forward as early as 2012 by output callback SWF files, its actual effect is on the attack website where a malicious SWF files, HTML remote calls the SWF files, can be directly lead to CSRF attacks.

    Specific Upload Flash files with CSRF attacks, please refer to the Flash + Upload CSRF attacks technology _attacking ( /).

    Careful friends may find that the above code output callback SWF file flow exists in all kinds of special characters, through the above mentioned "b. filter callback and JSON data output" scheme can intercept directly, to sophisticated large sites like Google, Facebook, defense.

    In the Flash update "security bulletin APSB14-17" after the release, the vulnerability discovery vulnerability details are given, one of the bright spots, is the author implements a method of pure alphanumeric output SWF files:

    Specific please refer to

    For pure alphanumeric output, therefore, against XSS filtering can ignore directly, obviously this vulnerability also proved that above we mentioned the "solution" a + b can be directly to bypass.


    Through the attack-defense exercise above, many developers may feel a little tragedy, a variety of defense mechanisms as if there are ways of getting around.Here I think of a truth: there is no absolute safety.Where, then the meaning of our defense?I think the meaning of the defense is although no way to program the safest (safe), but you can make it more safety.Raise the cost of the attacker's technology and the threshold is one of the main security defense and important ideas.Back on specific json defense, can be summarized as follows.

    1. CSRF way that strict safely call JSON file: limit the Referer, deployment, one-time token, etc.

    2. Strict installation JSON format standard output content-type and coding (the content-type:

    application/JSON; charset = utf-8).

    3. Strict filtering the callback function name and the output of the JSON data.

    4. The length of the strict limits on the json output callback function name (such as defense above

    Flash output method).

    5. Other comparative "obscene" approach: for example, in the callback output before joining other

    characters (e.g., / * * /, line breaks, etc.) that do not affect the JSON file loading, but also to a

    certain extent prevent other file format of the output.Gmail has get JSON using AJAX way,

    through the output JSON before joining the while (1);The JavaScript code to prevent remote calls.

Report this document

For any questions or suggestions please email