1.前言
本文大体完成于去年，是由某金融SRC的案例修改而来，由于涉及一些敏感信息，所以部分细节略有修改。整个案例还是很有意思的，从一个页面到另一个页面，从一个JS到另一个JS。
2.目录FUZZ到JS接口分析
首先本文的攻击场景是一个登录框
看到这，很多师傅应该会很开心，看起来没有验证码，那不是妥妥的喷洒+爆破拿下吗？但实际上并不是，密码错一次就会出验证码
好吧，有验证码又如何呢，我用验证码识别插件操作一下不就行了？
实际上不行，测试之后发现，这里这个接口有密码错误次数进行限制，并且验证码+错误次数限制都没法绕过去，所以在这个接口爆破喷洒肯定行不通了。
那么还有什么办法呢？这时候就可以开始想想分析JS找接口了，但是不行啊，这里没有webpack，而且这里的JS文件都是这种的：
有经验的师傅应该知道，这种JS文件找不到什么接口的，所以JS分析这条路也断了，那接下来只能去目录FUZZ了呗。
天无绝人之路，目录FUZZ发现这个站点存在目录遍历的问题
而在众多目录中，我发现了一个与众不同的目录
在该目录中，有一个wechat目录，当我访问这个目录，会重定向到一个页面
看似一片空白，但在这之下，我看到了熟悉的webpack：
那么接下来就是分析了
3.从JS分析再到JS分析
有webpack，那找到接口的可能性大大提升了，在这里，我提取出了六七百条接口
但是令人震撼的是，这些接口居然全部鉴权，一个能用的都没有
所幸，这其中有一些前端的web界面，我们还是可以访问到的，虽然这些界面上的功能我们也一个都用不了
好吧，那么此时要怎么破局呢，我对这些新页面又细心研究了一波，发现其中有相当一部分是有一些新的JS文件的，比如：
有新的JS文件，意味着可能有新的接口，有新的接口就可能有新希望，我统计了一下存在新JS文件的页面，并且对其中的JS文件进行了分析，然后找到了一些新的接口，而在其中，我终于发现了少量未鉴权的接口
其实说实话，这两个接口我一开始只测试了/API/rfid/GetAssets，因为另一个带login，我以为和登录口那个登录点一样，有验证码，那就没有测试的必要，但是GetAssets接口的参数怎么都FUZZ不出来，最后我极不情愿的去研究这个Login接口了。
在研究它之前，我特地去看了看登录界面的接口是怎么样的，然后我惊讶的发现，他们从接口路径来看实际上是完全不同的
也就是说我那个新的登录接口，或许并不像登陆界面的接口一样这么严格。我对这个新登录接口进行参数FUZZ，很简单地发现了它的参数
这里说个趣事，实际上这个点是有验证码参数的，但是不加也没事，于是就这么简单的被我绕过了。
然后就是愉快的密码喷洒环节了。
4.虚惊一场的密码喷洒到进入后台
密码喷洒非常简单，非常顺利，固定密码为123456，喷洒出了大量用户，其中不乏部门管理员
正当我兴致勃勃拿着弱口令去登录时，却发现一个都登不上
是的，在另一个接口登录成功，但在这个接口却不行，这时我都欲哭无泪了。那还能咋办呢？这时候我开始认真分析起了两个接口地返回包：
如下是登陆界面接口的返回包：
如下是fuzz出的新登录接口的返回包
注意观察我们是不是少了点什么？没错，两个接口实际上是极其相似的，唯一的区别只在于，登录页面的那个接口，多了一个返回值，也就是”issuccess”，那如果我们替换返回包，并且在其中也加入这个返回值呢？
成功登录后台！
5.结语
本文主要是作为一个引子，引出以后可能发布的JS分析系列，JS分析的各种姿势还是非常重要的，在不同场景下，都有哪些方法、工具、思路去获取js文件，比如登录点场景、后台场景、SSO场景、Webpack场景、目录以及JS文件FUZZ场景、小程序解包场景等等。以及我们拿到JS文件之后，其中可能有什么与安全有关的重要信息、我们要如何提取这些信息，这些都是很有意思的知识点，如果只用findsomething或者packerfuzzer之类的工具，是绝对无法应对上述的各种情况的，无疑会错过一个亿，在长期挖掘各家企业src的经历中，笔者也是总结了大量特殊场景下的JS获取以及分析思路，后续也会整理成一个系列的文章发布出来，欢迎师傅们关注。
原文始发于微信公众号（HW专项行动小组）：某金融src的一次较复杂攻击链进入后台
