业务逻辑漏洞

业务逻辑漏洞概述

 业务逻辑漏洞产生的原因

1. 第三方逻辑缺陷
2. 没有在初期进行安全审计
3. 开发水平及对安全认识程度不一致

业务测试流程：

以电商为例：

业务场景

身份验证漏洞

暴力破解

攻击者暴力列举尝试用户名和密码，并进行登录操作

缺陷原理

由于没有设置登录失败次数限制，导致攻击者可以通过口令字典进行特定用户的密码爆破 或 通过用户名字典进行特定弱口令的用户枚举。

漏洞存在点

系统登录点

漏洞修复

对于固定用户名爆破密码

• 可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间 或者添加验证码

• 但是注意不能永久锁定，可能被用来进行账号恶意锁定

对于固定密码枚举用户名

• 需要计算IP对URL的请求情况，某个IP短时间大量请求登录应该加入

黑名单

进行传输数据加密有一定的防护效果

会话固定攻击

会话固定攻击是利用服务器的session不变机制，借他人之手获得认证和授权，然后冒充他人。

漏洞原理：

在请求登录过程时候，URL带有一个session，登录成功之后会将登录成功的信息绑定到这个session中，攻击者可以发送带有session的URL给相关工作人员诱导其登录，则相当于获取了其身份信息

漏洞点

在get方法请求登录时会带有session值 

 修复

只要避免在URL中带入session信息即可比较有效防御

注意POST请求中带有sessionid进行session固定攻击，虽然可利用性比较低，但是建议修复

Cookie欺骗

通过伪造cookie信息能够伪造其他用户进行登录

漏洞成因

开发者为方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在cookies中，网站通过获取得到的cookies进行授权或者身份认证。

漏洞点

cookie中有明显或者只是简单编码，哈希的字段

修复

Cookie不应该存储可理解的身份信息和登录信息

按照规定，cookie对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行，避免篡改

 权限类漏洞

垂直权限跨越

平行权限跨越

未经授权访问

权限漏洞是逻辑漏洞中出现得 最多 的漏洞

未经授权访问

游客可以访问普通用户或者管理员才能访问的系统功能或信息

形成原因

主要是系统设计期间没有进行全局用户身份校验；或者校验存在缺陷。

漏洞点

漏洞点

在任何用户登录后的才能访问的链接或者功能中都可能存在

 漏洞修复

J2EE中存在filter，可以获取用户的cookie等信息

修复思路

• 建立LoginList，值是当前在线用户的id

• 对所有需要登录访问到URL，获取请求request

• 再利用 getAttribute(”userid”) 获取其userid

• 检查userid是否存在于LoginList中，不存在则直接返回错误跳转

值得注意的是切勿将错误跳转写到Javascript里面，还返回目标URL页面的相关信息。

垂直权限跨越

即 普通用户 能够访问 管理员 甚至 超级管理员 才能够访问的系统 信息 或者系统 功能 。

形成原因

程序在方法调用时候，缺少角色等级校验。

  漏洞点

在任何用户登录后的才能访问的链接或者功能中都可能存在

漏洞修复

需要验证用户是否有权限访问这个方法

修复思路：

1. 获取请求resquest
2. 再利用 getAttribute(”roleid”) 获取其角色等级
3. 检查角色等级是否合法，错误则直接返回错误跳转，返回页面必须从Attribute中获取userid再进一步查询相关信息

 勿将错误跳转写道js中，还返回目标url页面的相关信息

平行权限跨越

即 普通用户/管理员 能够访问其他 普通用户/管理员 才能够访问的系统 信息 或者系统 功能 。

权限等级未变，只是能够访问的范围大

 漏洞成因

在进行方法调用时候未进行请求用户和目标信息拥有者是否匹配一致，直接用 userid/email 之类的容易遍历的参数进行数据库查询。

漏洞点 

在 普通用户/管理员 登录后的能访问的链接或者功能中都可能存在。

 漏洞修复

