几乎每个系统都有各种各样的验证功能。一些常见的验证功能包括帐户密码验证、验证码验证和JavaScript。

数据验证和服务方数据验证等，程序员在验证方法中可能存在缺陷，因此有验证绕过的漏洞。各大安全社区的师傅已经发表了更详细的漏洞介绍，在此不再说明。

昨天晚上没事，回顾自己Edusrc的历史脆弱性，看到某个注入绕过修复，顺便进去了。利用以前的绕过手法进行注入被拦截，真的修复了~有些懊悔的理由，继续挖掘这个网站的脆弱性。打开网站:http://xxxxxx.xxxxxx..info/login.do仍然是熟悉的注册框，文章开头的文章注被修复了。

大多数人的想法可能是:

1.暴力解读。

2.抓住登录的POST包注入。

另外，面对这个登录框，试着利用上次注入的密码登录失败(但是正常，一定会改变)。试着注入(修复.修复方法:加密输入的帐户密码，判断是否正确，如果不是RSA，直接返回False)，直接切断后路不，不，跟踪Js。看源Js文件时，找到login.min.js，推测是登录相关的接口文件。我们继续跟踪具体内容，有些内容Unicode代码，能够在网站上方便。分别访问，第一个是登录验证，跳到文章开头的登录点。访问第二个接口时，闪烁背景框架到达空白接口。逻辑问题可能不能从js直接判断，但是通过js访问的这个界面，菜x的第六感告诉我这里可能有问题。分析这里的Js.预计问题点可能是这些。

你为什么能访问这个背景框架？我确信这里一定有问题。联想到以前定义的三个变量。根据我的理解，变量定义没有问题。但是，这里好像只验证了loginId，也就是a。其中，根据Js的判断可能会出错，但Js确实只判断a，直接获得后台url。然后，追踪此分析进行测试，帐户输入admin密码自由。一般来说，按照Js的逻辑进行，输入正确的用户名称，即刚才提到的a.手动访问刚得到的后台接口地址时，直接获得admin这个用户的所有权限。很明显，只验证参数A.成功进入后台。

背景有很多功能点，文件上传没有被验证。然后是一个普遍的过程。验证功能一直是各系统不可或缺的重要部分。我们在平时的渗透测试中遇到的各个功能点的验证部分能够更加细心地进行测试。不是看到密集的代码手脚不方便，而是细心地发现突破口吗？