业务逻辑漏洞

一、越权漏洞

1、定义

越权漏洞是一种很常见的逻辑安全漏洞。是由于服务器端对客户提出的数据操作请求过分信任，忽略了对该用户操作权限的判定，导致修改相关参数就可以拥有了其他账户的增、删、查、改功能，从而导致越权漏洞。

 

2、产生原因

开发者认为通过登录即可验证用户的身份，而用户登录之后对数据进行增、删、改、查询等的操作时缺少进一步的权限验证，进而导致越权问题。

 

3、实例测试

1）水平越权

通常说的越权一般是修改get或者post参数导致的查看到他人的业务信息，一般看订单处，个人信息处等位置的参数

①方法：拿2个账号，修改账号1的get或post参数给账号2。

②例子：身份认证失效漏洞实战

a）登录测试账号时用burpsuite抓包。

b）可以看到card_id，发送到Repeater -> Go，发现了test账户的信息，尝试修改card_id值发现可以越权读取其他账户信息，那么现在关键就在于找出钻石代理马春生的id。

c）返回登录界面寻找线索，查看一下登录页面源码，成功找到钻石代理马春生的id。

d）回burpsuite修改包里的card_id，获取密码。

e）由于密码用了md5加密，去https://cmd5.com/进行解密。

f）登录钻石代理马春生的账号，拿到KEY

 

2）垂直越权

通过垂直越权漏洞实现在没有任何权限的情况下添加管理员用户，获得管理员权限。

方法：在添加用户处用burpsuite抓取请求数据包,生成form表单，设置账号密码，越权添加管理用户。

 

4、防御方案

1）前后端同时对用户输入信息进行校验，双重验证机制

2）执行关键操作前必须验证用户身份，验证用户是否具备操作数据的权限

3）可以从用户的加密认证 cookie 中获取当前用户 id，防止攻击者对其修改。或在 session、cookie 中加入不可预测、不可猜解的 user 信息

4）直接对象引用的加密资源ID，防止攻击者枚举ID，敏感数据特殊化处理

5）永远不要相信来自用户的输入，对于可控参数进行严格的检查与过滤

 

二、支付逻辑漏洞

1、产生原因

最常见的支付逻辑漏洞通常是由于服务器端没有对客户端请求数据中的金额、数量等敏感信息作校验，导致一般在电子商务网站上容易出现此类漏洞。

 

2、危害

攻击者可以通过burpsuite等工具修改任意金额购买商品（有的订单中商品数量可以修改为负值），甚至可以导致购买商品后系统给自己的账户充值。

 

3、实例测试

PHP逻辑漏洞利用实战

① 打开靶场，用系统给的账号登录后，发现小明余额只有1块钱，买不起书。

② 点击购买并用burpsuite抓包

③ 修改金额和数量，购买成功并获得key​

 

4、防御方法

1）在请求数据中对涉及金额、数量等敏感信息进行加密，保证加密算法不可猜解。并在服务器端对其进行校验。
2）支付交易请求数据中加入token，防止重放攻击。

 

三、密码找回漏洞

1、产生原因

找回密码功能模块通常会将用户凭证(通常为验证码或者链接)发送到用户注册时使用的手机号或者邮箱中，只要用户不泄露自己的用户凭证就不会被攻击者利用。

但有些信息系统在密码找回功能的设计存在逻辑缺陷，可能会将用于用户自证身份的信息的用户凭证以各种各样的方式返回到客户端。这样攻击者只要通过在本地抓取数据包并对其内容加以分析就能获取到其他用户的用户凭证,从而达到重置任意用户密码的目的。

 

2、测试方法

在测试系统是否存在用户凭证客户端回显漏洞时，可以先用自己的账号进行密码找回操作，并在抓取记录每次交互操作时的response数据包。然后观察分析数据包中是否存在和手机或邮箱中收到的用户凭证相同的字符串。

 

3、实例测试

1）用户凭证暴露在请求链接中

① 进入某直播网站登录处,点击忘记密码,选择通过注册手机找回密码。

② 输入手机号码,点击获取验证码,使用控制台查看请求链接，发现验证码直接出现在请求链接中。

2）加密验证字符串返回给客户端

① 进入某电商官网按正常流程执行找回密码功能,填写好邮箱和图片验证码,点击下一步,然后使用抓包工具抓取请求包。分析返回的数据包,发现其中包含了一个加密字符串,将其记录下来。

② 邮箱中会收到一个找回密码用的验证码。将该验证码在页面上填好，点击下一步即可进入到密码重置页面。

③ 仔细观察发现,密码重置页面URL中的加密验证字符串和之前返回数据包中的加密字符串是同一个。既然如此，则可以绕过邮箱验证码校验，直接利用抓包工具获取到的加密字符串构造到url中进行任意密码重置了。

3）网页源码中隐藏这密保答案

① 进入某邮箱网站官网，点击找回密码按钮,再点击"网上申诉"链接。

② 在网上申诉页面直接查看源代码，发现源代码中不但有密码提示问题，还在Hide表单里隐藏着问题答案。通过该方式，可获得任意用户修改密码问题答案，从而可以修改其他用户邮箱密码。

