我和JS文件不得不说的故事

兄弟们，晚上好呀，太久没和大家聊天了

今天决定给大家掏一下💖窝子

大家可能都知道我是一个未成年的白帽子，在我17岁之前，我从来没有挖过什么SRC

不过，也曾侥幸在某些众测平台上斩获过80大洋😏

依稀记得那个感觉简直不要太爽，"我居然靠挖洞赚到钱了",当时满脑子都是这东西

虽然也不是真钱，而是8个金币，但这区区8个金币对当时的我来说可意义非凡呀

看到金币真正到账的那一刻，我兴奋地跑去和室友们吹嘘起来

“爷挖洞赚到钱了，屌不屌！”

室友们当然也非常nice，一直像下面这样鼓励我

得到室友们的友好问候，我兴奋不已，决定再接再厉

但是

挖了几天发现啥都挖不到了，这还玩个🐍🐍？？？

在哪里跌倒，就在哪里躺下

于是，我再也没有碰过黑盒挖洞这东西，然后就去搞白盒了...

还好，白盒挖掘没有打击我，我对白盒也特别喜欢，本想趁着今年整个有分量的0day

但是，计划赶不上变化，工作原因暂时还是得先搞搞黑盒

时隔一年多，上上周我开始挖src了，同样的，我还是觉得src挖掘太tm难了呀

什么安全工程师，简直就是互联网资产清点工，我也算是真正理解了“渗透测试的本质就是信息收集”这句话的含义

不过挖洞也还是有点收获的，挖了两天vivo挣了700，这也是我的src第一桶金

然后前天看到水滴SRC新人三倍奖励，顿时就心动了，要啥自行车，赶紧跑去挖💧

还没开始挖，就已经想好国庆去哪里度假了🤔

功夫不负有心人，挖了两天总算挖到个中危的ssrf

结果

撞洞了

当时我那不争气的眼泪就扑簌簌的往下掉

本来想着1000大洋可以到账了，结果竹篮打水一场空

而且，这不是最可怕的，最可怕的是我觉得我已经把所有能看的功能都看了（除了要收钱的功能😅），哪里还有漏洞？爷的度假梦泡汤了，55555

而且，因为挖的是水滴src,水滴有个业务是卖保险

所以，在我挖掘的过程中，已经收到过好多次水滴保险小哥哥的电话了

当然，他们还是很有礼貌的，电话一接通你就可以听到一副很温和的声音对你说

当时就给我吓坏了，原来他们不是馋我的技术，而是馋我的身子，这简直太糟糕了

但是，我阳光幼儿园三班浪里小白龙什么大风大浪没见过？

我迅速稳定心神，不能让他们就这么羞辱我，我得支棱起来，好好做信息收集，我决定先从JS下手...

JS里能找到啥？

作为一个安全从业人员，我们最关心的就是Js文件中的这些东西：

• 会增加攻击面的信息（URL，域名等）

• 敏感信息（密码，API密钥，bucket等）

• 代码中的潜在危险函数操作（eval，dangerallySetInnerHTML等）

• 具有已知漏洞的组件（过时的框架等）

怎么去找？

1. 识别并收集应用程序中的JavaScript文件

2. 使收集的JavaScript代码可读（取消最小化/反混淆）

3. 识别可能导致安全问题的信息（找敏感词）

收集整理js文件

如果你是使用Burp Suite来进行测试，就可以通过多种方式来收集应用程序中的所有JavaScript文件。这也是俺比较喜欢的一种方式

挂着burp，然后浏览应用程序。浏览结束后，burp会被动或主动记录下所有经过burp的请求，其中就包括你请求的js文件，然后咱们就可以使用burp提取出js文件😉

如果你使用的是Burp Suite社区版，则可以导航到 Proxy > HTTP history，并使用显示过滤器仅显示该应用程序使用的JavaScript文件。您还可以复制所有显示的JavaScript文件的URL。

如果使用的是Burp Suite专业版，不仅可以复制应用程序中所有JavaScript文件的url，还可以导出所有js文件内容。在Target > sitemap下，右键点击感兴趣的站点，选择Engagement tools>Find scripts。使用此特性，你可以导出该应用程序中的所有脚本内容。

还有一种利用【互联网归档数据库】快速查找Js文件的方法，如Wayback Machine,这种技术是完全被动的，因为我们不向目标应用服务器发送任何请求。

Wayback Machine可以理解为一个互联网的历史记录数据库，你可以在里面找到某个网站所有的链接

它的地址是(可能需要爬墙)：https://archive.org/web/

在诸如Wayback Machine之类的Internet档案库中进行挖掘对于识别应用程序中的JavaScript文件非常有用。有时，能够找到服务器上未删除的较旧的JavaScript文件

waybackurls是一个使用Wayback Machine搜索某个站点JavaScript文件(或者任何其他url)的工具，大家可以瞅瞅

