从0到n，登录框实战测试
区别于其它登录框漏洞分类文章，本文从实战出发，根据经验，从各种可能情况带你打完一个登录框。
开局一个登录框，你能打多久？
指纹识别找漏洞，弱口令，爆破，三板斧就没了吗？
在现在这种web环境下，如何对登录框进行深入测试？在此我将自己带入实战环境，结合经验，从多种情况讲述测试的完整思路：
拿到一个登录框，首先就是利用工具做指纹识别找历史漏洞，目录端口扫描，尝试弱口令，对账户密码处进行sql注入测试这些常规操作，现在sql注入还是有的。如下，登录页面存在sql注入：
在修改密码处对发验证码的电话号码进行抓包，发现也存在sql注入，因为一个系统对数据的处理多半采用的一套代码：
当然再修改密码处如果存在验证参数，可以考虑将其：置空，删除参数，设为NULL值。或者修改返回包状态直接跳过验证，进入下一步。
这里讲一点xss测试思路，对xss的测试记住一句话：一切可控参数能在页面回显均可尝试！
看看下面这个登录框：
哪里可以测xss?
我任意输入账户密码后出现如下页面：
这个很简单就是errorname参数可控，插入payload实现注入
除历史漏洞外还可以测试shiro反序列化，log4j对登录处的RCE，但现在经过多次护网，这类漏洞很少见了，不过shiro的权限绕过漏洞挺有效。
它的原理就是;截断，shiro鉴权时检验;前半部分，而springBoot处理URL时返回的是;后半部分。也就是/admin/处，导致成功访问后台请求。
而且在做测试时，你基础知识得扎实吧，还得了解struct2,spring这些框架识别及其漏洞。
常规操作完后就是对登录框进行深层次分析：
首先分析url。
看路径是否含有#，对这种登录框，它的前端代码一般是能从js文件中看到的。可以通过关键字搜索（例如:admin,password,github,accesskey等等）
通过这些关键字去找前端验证逻辑，是否存在敏感信息，例如账号密码，是否是开源框架，或者直接泄露ak,sk，那就直接尝试接管云主机。
像上面这个ak为LTAI开头的应该就是阿里云的，直接行云管家输入ak接管。
关键字搜索完后，还可以通过工具提取大量js路径，再批量扫描测试，注意get，post方法都试一下！！！
对于js的提取，所有现存提取工具它的逻辑都是基于一定规则去匹配提取，要想挖到别人挖不到的漏洞，你就可以自己去修改工具规则。
不过在提取完js后，去批量跑js时可能会遇到一种情况，就是跑的路径全部404，像这种情况很可能就是提取出来的路径需要放在某一特定接口下，例如/api/，/system/ 等等，这种东西是工具提取不出来的，这就需要你分析现有路径（F12刷新页面看网络，bp历史数据包），找到特定接口放到域名端口后再跑。
这里就谈到一点，对url路径的分析。
可以尝试google百度这些搜索用户手册，或者用字典爆破去找api文档，拿到文档后可以寻找可用接口，测试未授权，或者通过分析文档中的路径规则进行FUZZ。
尽量不要去做没有信息基础的FUZZ，包括在进行密码爆破时做特定字典，或逆向js找加密函数，写脚本将密码全部转换后爆破。这些是在迫不得已才去做，不然别人打众测拿分，你在那写半天脚本，结果密码还没跑出来。
看过上面的路径（上述路径我均没测出来）后你应该知道该怎么去FUZZ了吧。再次强调，注意get，post方法都试一下！！！（可以同时bp配合HAE搜集更多信息）
成功案例：
我觉得在现在这种web环境下，难的不是怎么测一个漏洞点，而是怎么找一个漏洞点。（在测试时一定要对参数及参数值敏感！）
例如.do,.action,Pwd以及看起来可能没有规则的长串字符等等，例如那些长串字符可能它前面一段字符都是固定的，只有后半部分在改变。
在跑js时还可能遇到下面这种情况：可使用，但缺参数。
这种情况我的建议是要么FUZZ要么换......
不过运气好有些缺参数的接口可能是会将参数进行回显的，这种情况FUZZ就会更加轻松。
在FUZZ时还有种情况：一二级目录都没权限，但后面就有权限了。
在上述方法跑js或者直接遇到一个登录框，还有个麻烦就是权限问题。
常见思路就是利用403bypass工具或者自己修改返回包。（当然JWT出现了，你也得认得出来，能操作一下吧）。
返回包修改如果为前端验证就可能绕过，这种垃圾设计现在还是有的，我最近就遇到过一个修改返回包body的0为1直接进后台。只是那个登录框现在不知被我丢哪去了。
除此外，还可能遇到点进页面后台一闪而过，或者直接显示未登录状态的。
上述均可采用修改返回包的思路，一点点放包找302跳转页面改为200或者丢弃来完成绕过，或者bp抓包，一点点放包来查看后台。
除了修改返回包，还可以利用js，我遇到的大多数登录框都是只有登录功能的，但如果你找到了注册的接口，FUZZ参数后能完成用户注册，也可以尝试拿注册用户的凭证来进行登录。
或者修改访问IP为127.0.0.1，制造自己访问自己的假象完成绕过。
还可以分析登录框的版本，比如你想进后台，但高版本打不动，你可以拿这个登录框的ip在fofa搜索，看这个后台是否还有对应的低版本登录框没处理干净，找到了，甚至弱口令就能进。
有些甚至直接将账号密码写在了页面，直接输入验证码即可登录
这种可能是测试页面未关闭，在做端口映射时将测试页面展现出来，同时带上了账号密码。
再者就是查看源代码继续看版本历史漏洞，或者是否为开源项目等等。
同时还需要在源代码或者js文件处注意是否使用编辑器（关键字：Ueditor，kindeditor，Fckeditor，ewebeditor等），如果有，还可以从编辑器漏洞的角度出发，这样攻击面又被扩大。
如果登录框为小程序页面，直接抓包域名转web页面测试，思路如上。不过在小程序中，还可以寻找是否存在点赞，关注某人的功能，抓包看返回包是否含有他的凭证，如果有可以尝试拿凭证去进行登录。
以上方法实在不行还可以尝试爆破，根据域名，归属公司名这些做专用字典进行爆破。
不过很多登录框是限制了爆破次数的，限制逻辑一般就是根据就是你本地环境有什么信息（什么信息会上传到服务端）。
因此可以尝试：
修改为随机IP
随机UA头
Referrer头 127.0.0.1
进行密码喷洒
修改设备信息例如固件等
或者遇到在http头里加一段随机的，后端给的参数来识别爆破次数，就可以通过脚本先获取随机数再请求等等。
攻击面大小由功能点多少决定，如果有那种可直接注册的登录框，测试点又会多很多，例如短信的轰炸，验证码爆破或回显在数据包，万能验证码，任意用户注册等等
上述全试完还不行就换目标吧，换着换着就出洞了......