4）短信验证码在客户端回显

① 进入商城网站首页，点击忘记密码。然后通过短信验证方式找回密码。

② 在点击获取短信验证码的时候抓取数据包,发现服务端直接将短信验证码xxxxxx返回给了客户端，将其填写到验证码处即可成功重置其密码。同理，通过该方式，可以重置其他用户的密码。

 

4、防御方案

1）从验证码有效期和请求次数进行限制验证码爆破。
2）不要将token验证之类的数据直接返回给用户数据包。
3）修改加密算法和加密内容，一定要是强加密，要做到增加猜解难度或密文不可猜解。
4）用户身份验证一定要在后端实现。
5）在最后一步修改密码的动作时，一定要校验帐号是否通过了验证、短信与手机号是否对应、发送短信与已校验帐号不要使用同一个session名称。

 

四、验证码相关漏洞

1、验证码暴力破解

1）当验证码具有一定的规律性，并且没有做好对应的防护措施时，会导致攻击者通过穷举或其它方式猜解出验证码，从而对目标系统造成危害。

2）测试方法

a）接收验证码,观察验证码是否有规律性(如纯数字或可预测的字母)
b）多次填写验证码提交,观察是否有时效性或失败次数限制。
c）通过工具暴力猜解验证码

3）防御方案

a）提高验证码的复杂度(如:设为6位以上数字和字母的组合)
b）限制单位时间内验证码输入错误的次数(如规定10分钟内连续输错5次就锁定10分钟)
c）缩短验证码的时效性(一般短信验证码为5分钟内有效)

 

2、验证码重复使用

1）如果设计不合理，当服务器端接受请求后，没有将上一次保存的session及时清空，将会导致验证码可重复使用。

2）测试方法

通过重放请求,观察返回的信息提示来进行判断。如果通过重放没有提示"验证码错误"之类的信息,而只是提示"用户名密码错误"这些信息,就说明存在漏洞。

例如：登录密码重置漏洞分析溯源

启动靶场环境，用系统提供的手机号先获取一下短信验证码，然后在填入验证码后直接将手机号修改为17101304128，最后点击重置即可获得KEY

3）防御方案

当服务器端处理完一次用户提交的请求之后，及时将session域中的验证码清除，并生成新的验证码。

 

3、验证码客户端回显

1）用户向网站系统发送一条验证码(如短信验证码)的请求，当服务器端在调用短信平台发送短信时，没有判断验证码和手机是否绑定，并把验证码校验的功能放到客户端进行，从而导致验证码在客户端回显，验证码会直接返回显示在前端页面中或者数据包中（即可通过抓包工具截获该验证码）。

2）测试方法

a）输入任意手机号码,点击发送短信验证码并抓取数据包
b）查看返回数据包,观察验证码是否回显。

3）防御方案

a）在服务端对验证码进行校验。
b）禁止将验证码内容输出到客户端页面以及返回的数据包中。

 

4、验证码绕过

1）由于开发者使用了错误的逻辑判断，仅仅在客户端接收用户输入的验证码，并且在本地校验验证是否正确，而该判断结果也可以在本地进行修改，最终导致客户端误以为已经输入了正确的验证码，实现了验证码绕过。

2）测试方法

a）在接收验证码后,输入任意验证码,提交并抓包
b）尝试修改返回包中相关的参数值。
c）转发数据包,若进入密码重置页面,则证明存在漏洞。

3）防御方案

在服务端增加验证码的认证机制，而不仅仅是在客户端进行判断。

 

5、验证码自动识别

1）当验证码设计不存在逻辑层面的问题时，就要涉及到与验证码机制本身的正面对抗，也就是验证码识别技术。这里的验证码主要是指图片验证码。验证码自动识别就是指通过自动化的技术对图片验证码中的字符或公式等内容进行还原,从而突破验证码的安全限制。

2）测试方法

a）获取验证码链接
b）将链接载入验证码识别工具，进行图像二值化、去干扰等处理
c）如成功破解用户帐户,则证明验证码识别有效。

3）防御方案

a）增加背景元素的干扰。如背景色、背景字母等
b）字符的字体进行扭曲、粘连
c）使用公式、逻辑验证方法等作为验证码。如四则运算法、问答题等
d）图形验证码和使用者相关,比如选择联系人头像,选择购买过的物品等作为验证码
e）对单位时间内提交请求失败的次数进行限制

 

五、刷赞

1、测试方法

服务器是根据ip地址识别当前用户是否已点赞的，在数据包里添加一行X-Forwarded-For来伪造http客户端ip

 

2、实例测试

热点评论刷分漏洞分析溯源

① 进入页面，找到zhangyu的评论

② 在点赞时使用burpsuite抓包

③ send to intruder里遍历ip

④ 设置好payload，开始攻击

⑤ 攻击完毕后返回点赞页面，刷新一下就可以得到KEY了，可以看到zhangyu点赞数也涨了。

 

参考

https://www.cnblogs.com/tkb-/p/14394106.html

https://www.cnblogs.com/sijidou/p/13121335.html

https://www.cnblogs.com/Iamyoyodan/p/12984272.html