使用Wayback Machine可能会导致误报，所以，在收集了JavaScript文件的url列表之后，我们需要检查这个js文件是否真的还存在，可以使用curl快速检查服务器上的JavaScript文件的状态

命令如下（感觉老外特别喜欢玩这些花里胡哨的命令）：

cat js_files_url_list.txt | parallel -j50 -q curl -w 'Status:%{http_code}t Size:%{size_download}t %{url_effective}n' -o /dev/null -sk

如果你觉得上面的方法太麻烦了，也可以使用其它现成的工具，例如：hakcheckurl

• 安装：go get github.com/hakluke/hakcheckurl

• 使用：cat lyftgalactic-js-urls.txt | hakcheckurl

Js文件美化

大多数时候，我们收集的JavaScript文件都是经过压缩、混淆的。

有很多工具可以压缩JavaScript。UglifyJS是一个压缩JS代码的工具，它也可以作为npm包使用

有很多工具可以解压缩js。例如JS Beautifier，这个工具很强大，我们可以在各个语言中使用它，例如node.js、python等

当我们在反混淆时，特别是在逆向恶意程序时，没有一种技术或工具是一劳永逸的。我们将不得不尝试各种工具、去混淆方案。当然，目前已经有很多工具可以帮助咱们去混淆Js代码,例如：

• JStillery：https://github.com/mindedsecurity/JStillery
• JSDetox: ``
• JS-Beautifier
• IlluminateJs
• JSNice

寻找敏感信息

js文件中有很多接口，这些接口可以扩展我们的攻击面，例如，我在水滴src中某个页面下发现的js文件：

虽然经过测试这些接口貌似都没有未授权访问问题，但是，只要肯挖，说不定下一次就是一个高危敏感信息泄露呢？

当然，也有一些很方便的工具帮助我们从js文件中提取这些接口：

relative-url-extractor:这个工具既可以直接从线上js文件中提取接口，也可以从本地文件中提取，并且，它还可以从压缩的js代码中提取，直接省去了咱们前面说的美化js的步骤

LinkFinder:这个工具也相当nice,应该很多人都知道，使用也很简单：

python linkfinder.py -i https://example.com -d -o cli

当然，还有国内一位安全研究员写的JSFinder，也是很好用的

找这些敏感信息也还是靠正则，当然还有一种技术叫entropy,俺也不知道这个怎么翻译才好，应该就是根据一串字符串的随机性来判断这个字符串是否是密钥，我们都知道，密钥都是一串字符嘛，同样的，有工具👻，安心做个脚本小子吧：

• DumpsterDiver
• Repo-supervisor
• truffleHog

除此之外，还可以用grep/sed/awk等工具来搜索敏感词

我都说了，shell玩得好，老婆随便找

下面的内容逐渐超出我漏洞挖掘的耐心范围，非战斗人员请撤离❗️❗️❗️

JS中的一些函数使用可能带来潜在的问题，例如innerHTML的使用就可能带来dom xss问题

而现在前端框架琳琅满目，我一个都不会，md

他们用的方法名字那叫一个长呀，React中就有一个和innerHTML差不多的函数叫做dangerouslytSetInnerHTML，这个函数也是咱们的重点关注对象

然后还有Angular中的bypassSecurityTrustX，还有咱们熟悉的eval函数

除此之外，还有postMessage函数值得关注，这个函数相关的问题都可以专门开一篇文章讲了，这里就不多说了，下次一定，下次也不一定...

localStorage和sessionStorage是HTML Web存储对象

通过web storage，web应用程序可以在用户的浏览器中本地存储数据

识别使用Web Storage存储的内容非常重要，尤其是可能导致潜在安全问题的内容

在JavaScript中，我们可以可以查找window.localStorage以及window.sessionStorage。这里俺也不太了解，留待大家去探索吧🤔

寻找js中的危险函数、危险代码高度依赖目标所使用的的前端技术栈，不说了，先去学webpack了

哦，对了，我们还可以使用工具呀😝

• JSPrime：是一种静态代码分析工具，用于查找JavaScript代码中的安全性问题，但是该项目已经有一段时间没有更新了。

• ESLint：是最流行的JavaScript工具之一，通过添加自定义规则，对它进行自定义。ESLint提供了许多自定义安全规则，尤其是针对现代框架（如Angular，React等）。

老生常谈的问题，寻找一些老旧的存在问题的前端框架，不过，我觉得这个基本没啥用，为了文章完整性还是列出来吧

如果目标程序使用了一些存在漏洞的前端框架，那对我们来说也是一点曙光不是？

关于这个的挖掘，直接上工具吧——Retire.js

Retire.js是一个可以识别应用程序使用的老旧JavaScript框架的工具

该工具可以用作独立工具，浏览器扩展，grunt插件或Burp / ZAP扩展。当然，这个工具也还是有很多误报的，不过作为参考还是不错的嘛

其它

挖洞路上我就是个臭弟弟，如果表哥们有什么好的挖洞思路以及资源，欢迎在评论区分享补充