SSRF引发的血案

渗透能力的体现不只是储备0day的多少，许多站点能否被突破，对本身基础漏洞的熟练的配合利用也是一场考验，故事正是因机缘巧合拿到shell的一次记录总结。

客户给定的地址打开之后就只有一个登录页面，留下没有账号的我在风中凌乱。

一直怼一个登录框也不是事儿啊，没办法，只能先将端口，目录和弱口令先探测起来。

端口基本都开了感觉有点问题，ping 过之后发现有cdn。

很不幸，弱口令没爆出来，目录端口也没有太多的发现，当务之急就是需要一个账号进入系统。但是账号信息该从哪里搜集？？？

等等，项目开始客户是提供了邮箱地址作为报告的提交地址的，首字母大写+名@xxx的格式，和许多企业的命名规则一样。

一边先把人名字典构造起来，一边通过google语法去搜索相关邮箱，相关公司名称，运气不错，从大大小小几十个网站论坛上面发现七八个公司邮箱，和几个qq邮箱。

然后通过一些不可告人的的手段反查到了其中某些qq的绑定手机号，以及历史密码信息。

再次构造相关字典，果然人们都喜欢用类似的密码，撞库成功。

进入后台后，挨个测试了一遍功能点都没能发现getshell的，上传也没能绕过后缀限制。

都说没有getshell的渗透测试是不到位的，只发现一些中低危漏洞可没法满足。

因为没有太多的收获，于是挨个访问之前dirbuster跑出来的目录，其中一个页面访问之后会有一道黑影一闪而过，然后跳转到登录页面，猜测做了权限验证，然后强制跳转了。

测试中有很多时候都可能遇到无权限访问的情况

当我们遇到访问403，401，302，或是弹框提示无权限可以尝试一下以下的办法。

GET /xxx HTTP/1.1 403

GET /xxx HTTP/1.1 403

302跳转：拦截并drop跳转的数据包，使其停留在当前页面。

前端验证：只需要删掉对应的遮挡模块，或者是验证模块的前端代码。

这里使用burp拦截一下，扔掉后面的跳转，看到如下界面，弹窗还是提示没法访问，权限不够，但是和之前的访问403不一样了，难道是我使用了普通用户登录的缘故？？？

熟练的打开F12开发者模式。删掉前端代码看是否能使用他的功能。