验证码绕过(burpsuite)

**Pikachu是一个带有漏洞的Web应用系统,

**在这里包含了常见的web安全漏洞。通过一些资料认识这个练习的靶机平台。练习需要的条件是自己首先在电脑上下载并安装相关的工具。Burp suit、Phpstudy(利用火狐或者谷歌等浏览器访问pikachu的网址127.0.0.1),fire proxy omrga插件。Pikachu目前的漏洞类型有16种类型。
Burte Force(暴力破解)“暴力破解”是一攻击具手段,在web攻击中,一般会使用这种手段对应用系统的认证信息进行获取。 其过程就是使用大量的认证信息在认证接口进行尝试登录,直到得到正确的结果。 为了提高效率,暴力破解一般会使用带有字典的工具来进行自动化操作。理论上来说,大多数系统都是可以被暴力破解的,只要攻击者有足够强大的计算能力和时间,所以断定一个系统是否存在暴力破解漏洞,其条件也不是绝对的。 我们说一个web应用系统存在暴力破解漏洞,一般是指该web应用系统没有采用或者采用了比较弱的认证安全策略,导致其被暴力破解的“可能性”变的比较高。 这里的认证安全策略, 包括:(1.是否要求用户设置复杂的密码;2.是否每次认证都使用安全的验证码(想想你买火车票时输的验证码~3.是否对尝试登录的行为进行判断和限制(如:连续5次错误登录,进行账号锁定或IP地址锁定等);4.是否采用了双因素认证;)

**验证码绕过on client(客户端)的问题。

**什么是验证码?验证码(CAPTCHA)Completely-Auto mated Public Turing test to tell Computers and Humans Apart”(全自动区分计算机和人类的图灵测试)的缩写,是一种区分用户是计算机还是人的公共全自动程序。可以防止:恶意破解密码、刷票、论坛灌水,有效防止某个黑客对某一个特定注册用户用特定程序暴力破解方式进行不断的登陆尝试,实际上用验证码是现在很多网站通行的方式,验证码用来登录暴力破解,还可以防止机器恶意注册。需要搞清楚验证码的认证流程,客户端request登录页面,后台生成验证码(1.后台使用算法生成图片,并将图片response给客户端2.同时将算法生成的值全局赋值存到SESSION中),然后客户端将认证信息和验证码一起提交,后台对提交的验证与SESSION里面的进行比较,最后,客户端重新刷新页面,再次生成新的验证码,验证码算法中一般保含函随机函数,所以每次刷新的验证码都会改变。在on client中的操作,我们去验证它的接口是否存在可以暴力破解它。我们先随便如入一个账号和一个密码,不输入验证码或者输入一个错误的验证码提交它,会提示输入的验证码错误。所以必须要输入验证码才可以去提交它。之后我们输入正确的验证码,点击Login。下面出现提示用户名或密码错误。因为验证码时刻都在变我们无法对它进行暴力破解。他是否安全,这是未可知的。利用Burp suit抓到的数据包我们可以在Bp中可以看到里面有一个破解请求,提交了账号和密码,后面多出来一个验证码,返回pikachu的页面,查看源代码,看到页面是由Html、javascript写的,在页面的最下面看到定义了一个全局变量通过写函数去生成验证码,验证码是从字符串中0-9和A-Z中随机的抽取,一旦函数被调用,执行后面的语句去生成验证码。在验证码的表单中找到代码,看到on client,发现你只要在前端页面点一下验证码就会立即生成新的验证码,所有验证码的生成及验证都是在JS在前端做的,从安全的角度来讲,在前端用JS写验证码是不靠谱的把数据包发送到数据存放的repeat中,我们可以自定义的去修改发送过来的内容,修改完之后点击go,它会把修改的数据包重新发送到后台,来测试整个验证码是不是有效的,看html反馈的信息,砍到后台并没有验证。再将数据包重新发送到intruder,修改变量,选择我们收集的字典,发送请求,排序,会发现验证码对应的账号和密码,这时就可以知道在前端用JS写验证码,仅仅是在前端展现(纸老虎),在后端并没有发挥作用。得出结论可以被绕过。还有就是在请求验证的过程中后端会生成验证码,同时应该要以图片的形式展现在前端,而不能以字符串的形式,一些系统仅以文本的形式将验证码响应到cookie中或页面去,会被前端的HTML读取到。即使可以在后端验证,但攻击者可以在前端写一个脚本去刷新这个页面,先把输出的验证码获取到(意味着你的验证码已经提前泄露了)。这是我们在实际的应用系统中比较容易出现的问题。

**验证码绕过服务端的问题。

**主要表现在验证码在后台不过期,导致可以被长期使用;验证码校验不合格,逻辑出现问题;验证码设计的太过简单或有规律,容易被猜解。我们在pikachu上面和前面的验证码绕过客户端一样,先测试验证码的有效性。BP保持抓包的状态。查看抓到的数据,看后台有没有对验证码去验证。发现验证码是会验证的。首先,刷新前端页面,会看到新的验证码。我们不去提交它,把它记下来到数据包里面将验证码改成正确的验证码,后台会反馈账号或者密码错误。我们再改另外一个账号或者验证码,提交,发现后台还是提示账号或验证码错误,说明验证码是有效的。得出结论这个验证码是一直可以被用的。利用这一点可以进行暴力破解(自己收集的字典),发送请求,后面的操作和验证码饶过客户端一样。破解出响应的账号和密码。前端页面查看源代码发现验证码的反馈是根据所写的函数你所提交的验证码和”SESSION”对比。问题主要在后台PHP设置的验证码过期时间。

防暴力破解的措施和防范误区总结

:设计安全的验证码(安全的流程+复杂而又可用的图形);对认证错误的提交进行技术并给出限制,比如连续五次密码错误,锁定两小时;必要的情况下,使用双因素认证。

发布了65 篇原创文章 · 获赞 4 · 访问量 1万+

猜你喜欢

转载自blog.csdn.net/gl620321/article/details/94834051