实战中获取JS文件的各种场景

1.前言

在前面的几篇文章中，我们先是介绍了如何从JS里提取一些信息，然后介绍了如何从JS里提取参数以辅助测试。但是还有一个至关重要的问题我们没有解决，在不同场景下，我们获取JS的方法会有差异，而且目的也不尽相同，这会影响到后续测试的展开。本文就来尝试列举一些笔者在日常测试过程中的一些获取JS文件的常见情况。

2.开局一个登录点 or 开局一个神秘白屏

这是实战中我们最最常见的情况，比如我们拿到一个登录点

再比如，像下面这样的一片白的网站

查看其页面源代码，就可以发现一些js文件

这种情况，使用packerfuzzer将JS文件下载回来即可，目前来说，大部分JAVA站点，尤其是Spring相关的站点，基本都会像上面一样对js进行打包，看到app.js index.js main.js之类的关键词，用packerfuzzer进行处理是比较好的。当然，如果是比较传统的写法，类似下面这种，一样可以用packerfuzzer去下载

（图片仅作示例，大概是这样，与具体的漏洞案例无关）

这种情况还有一个变种，之前也提到过，那就是页面源代码没有webpack的一些特征

但是burp可以看到app.js的加载

这种在F12的源代码-来源中应该也能找到一些蛛丝马迹

这种情况下还是用findsomething或者其它类似burp插件去拿到JS并自动提取里面的信息，因为凭人的注意力不可能百分百注意到所有这类js文件。

在这种情况下，我们获取JS，并分析其中的信息，主要目的是尝试直接调用后台的一些接口或者进入后台。

3.开局一个登录点或部分后台界面，但重定向到SSO

这个也是平时测试里很常见的，我们之前也提到过，很多后台都是，你从url访问进去，能看到一点东西，比如下面这样：

虽然没加载出什么功能，都是空的，但是我们能看到一个简单的界面

然后重定向到统一登录（这里也并非漏洞案例，就纯粹用来说明是一种什么情况）

像这种情况，能看到后台的页面，说明JS至少是加载出来一部分的。这种情况也是直接把目标网站丢给packerfuzzer去拿到js文件即可。

此外，这种情况还有个变种玩法，就是在一些比较严格的规则下，我们访问一个网站不会有“闪一下后台页面”这个过程，访问就直接是登录口了。然后登录口也看不到啥有用的JS。这种情况有一个玩法可以试试，那就是用修改返回包的姿势，把登录状态修改为成功，尝试一下能不能短暂进入后台，加载出后台的JS。

在这种情况下，我们获取JS，并分析其中的信息，主要目的是绕过SSO统一登录，去调用目标后台的一些接口。值得注意的是，在这种情况下，如果获取到目标原后台的一个非SSO的普通登录点，也是有很大价值的。因为目标的一个后台未必是一开始就接入SSO，它原本可能有一些自己的登录口，后续为了安全性考量才接入的SSO。因此在这种情况下，如果找到原先的一些常规登录接口，用密码喷洒和爆破等姿势是很容易打开突破口的。

4.新页面，新JS

在很多情况下，我们进入一个新页面，可能会加载新的JS，比如公众号发的这篇文章：

https://mp.weixin.qq.com/s/AoELgEi_g8JfAlUPf6ZimA

就是进入了新页面之后，提取出新的JS，在新JS里找到新接口，从而打开的突破口。所以当我们进入一个新页面，还是要警觉一点，看看页面源代码，看看F12，有没有多出一些新东西。在这种情况下，我们的目的还是去调用一些后台的隐藏接口。

还有一种很常见的情况如下，比如我们以一个低权限用户进入了一个后台（平台）。

权限很低，没啥功能可以调用，但是管理员页面的功能很多：

我想表达什么意思呢？意思就是，管理员权限下这些功能点，背后对应的接口，应该是写在后台的JS里的吧？只是因为一些规则，没有给我们显示出来而已。因此，当我们以一个低权限用户进入后台，可以再尝试提取一次JS，可以靠findsomething等插件，把后台中的接口尽可能地进行提取，然后以低权限尝试去访问你提取出来的接口，有些接口可能是管理员才能用的，只是做了一个前端的隐藏，其功能对应的后端接口，有时候是没做好鉴权的，这样就会形成一个越权问题。

所以，可以养成一个习惯，无论用何种方法，当我们找到并进入一个新的页面，最经典的比如从前台进入后台，可以打开页面源代码或者F12，看看有没有多出一些新的JS。

5.不要只关注JS文件

在有些时候，尤其是一些比较古老的PHP/ASP.NET站点，大概像是下面这样：