在权限管理中，平行越权的权限管理颗粒度最小

修复思路

• 需要在方法中进行相关的获取请求request

• 再利用 getAttribute(“userid”) 获取其userid

• 直接使用该userid作为参数进行数据增删查改，避免userid参数传输

 图片验证码漏洞

攻击者突破验证码的验证，可以实现登录爆破，验证码绕过等攻击

漏洞原理

1. 图形验证码在错误后未失效

2. 返回验证码信息

3. 分步验证验证码

 漏洞点

任何存在图形验证码的功能中

1. 验证码不变 
2. 验证码返回
3. 验证码分布绕过

漏洞修复

1. 一旦验证码使用过了，必须要进行删除，重新生成验证码，可以放到attribute中
2. 验证码需要设置超时，时间一到立即删除旧验证码，用户需 要获取新的验证码
3. 验证码只需要返回图片，切勿将生成验证码的字符串也一并返回
4. 验证码不应该进行分步校验，应该连同请求数据一起发送到目标服务器进行校验，服务器校验通过则返回合法数据，否则返回错误

 找回密码逻辑漏洞

攻击者通过密码找回逻辑漏洞，可以重置他人账号密码，危害他人账号安全。

漏洞原理

其实是验证码漏洞的一种。其中包含多种原理：

1. 验证码时间长可爆破

2. 返回重置密码凭证

3. 弱加密的重置密码凭证

4. ……

漏洞点

任何密码找回处（可延伸至相似具有验证功能） 

 漏洞修复

1. 一旦验证码使用过了，必须要进行删除，重新生成验证码，可以放到attribute中
2. 验证码需要设置超时，时间一到立即删除旧验证码，用户需 要获取新的验证码
3. 校验凭证不能够随着返回包进行返回
4. 验证码不应该进行分步校验，应该连同请求数据一起发送到目标服务器进行校验，服务器校验通过则返回合法数据，否则返回错误
5. 校验凭证的生成需要进行随机生成，防止凭证破解用户身份凭证和权限类漏洞修复一样，需要从attribute中获取

业务数据篡改

攻击者通过进行数值篡改进行攻击，从而获利。

l 商品编号 —— 提交最终订单时候将编号改为更贵的物品的编号

l 商品金额（购买） —— 提交最终订单的时候将金额改得更小甚至是负数

l 商品金额（返现） —— 提交最终订单的时候讲返现金额改得更大

l 商品数量 —— 通常购买两类商品收将其中一种数据改为负数（电子票务中可以单品直接

改成0）

l 商品数量 —— 如果检验了负数，可以尝试往整数上溢出方向增加

成因

1. 没有对传输数据添加相关的校验参数；

2. 后台未对参数值进行校验并直接使用数据包中的参数。

漏洞点

抽奖、购买、转账、返现等功能

修复 

p 对于软件来说，需要保护好内存数据，防止内存数据篡改

p 计算传输数据的哈希，并将哈希附加在传输数据中作为校验值，避免被篡改

p 先校验数值，防止大整数和负数；接着利用传输的商品Id从数据库中获取商品单价重新进行价格计算；最后生成订单号（订单号应为随机值）

 执行顺序逻辑漏洞

攻击者通过篡改分步逻辑中的步骤数字，达到绕过支付、校验等效果。

漏洞原理

程序逻辑分步进行，但是对步骤、验证信息、支付信息没有做好严格校验，导致修改步骤就直接绕过验证或者支付。

漏洞点 

任何分步逻辑且带步骤数字，或者利用Js进行步骤控制的功能中。

 漏洞修复

1. 在请求最后一步时候需要带入前面的验证信息，服务端再进行一次校验信息的验证，验证正确方能继续执行数据操作 也可以通过getAttribute(“userid”)获取userid进行userid和验证结果绑定，最后一步不带入验证信息，但是仍然要获取userid进行校验
2. 在最后一步通过验证之后或者服务器收到支付信息后再生成相应的数据交给用户