登录框系列最后一篇，半年的准全职赏金猎人的生涯，算是水到渠成的一篇，这一篇每一个类型都将配一个这半年来我所发现的漏洞当作案例。
0×00 文章内容结构图
0×01 管理后台隐藏的注册接口
很多系统的后台会用一些本身存在注册功能，但是在后续正式使用的时候，开发人员为了图省事，仅仅删除前端显示的操作。也就是说该系统注册接口仍然存在，只是你在客户端无法找到而已。
案例
这是某系统的管理后台，除了我们所看到的以及HTML源码，js代码均为发现其他有效接口。
此时，我手动将login修改为reg，没想到中奖了。
很简单的尝试，最终让我获得了2500元的赏金。
一般来说我会尝试像reg、register、sign字段，这些字段直接记住手动测试即可，都没必要用字典跑了。
再来看另一个案例：
这个时候我们就要灵活变通了，根据开发人员的命名规则来进行测试，此时我们应该尝试的便是：Reg、Register、Sign。
0×02 目录遍历
当资产仅仅只有一个登陆框时，一定要花费两秒钟的时间来测试这个目录遍历漏洞，讲真，真的只需要两秒钟。
案例
第一秒：直接按快捷键 Ctrl+U（查看页面源代码），讲真，不要再右键点击了，太慢。
第二秒：直接访问https://domain/static/，不要问我为什么直接访问static目录。这个漏洞的确认没必要用路径扫描器去扫。
此时只需要了两秒钟，一个目录遍历漏洞便确认了。后续的则是想办法找敏感文件来扩大危害了。
最后，找到了该系统的备份文件，很常规的一个备份文件的目录，backup。
不过这里有趣的时，遇到了其他困难。
找到数据库配置文件api\app\config\database.php
可以看到加密了，使用了网上的phpjm加密，解密比较费劲，不过过了一会我想到，根本没必要解密。
通过封装的数据库文件可以知道database.php文件使用变量$db来存放配置信息。
我只需要新建一个文件，然后包含database.php文件，再打印出配置信息来即可。
除去后面代码审计出来的漏洞以外，这个漏洞获得了4000元的赏金。
0×03 三端逻辑处理不一致导致的问题
这里的三端只是一个虚词，并不是非得三端，可能是两端，也可能是四端，只是这里我的案例是三端的原因：web端、app端、小程序端。
就像是木桶原理，你的站点web端做的安全系数可能很高，但是你的app端、小程序端如果很烂的话，依旧可以让人突破进去。
案例
首先这个站点我先发现的是web端，其次是app端，最后则是小程序端。
我在web端跟app端用了很多时间，最后突破点是小程序端，发现小程序端以后，则用了很短的时间。
Web端安全系数最高，在登陆时，用了rsa加密，没法直接爆破，并且用了token校验。我手动试了一下，没法确定用户名，只能得到一个【用户名或密码错误的提示】。
后来我发现了app端，发现app端有图形验证码，并且是有效的图形验证码，我试图通过该apk文件包含的js代码来入手，无果。
最终我发现了微信小程序端，在登陆时由于图形验证码是客户端刷新，因此可以直接进行数据包重放。
确认用户名是否存在非常重要，这个时候我一般会先输入一个一定不存在的用户名进行尝试，可以看到，竟然提示了【账号不存在】，最终我通过该处枚举出了多个用户名。
然后我进行了简单的爆破尝试，未果，此时我拿着正确的用户名去尝试app端时，发现了另一个问题。
当输入正确的用户名时，竟然会将该用户的基本信息返回过来，包括但不限于姓名，部门，密码的md5值。
我用拿到的账号密码登陆成功了web端、app端、小程序端。
最终获得了1400元的漏洞赏金。
0×04 从系统帮助文档进行突破
当资产只有一个登陆框时，确认用户名信息则显得至关重要，通过系统的帮助文档，可以快速的帮我们确定用户名的规则及密码的规则。从而可以有针对性的进行爆破。
案例
如下图所时，这个系统我放弃了一次又一次，在登陆时会先校验公司名是否存在，但是我却连公司名都不知道，更不要说用户名了。
我发现这个系统用的是非自研的系统，因此我通过蛛丝马迹（恕我直言，我不能说），结合google语法，intitle:XXXX，发现了该系统的一个测试系统，该测试系统使用了另一个域名，于是我通过site该域名，发现了该系统的一个帮助文档。
通过下图，我获得了，公司名的命名规则。
通过下图，我获得了密码的规则，至少6位，2/3原则。
使用了正确的公司名后发现了，发现存在用户名枚举漏洞，然后我写了一个脚本，原理就是三重循环。
公司名 – 用户名 – 生成的该用户符合规则的社工型字典。
很快，大约30秒，第一个用户的密码就出来了。
我使用的是用户名+123456的形式，既符合规则，又好用。
登陆系统后发现了很多漏洞。最终也是获得了6000元的赏金。
0×05 从js文件进行突破
讲真，我是真的很喜欢读js文件，因为它经常给我带来惊喜，接口信息、命名规则等频率是极高的。
案例
如下图，看到下图的时候，我小心_脏噗通一跳，哇咔咔，竟然没有校验旧密码。
于是我构造数据包。对了，有一个技巧，其实不用构造数据包，直接将我红框标记的区域复制出来，粘贴到开发者工具，js的控制台里，然后替换userCode变量跟password变量回车抓包即可。
我推测存在admin用户，果然推测成功。
最终顺利登陆后台，赚的2000元的赏金。
0×06 其他
当然还有很多其他类型的，如apk重编译突破登陆限制、图型验证码dos攻击、历史漏洞、Http Request Smuggling等。
我便不再说了，网上很多资料。打算完结了，也不会再写啦。
0×07 综合
说一个综合的吧。我这个漏洞是利用了web端跟pc端处理逻辑不一样，然后通过pc端js文件发现了密码规则（这不是一个单纯的名命规则）及可用来枚举用户名的接口来进行突破的。
案例
Web端非常安全，我通过fuzz目录，xxxx.jsp，发现了该站点的一个app下载地址download.jsp。
这个PC端跟web一样存在图型验证码，只不过web端的图形验证码无法绕过，但是pc端的图形验证码可以通过删除该字段的值进行绕过。
但是，不管用户名是否存在，反馈都是一样：账号不存在或密码错误。
这个站点我放弃了很多天，因为js文件实在是太太太太大了，除了大还有别的障碍，总之就是一句话，读起来费劲。
最终我还是一段代码一段代码的读了。
如下图，原始功能是，用户改变自己的在线/离线状态。
这个接口导致我可以在未登陆状态下，通过账户名加在线（1）离线（0）来根据响应包判断出用户是否存在。
如果用户名存在，那么res的值为1（即切换状态成功），如果不存在那么值为-1
通过下图，可以得知密码的名命规则，字母+数字+特殊字符，最短8位。
这样的密码规则，确实难爆破，我心中一凉。
但是峰回路转的是，我看到了以下代码。
于是我推测，可能是因为后台的某些功能，导致会存在不符合规则的密码存在，使用这些不符合规则的密码进行登陆时，依旧可以登陆成功。
window.loation.href= main_url;
于是我用枚举出来的几千个账号，尝试123456的密码。最终成功登陆了PC端跟web端，结合其他福利获得了2300元的赏金。
对了，再补充一下，通过删除图形验证码的值绕过校验的截图。
0×08 临别
最后分享我师傅送我的一句话：在路上点滴挪步，不骄不躁。
对啦，容我再打一个小广告，哈哈哈哈哈，喜欢相互分享的同学，很乐意各位加入我们米斯特安全团队，这里有着每个人各种各样的分享。
*本文原创作者：丶楼兰