基于AST的JSONP劫持自动化挖掘该怎么理解,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
0 x01 JSONP劫持简介
JSONP利用脚本标签的跨域能力实现跨域数据的访问。请求动态生成的JS脚本同时带一个回调函数名作为参数。服务端收到请求后,动态生成脚本产生数据,并在代码中以产生的数据为参数调用回调函数。
JSONP劫持,就是在受害不知情的情况下,访问了攻击者的网站,攻击者通过JSONP接口获取用户在其它网站的敏感信息。
因此通常用做:
- <李>
敏感信息泄露引发的精准诈骗。
李> <李>防守方的溯源能力之一,如在蜜罐中获取攻击者画像。
李>0 x02 AST简介
AST(抽象语法树,抽象语法树)是源代码语法结构的一种抽象表示。它以树状的形式表现编程语言的语法结构,因此相同含义的代码,即使在不同形式的实现方式下,在AST层面是统一的。
在AST层面的统一和一致,是传统的正则匹配所做不到的。使我们可以很轻易的解决下面几种情况:
<>之前回调({“username":“xray"}); 回调({“data":{用户名:“xray"}});/* aa */, window.cb ,,, window.cb ({“username":“xray"}) 回调([{“info": {“username":“array"}})) cb (& # 39;,, {“username":“xray"},, & # 39;) a={“username":,“xray"},, cb ({“s":})0 x03 JSONP漏洞挖掘
Koalr师傅的分享非常好https://koalr。我/post/a-tour-of-xray/?/p>
手工挖掘JSONP漏洞时,主要分为以下几步:
- <李>
找JSONP接口
李> <李>检查响应是否包含敏感信息
李> <李>绕推荐人
李>在做自动化挖掘时,我们应该主要考虑以下几个问题:
- <李>
优秀的爬虫(使用crawlergo)
李> <李>筛出js资源:通过内容类型即可判断。参考chrome.https://github.com/chromium/chromium/blob/fc262dcd403c74cf3e22896f32d9723ba463f0b6/third_party/blink/common/mime_util/mime_util.cc # L42
const char *, const kSupportedJavascriptTypes [],=, { ,,,“应用程序/ecmascript" ,,,“应用程序/javascript" ,,,“应用程序/x-ecmascript" ,,,“应用程序/x-javascript" ,,,“文本/ecmascript" ,,,“文本/javascript" ,,,“文本/javascript1.0" ,,,“文本/javascript1.1" ,,,“文本/javascript1.2" ,,,“文本/javascript1.3" ,,,“文本/javascript1.4" ,,,“文本/javascript1.5" ,,,“文本/jscript" ,,,“文本/livescript" ,,,“文本/x-ecmascript" ,,,“文本/x-javascript" 李};> <李>
解析js类型资源,检查查询中的每个键,是否满足jsonp的特征。正则大法好:
(?)(我)吗?(回调)| (jsonp) | (^ cb)美元|(函数)李> <李>
推荐人配置为同域,请求js获取响应。
李> <李>将jsonp响应解析成AST,如果生成的AST满足以下条件即可认定存在jsonp漏洞。
一、调用。名字==回调函数名
二、检查是否存在敏感信息:递归遍历AST获取所键和值,是否满足满足正则(?)(我)吗? (uid) | (userid) | (user_id) |(外祖母)|(名字)|(用户名)|(尼克),且值不为空
李> <李>替换推荐人后再请求一次,重新验证步骤5 .
李>0 x04工具使用方式
通过golang实现了以上逻辑:https://github.com/jweny/check_jsonp_based_on_ast
本组件未单独提供爬虫,须结合爬虫使用(推荐crawlergo),将爬虫的js资源直接用工具检测即可。
项目中提供了一个jsonp的漏洞环境,如需自取。
入参:js uri
返回:是否存在漏洞(bool型,真为存在漏洞),犯错
例:
结果,,err :=, CheckSenseJsonp (“http://127.0.0.1/jsonp_env/getUser.php?id=1& jsoncallback=callbackFunction")