zoukankan      html  css  js  c++  java
  • 逻辑漏洞破解手机验证码重置用户密码——纯数字的可以考虑爆破、另外可以考虑直接抓包可以获取验证码(有逻辑漏洞)

    逻辑漏洞破解手机验证码重置用户密码

    from:https://www.xf1433.com/4275.html

    找回用户密码几乎是每个网站都有的功能,漏洞点也非常多,功能开发起来容易,要做好安全的防御机制需要投入更多精力,比如小风教程网为了保护用户的绝对安全,就干脆把找回密码的功能去掉了,用户想找回密码只能通过客服反馈。

    首先是最暴力的验证码暴力破解漏洞,很多公司系统提供的功能点,都是有忘记密码的功能的,所以这一点就很方便我们做出测试。

    验证码暴力破解

    我们来看下图的页面,这是现在还有少数厂商存在的漏洞,4位验证码,但是一般的有的厂商会有4位验证码但是会做防护,但是下面的这个我今年新挖的就是没有防护,可以被暴力破解,然后成功重置该用户的密码。

    需要验证码

    验证码暴力破解

    然后就成功破解出来了,下面还有一个现在大多数厂商的6位验证码,才是困扰我们的难题,但是6位验证码也是可以破解的。要破解6位验证码是一项大工程,所以我们就要确定两点
    1.它这个地方是否限制了访问过快的暴力破解banip
    2.它这个地方是否有错误太多就出现验证码的功能
    3.最后就是它这个6位验证码的时效性了
    我下面举的例子就是它的验证码时效性较长有30分钟

    时效性

    暴力破解

    如图其实暴力破解6位验证码如果时效性够长的话就可以破解,因为毕竟如果成功就是能够重置用户的密码,这种危害性还是较大的。厂商都比较重视。
    如果它的验证码时效性较短比如,5分钟,或3分钟,这时候你就要确定一个界限,确定你的电脑在3或5分钟最多能爆破验证码的个数,然后你确定这个界限,发送验证码不断的尝试,它的验证码总会有发到你这个界限里面的,然后你就能暴力破解了,也不要嫌弃麻烦,毕竟暴力破解,重点就是暴力嘛

    构建回显包绕过

    回显包也是,现在很多厂商也是拿这个包里的内容返回给页面,靠这个信息来判断这个验证码是否正确,来进行绕过的。如下我这是举出一个我最近挖出的例子,它这个就构建的很简单,页面仅仅靠包里的0和1来判断验证码是否正确。
    当然还有很多形式 比如 true or false 之类的,总之遇到这样的我们就要多去判断一下 ,当然有一个前提条件,你得知道正确的验证码的回显包,这样你才能去修改欺骗web页面。

    构建回显包绕过

    如下图都是一些厂商常用的靠返回包里面的内容来判断验证码成功验证码成功的数据

    判断验证码成功

    代码

    当然修改完成我们还要走一步,就是重置新密码。
    因为只要最后一步成功的话,这个漏洞才能生效,笔者就踩过不少的坑,测试到重置密码的界面就以为成功了,结果被人家驳回,再去试一次才知道,这个也就是自己骗自己了。。。所以大家在测试的时候一定要细心走到最后一步去看是否成功。测试切记莫心急

    重置新密码

    缺陷的验证码验证

    Emmm这处的功能,怀疑是开发的锅了。这里的笔者也就看到一处,当时测试还没注意随便输入忘记抓包,结果就成了,真是惊喜来的太突然。
    如下图,大家看见,我直接输入验证码为111111,就直接显示最后验证码重置成了,emm这个漏洞也是可遇不可求,当个怀念吧。真的就是自欺欺人啊。所以这也是告诫大家再测试,多想几方面,万一它的验证码是个幌子呢对把

    缺陷的验证码验证

    验证码直接在返回包处可见

    这一处漏洞也是迷幻程度不堪上下,所以说当我们测试的时候多看看返回包里的内容是有好处的,看下面包里面的内容,很多厂商都有手机登录对吧,而且下面的这个厂商直接把验证码内容放在了返回包中,然后再由页面去认证,这一部分被我观察到了,就造成了可以登录任意用户的漏洞了。
    1570,多么美好的数字呀。而且我们可以观察到,它这个验证码还是4位,这意味着我们还可以通过爆破验证码来登录任意用户,只要它这处没有做出限制就行。

    验证码直接在返回包处可见

    还有一处验证码出现在返回包里的,但是这处比较奇怪因为它不是出现在本次发送验证码的返回包里,而且当你再次点击发送验证码的按钮的时候,你再次抓包就会发现,这次的包中出现了验证码,而且跟之前一次的你收到的验证码一样。所以当我发现这一处的时候,我就想到了一下步骤
    我先点击一次发送验证码,收到验证码了,但此时我不知道
    然后我开启抓包再次点击发送验证码的按钮,然后丢弃此包,让服务器端接受不到发送验证码的请求。这样我就能成功找到了,我上一次验证的正确验证码,然后输入就能成功验证重置密码了。
    当我们在测试的时候要对code这种命名的格外在意,万一就能行对把,而且下面的还是用了加密处理,正好md5能成功解开。

    抓包

    md5

    最后一步可替换重置密码用户

    这一处漏洞,其实也是开发最后一步放松了警惕,没有去把验证码和重置密码的用户绑定在一起,到最后一步只是单纯的验证了是不是验证码正确。然后用户直接输入新密码即可。
    结合我这个漏洞,其实的话就是最后一步它已经验证了验证码正确,等于过了最后一道安检,然后当我测试我看到出现手机号,和此手机号的id我就知道有机可趁,这个uid的值是可以遍历,所以我们只需要确定手机号,就能从最后一步修改任意用户的密码了。

    替换重置密码用户

    看如下图那样,最后一步系统没有做任何检验它这是检测了cookie里面的内容,而且和我们post提交的参数没做任何绑定,所以导致我们可以修改任意用户和它对应的id值

    修改任意用户

    其实这里还有一处,有时候越权重置他人的用户密码,我们最需要关注点我觉得吧就是看最后一步,看他是否从一开始就绑定了你这个用户,不能修改。同时你也要主要观察包里的参数,url的链接这一点很关键。

    可跳过验证码验证步骤

    这里的一处是刚刚测到的。因为是某大学的不方便贴的仔细只能简述一下过程
    首先是输入用户名,这里我们输入要重置对象的用户名,然后到第二步安全验证

    可跳过验证码验证步骤

    然后到了第二步,它是给邮箱发送了验证码,这里我查看了页面源代码发现很可疑的一点,就是这里出现了一个从没有出现的userid值,这让我抱着疑惑的心情,接着测试,我发现观察页面源代码我看见了,一处它这里的重置密码是分步骤也就是url是这样的 passwd1/2/3 所以我就直接在url处加了3跳到了最后一步,不过因为没有输入验证码,导致验证不完全,最后一处页面发送错误,不过不影响,我尝试一下输入新密码抓包

    新密码抓包

    userid值

    抓包之后,大家看到这个userid值是不是很眼熟,没错正是第二步页面源代码里的userid值,只要我们将之前获取到的贴进去,就可以成功重置这个用户的密码了。它这里也算是页面的缺陷,我估计应该是当你输入正确的验证码,这个userid的值会跟着用户一起进入页面3,然后当你输入新密码的时候,这个页面就会把userid值带着证明重置的是这个用户。

    验证码重置链接可以伪造

    重置密码的时候,我们大家也可以经常遇到邮箱验证叭,此时厂商总会去给你的邮箱发送一个邮件,然后点击这个邮件带的链接去重置的密码,这时候当我们知道这个邮箱链接url的构造,并且我们能成功伪造的话,我们就可以重置用户的链接了。正如下图所示,它这里的链接带了一个mun参数,所以让我想一下这个一看就像md5啊

    验证码重置链接

    md5去解密一下,果不其然解密出来就是我们的用户名,这样我们就可以清楚了它这个的逻辑了,classid是你用户名对应的id值,而mid的值则是代表了你是系统发送的第多少次验证码,所以我们知道了这个url的链接构造,并且能成功的去伪造,我们就可以重置用户的密码啦。

    md5去解密一下

    总结

    测试逻辑漏洞,虽然逻辑漏洞被认为是最简单学习的漏洞,可是并不是非常容易找到的,测试逻辑漏洞就是要心细,对包里的每个参数,都要有一番自己的估计,不断的去仔细的走每一步的步骤。去观察包里的参数变化,这样能帮助你更好的发现逻辑漏洞。
    然后这里我提出一个观点,当你测试密码找回的时候要注意去看每一步页面的js代码,和它的页面源代码,说不定你可以从中获取到一些意想不到的信息哦,还可以判断出它密码重置的代码逻辑。

  • 相关阅读:
    ODAC(V9.5.15) 学习笔记(六)TOraSQL、TOraTable和TOraStoredProc
    ODAC(V9.5.15) 学习笔记(五)TSmartQuery
    ODAC(V9.5.15) 学习笔记(四)TOraDataSet
    ODAC(V9.5.15) 学习笔记(四)TCustomDADataSet(5)
    ODAC(V9.5.15) 学习笔记(四)TCustomDADataSet(4)
    Cesium原理篇:7最长的一帧之Entity(下)
    Cesium原理篇:7最长的一帧之Entity(上)
    Cesium原理篇:6 Render模块(6: Instance实例化)
    Cesium原理篇:6 Render模块(5: VAO&RenderState&Command)
    Cesium原理篇:6 Render模块(4: FBO)
  • 原文地址:https://www.cnblogs.com/bonelee/p/15196016.html
Copyright © 2011-2022 走看看