这类似我们前面提到的新的页面有新的js的情况，但他这个js代码和JS里要请求的接口uri，是通过script标签嵌入在html里的，并不是打包放到js文件里，这种情况下会对很多工具造成影响，但是findsomething和unexpected.information这类从响应内容被动探测的插件应该还有一战之力。

6.注意不同页面、不同JS之间的关联性

这个也是和上面提到的比较古老的PHP/ASP.NET站点有关，简单来说是这样的。就是比较古老的站点，有时候可能是一个页面对应一个js。譬如我后台首页/index.php，对应的js就是/js/index.js，后台用户信息页面/user.php，对应/js/user.js。类似下面这种：

这种一看就有种很古早时期的后台的味道。这种实战中要怎么测呢？为什么我说他们有关联性呢。很多情况下，这种站点点击左边的功能栏，一般就是跳转到一个新页面，然后把新页面通过iframe之类的标签，加载到当前页面上（让你感觉自己没有跳转）。

也就是说，我们在index.php里点击一些功能，跳转到user.php或者别的界面。这样就建立起了一个Index.php到其它功能点的联系。要实现这样的行为，一般在前端都要写一些代码的。也就是说，在测试这些站点的时候，当我们通过目录FUZZ，找到了一些能加载的界面，比如后台Index.php，可以通过分析和他有关的一些JS内容，找到和它有关的页面B，然后分析B，又可能找到C... 通过页面之间的关联性，环环相扣，实际上只通过一个页面、一个JS文件，就可以把后台的大量页面和JS找出来，而其中说不定就有一些没做好鉴权的页面或接口。

7.找到JS目录后FUZZ JS文件

在上面我们提到过，比较古早的站点，其JS的名字比较简单，而且有规律可循，可以用FUZZ的思想去打开一些突破口，光说很抽象，我放一张图：

这里强烈推荐一下FFUF这款工具，很快，很自由。比如这里，我在JS目录后面插一个FUZZ，这样去找这个目录下所有JS文件

这样找到后台的一个创建账号接口，这个script.js在前台是看不见的。在进行这个操作的时候，要牢记我们前面说的，注意不同页面、不同JS之间的关联性。

总之，当我们遇到一个比较古老的站点，可以考虑用这种方法，这些比较古老的站点的JS目录一般就是/js /script  /plugins  /content等等，很容易找到，而且其js的名字也比较简单，不像用webpack打包的js，名字中可能会带有随机字符。遇到这种还是能去FUZZ一下JS文件的。

值得一提的是，这种方法对于一些404 403页面是有奇效的，师傅们平时应该也经常碰见这种。有经验的师傅就知道，这种不一定是真的没东西，而很可能是没找到对应的页面，通过目录FUZZ如果找到特定的uri，是能看到新页面的

但是很多时候，如果可访问的页面或者目录名字太过复杂，我们用常规手法不一定能直接找到，通过目录FUZZ只能找到一些名字比较简单的目录，比如我们上文提到的/js /script  /plugins  /content，这种时候可以进一步尝试去FUZZ这些目录下的JS文件，然后从JS文件里找到一些可访问的页面。

8.网站时光机找JS

网站时光机也是一种神技，用处特别多，简单来说这玩意可以获取某个网站的历史页面、url、各种资源文件，其中也包括JS，有一款工具调用各种网站时光机的接口，叫做waymore（需要科学上网）

https://github.com/xnl-h4ck3r/waymore

它大概能实现的效果如下：

目标历史上的页面，js或者其它别的文件，都会被他记录，通过这个方式可以拿到目标历史上的一些js以供我们分析，当然这玩意的用处远远不止于此，你还可以拿它搜集一些正常手段难以发现的子域，搜集目标历史上泄露的一些文档从而发现敏感信息，寻找一些正常手段难以找到的页面，甚至是找到一些复杂用户ID用于越权，这个以后说不定也会专门出一篇文章介绍一下这个神奇的手法。

9.解包小程序拿到JS

众所周知，逆向小程序，解包完成后会得到一堆js和json文件

那我们自然也是可以从这些东西里面拿到各种信息的，用以前介绍的那些提取思路和正则从中提取即可。

10.结语

写完这篇文章感觉挺难受的，平时测试的时候能遇到各种乱七八糟的情况，但是写文章的时候想找回来截图，发现很多案例怎么找都找不到，就算是现成的案例还得打厚码，对观感造成了很大影响。不过也算是分享了一些常用的经验，相关文章就告一段落了。后续在实战中遇到相关的案例，再慢慢以案例的形式去补充吧

原文始发于微信公众号（梅苑安全）：实战中获取JS文件的各种场景