某学习指导网站存在逻辑缺陷Session覆盖

1.登陆账户

账户登陆模块，如果存在问题可能出现绕过防护机制进行爆破账户甚至直接登陆他人账户。

1.1.登陆认证功能绕过

①直接访问登陆后的界面

一般登陆界面登陆成功后会进行跳转到主页面，例如：main.php。但是如果没有对其进行校验的话，可以直接访问主页面绕过了登陆认证。

②前端验证

有时候，登陆状态如果只以登陆状态码进行判断登陆成功标识，那么修改登陆状态码就能进行登录。

例如：对登陆状态抓包

修改这里的code值,修改成1，放行成功登入

1.2图形验证码

验证码的主要目的是强制性人机交互来抵御机器自动化攻击的。用户必须准确的识别图像内的字符，并以此作为人机验证的答案，方可通过验证码的人机测试。相反如果验证码填写错误，那么验证码字符将会自动刷新并更换一组新的验证字符，直到用户能够填写正确的验证字符为止，但是如果设计不当会出现绕过的情况。

1.2.1图形验证码前端可获取

这种情况在早期的一些网站中比较常见，主要是因为程序员在写代码的时候安全意识不足导致的。验证码通常会被他们隐藏在网站的源码中或者高级一点的隐藏在请求的Cookie中，但这两种情况都可以被攻击者轻松绕过。

第一种：验证码出现在html源码中。

这种验证码实际并不符合验证码的定义，写脚本从网页中抓取即可

第二种：验证码隐藏在Cookie中

这种情况，我们可以在提交登录的时候抓包，然后分析一下包中的Cookie字段，看看其中有没有相匹配的验证码，或者是经过了一些简单加密后的验证码（一般都是base64编码或md5加密）

1.2.2图形验证码可识别

这种验证码确实是图片，在前端也没有出现，但是由于没有对其做模糊处理，能够被机器自动识别。

1.2.3验证码重复利用

有的时候会出现图形验证码验证成功一次后，在不刷新页面的情况下可以重复进行使用。

1.2.4出现万能验证码

在渗透测试的过程中，有时候会出现这种情况，系统存在一个万能验证码，如000000，只要输入万能验证码，就可以无视验证码进行暴力破解。引发这样的原因主要是开放上线之前，设置了万能验证码，测试遗漏导致。

1.3短信验证码登陆

有时候为了方便用户登陆，或者进行双因子认证，会添加短信验证码的功能。如果设计不当会造成短信资源浪费和绕过短信验证的模块。

1.3.1短信验证码可爆破

短信验证码一般由4位或6位数字组成，若服务端未对验证时间、次数进行限制，则存在被爆破的可能。

1.3.2短信验证码前端回显

点击发送短信验证码后，可以抓包获取验证码。

1.3.3短信验证码与用户未绑定

一般来说短信验证码仅能供自己使用一次，如果验证码和手机号未绑定，那么就可能出现如下A手机的验证码，B可以拿来用的情况

那么作为一个安全的短信验证码，他的设计要求应该满足如下几点：

①A用户获取的短信验证码只能够供A使用

②A用户短时间内获取的多条短信只有最新的一条能使用

③短信验证码设置为6位数，有效期30分钟甚至更短，当验证码失败3次后失效。

2重置账户密码

重置密码功能本身设计是为了给忘记密码的用户提供重置密码的功能，但是如果设计不当存在任意账户密码重置。

2.1短信找回密码

跟短信验证码登陆类似

2.2邮箱找回密码

2.2.1链接弱token可伪造

这种一般都是找回密码链接处对用户标识比较明显，弱token能够轻易伪造和修改

①基于用户id标识

例如

http://xxx.com/member/getbackpasswd.html?sendTime=MjAxOC0wNC0wNyAxMjozOQ==&userValue=bGlsZWlAdnNyYy5jb20=

这里的明显是base64编码的

sendTime为时间的2018-04-07 12:39 userValue为用户邮箱的[email protected]

知道构造方式了 我们就可以自己构造找回密码的链接了

②基于服务器时间

例如

http://xxx.com/member/reSetPwdCheck.action?email=666@qq.com&startClickTime=20180810105628

这里可以看到startClickTime为20180810105628，我们不确定服务器时间时候，可以在同一时间同时重置账户a和账户b，根据账户a收到的url中token值来推断b对应的值

Ps：这里有一种情况，不是简单将用户id变形，而是融合了精确的时间戳与帐号绑定。例如我的id是1998，现在时间戳是1533892152，合起来是15338921521998。这种看起来有唯一性，但是还是可以通过暴力猜解获得。

2.2.2认证凭证通用性

凭证跟用户没有绑定，可以中途在有用户标识的时候进行修改

2.2.3 Session覆盖

session或cookie的覆盖(它被用作修改指定用户的密码,可能就是用户名),而服务器端只是简单判断了一下修改链接的key是否存在就可以修改密码了,而没有判断key是否对应指定用户名。

先向自己邮箱A发一封找回密码，再向用户B的邮箱发一封，当前浏览器记录用户B的账户信息，然后去自己的邮箱A点击找回密码链接，读取了存在浏览器用户B的账户信息，成功修改了密码。

2.3用户名找回密码

随便输入一个用户 他有一个包检验用户是否存在，这里回显了用户全部信息。

这里的问题在于查询用户处，回显了多余的个人信息。

2.4找回密码步骤缺失

找回密码过程中跳过关键的验证步骤，达到修改别人密码的目的

输入账户和验证码，点击后进入第二步

http://xxx.com/findpwd/step2.do?uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=&type=2

这里qazs1对应用户标识就是

uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=

然后这里理论上是要输入验证码，然后才会有step3，修改密码步骤，实际上是可以进行跳过的

http://xxx.com/step3.do?uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=

这里step3最后一步也有uri参数，可以直接拼接构造就可以完成重置密码的功能。

以上内容转载自(https://anquan.baidu.com/article/301)

0x01 Session覆盖任意注册

我们去注册一个账号走了一遍正常流程，然后从注册这方面开始

如何挖掘到这个session覆盖呢，我们首先准备两个手机号

攻击者:1311******* 被攻击者:171********

(这个被攻击者是某接收短信平台)

首先我们用自己的手机号去获取验证码

验证码是695994 我去修改要注册的手机号，为:171********

会发现成功的注册了这个手机号，只要去设置密码就能注册成功

0x02 Session覆盖任意用户找回密码

我们去找回密码的地方试试，可否使得任意用户修改密码

我们去拿被攻击者手机号测试一下

成功的进行了session覆盖

0x03 Session覆盖漏洞危害

第二次发送给服务端的session覆盖了第一次发送给服务端的session，从而通过了验证，造成漏洞。可以使得攻击者对网站任意用户进行密码批量修改，或者攻击者对该网站进行批量用户注册。

0x04 Session覆盖漏洞修复建议

Session覆盖类似账号参数的修改，只是控制当前Session方式进行重置账号或者注册账号，在重置密码的时候一定要对修改的账号和凭证是否一致进行检测

往期推荐

野草计划：一千种懒人刷洞 第一篇

WebShell免杀之JSP

LangSrcCurise 子域名资产检测系统

本文始发于微信公众号（谢公子学安全）：某学习指导网站存在逻辑缺陷Session覆盖