随着社会及科技的发展，众多传统行业逐步融入互联网并利用信息通信技术以及互联网平台进行着繁复的商务活动。这些平台由于涉及到大量的金钱，个人信息，交易等重要个人敏感信息，成为了黑客的首要目标，但是由于开发人员的安全意识淡薄，常常被黑客钻空子屡屡得手，给厂家和用户带来巨大的损失。

相比SQL注入漏洞、XSS漏洞、上传、命令执行等传统应用安全方面的漏洞，现在的攻击者更倾向于利用业务逻辑层面存在的安全问题。传统的安全防护设备和措施主要针对应用层面，而对业务逻辑层面的防护则收效甚微。攻击者可以利用程序员的设计缺陷进行交易数据篡改、敏感信自盗取、资产的窃取等操作。业务逻辑漏洞它可以逃逸各种安全防护，迄今为止没有很好的解决办法。现在为了规避该风险，总结了一些账户逻辑漏洞场景。

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/[email protected]&startClickTime=20180810105628

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

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

2.2.2认证凭证通用性

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

2.2.3 Session覆盖

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

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

2.3用户名找回密码

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

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

2.4找回密码步骤缺失

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

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

这里qazs1对应用户标识就是

uri=fjtwQnY2eDp1LHI0DT9zXHBAAE1xUgg6dEVwQARCAzRzPnRECUEBXXJ3dWIFenABc0M=

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

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

文章来自Backer Talk原创作者 - v清风

【Backer Talk】BSRC白客说栏目专注于安全知识分享，长期向安全爱好者征集漏洞分析、漏洞挖掘姿势分享等安全相关内容，欢迎惠赐作品！

详情点击：https://mp.weixin.qq.com/s/d5yeDopIBWr3Roqg5kUleQ