jsonp安全性防范，分为以下几点：

1、防止callback参数意外截断js代码，特殊字符单引号双引号，换行符均存在风险

2、防止callback参数恶意添加标签（如script），造成XSS漏洞

3、防止跨域请求滥用，阻止非法站点恶意调用

针对第三点，我们可以通过来源refer白名单匹配，以及 cookieToken 机制来限制

而前两点，传统的做法分为以下几种：

1、纯手工过滤特殊字符，引号尖括号等，一旦发现潜在恶意字符则服务端拒绝，返回错误。

此种方式较为严格，但是随之而来的问题是失败率会有所提升，尤其对于对外开发者。

而且JS中恶意字符的变形十分多，此方式需要枚举所有非法字符，可能存在疏漏。

我们不应该将潜在的恶意字符都一概屏蔽，因为确实有些需求需要传入并存储这些字符。

2、对于callback参数作严整的格式检查，或强制约定指定格式。基本可以彻底解决安全问题，

但同样是对调用端不是完全透明，使用者需要额外去知晓相关限制和约定，可能会造成不必要的沟通成本。

3、返回包体添加header头部，强制指定MIME类型，避免按HTML方式解析，防止XSS漏洞。

这似乎是个很完美的解决方案。

但是十分诡异的是，在某些版本的火狐浏览器下，直接访问MIME类型为JAVASCRIPT的请求时，浏览器仍然会按照HTML解析。

或许是该浏览器设计的缺陷，但它忽略了我们设置的header。无法保证所有浏览器严格按照MIME类型解析。

我们的关注点一直在于如何限制用户输入，但是请从另外一个层面去考虑该问题，或许就会豁然开朗。

我们先了解一下JS本身的特性。

JSONP的本质是构造全局回调函数，之后加载script标签触发回调函数。
通常我们使用函数可以这么写

function test(){}test();

而在全局的函数也就默认是window的成员。也可以显示书写为

window.test = function(){};window.test();

而JS中对象的成员是可以使用字符串索引的方式访问的，故进一步改造为

window[‘test‘]=function(){};window[‘test‘]();

现在有注意到么，如此一来我们已经把函数名已经完全限制在了字符串上下文，

理论上只要做好了防注入工作，callback参数是不可能跳出字符串上下文意外执行代码的。

以PHP为例，单字符串防止注入甚至可以直接使用json_encode该字符串实现。

window[‘alert("123");abc‘]();

上面的callback参数虽然有注入的风险，可以由于callback参数严格限制在字符串内部，仅会作为文本，不会意外执行

但仍然存在xss漏洞问题
看下面例子

window[‘<script>alert(123);</script>‘]();

我们虽然已经保证了<script>严格限制在引号内部，不会造成js注入，但是直接在浏览器中输入该jsonp请求仍会按照HTML解析，产生XSS

漏洞，即便设置了header也很难防范。

在进一步，我们只需要保证浏览器内不会明文出现<>标签，那么问题便可彻底解决。

基本思路是在服务端做一次urlencode。而在output输出decodeURIComponent(‘#####’)来规避显示尖括号。

Urlencode过的字符串，只可能包含字母数字%，也顺便解决了注入的问题

最终附上一段简短的代码。根本解决jsonp的安全问题

<?php header(‘Content-type: text/javascript‘); //加上此句可以消除chrome的警告 

$callback = urlencode($_GET[‘callback‘]); 

echo "window[decodeURIComponent(‘{$callback}‘)]({ret:0,msg:’OK’});"

请求1：http://www.test.com/a.php?callback=alert(123);abc

响应1：window[decodeURIComponent(‘alert(123)%3Babc‘)]({ret:0,msg:‘OK‘});

请求2：http://www.test.com/a.php?callback=<script>alert(123);</script>

响应2：window[decodeURIComponent(‘%3Cscript%3Ealert(123)%3B%3C%2Fscript%3E‘)]({ret:0,msg:‘OK‘});

上述几个例子都可以证明jsonp安全漏洞已被彻底规避，即便存在尝试注入的恶意参数，仍能最大限度保证程序完全正常工作触发回调。

来源

?

解决 jsonP 安全问题