逻辑漏洞(仅作个人笔记)

Hamburger001
184 阅读18分钟

业务逻辑漏洞就是指攻击者利用业务/功能上的设计缺陷,获取敏感信息或破坏业务的完整性。一般出现在密码修改、越权访问、密码找回、交易支付金额等功能处。 逻辑漏洞的破坏方式并非是向程序添加破坏内容,而是利用逻辑处理不严密或代码问题或固有不足，进行漏洞利用的一个方式。

一. 身份验证漏洞

1.1 暴力破解漏洞

漏洞介绍：攻击者可以通过该漏洞获取用户名和对应弱口令密码，并进行登录操作

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

漏洞点：系统登录点

漏洞修复： 
1.对于固定用户名爆破密码可以针对用户名进行错误次数计算，高于一定阈值账号锁定一段时间，或者添加验证码
2.但是不能永久锁定，可能被用来进行账户恶意锁定对于固定密码枚举用户名
3.需要计算 IP 对 URL 的请求情况，某个 IP 短时间大量请求登录应该加入黑名单 进行传输数据加密有一定的防护效果

1.2 Session 固定攻击

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

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

漏洞点： 在 GET 方法请求登录时候带有 session 值


修复思路：

1.只要避免在 URL 中带入 session 信息即可比较有效的防御
2.另外也要注意 POST 请求中带有 sessionid 进行 session 固定攻击，
虽然可利用性比较低，但是建议修复。

1.3 认证信息伪造漏洞（cookie 或者 token）

漏洞介绍：通过伪造 cookie 信息能够伪造其他用户进行登录。 漏洞原理：开发者为了方便将身份信息/登录信息明文或者只是简单编码、哈希之后存放在 cookies 中，网站通过获取得到的 cookies 进行授权或者身份验证

漏洞点：cookie 中有明显或者只是简单编码、哈希的字段时候 修改 lsLogin 值为 1 可以判定为用户已经登录 修改 cookie为 asp163=UserName=admin

漏洞修复：
1.Cookie 不应该存储可理解的身份信息和登录信息 
2.按照规定，cookie 对身份信息和登录信息的存储只能通过存储足够长度的随机字符串进行，避免篡改

image.png 案例分享：无锡数据局

二. 权限类逻辑漏洞

  • 权限相关逻辑漏洞是逻辑漏洞中出现的最多的漏洞

2.1 水平越权

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

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

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

漏洞修复：
在权限管理中，平行越权的权限管理颗粒度最小

修复思路:
1.需要在方法中进行相关的获取请求 request 
2.再利用 getAttribute("userid")获取其 userid
3.直接使用该 userid 作为参数进行数据增删查改，避免 userid 参数传输

2.2 垂直越权

漏洞介绍：即普通用户能够访问管理员甚至超级管理员才能够访问的系统信息或者系统功能.

形成原因：程序再方法调用时候，缺少角色等级校验

漏洞点：在任何用户登录后才能访问的链接或者功能中都可能存在对每一个传输的参数都要了解参数的目的，尝试将用户名改为 admin 尝试绕过

漏洞修复：
需要校验用户是否有权限访问这个方法

修复思路：
1.获取请求 request
2.再利用 getAuttribute("roleid")获取其角色等级
3.检查角色等级是否合法，错误则直接返回错误跳转，返回页面必须仍然从 Attribute 中获取 userid 再进一步查询相关信息

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

2.3 未授权访问

漏洞介绍：即游客能够访问普通用户甚至超级管理员才能访问的系统信息或者系统功能

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

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

漏洞修复：
J2EE 中存在 filter，可以获取用户的 cookie 等信息

修复思路：
1.建立 LoginList，值是当前在线用户的 id
2.对所有需要登录访问到 URL，获取请求 request
3.再利用 getAttribute("userid") 获取其 userid
4.检查 userid 是否存在于 LoginList 中，不存在则直接返回错误跳转

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

三. 修改返回包进行绕过

修改返回包的值进行绕过，比如登录,短信验证码,人脸识别等等

案例分享：淳安农商行，东南大学，教育 src

四. 图形验证码漏洞

漏洞介绍：攻击者通过突破图形验证码的验证，可以实现如登录爆破、验证码绕过等攻击

漏洞原理： 图形验证码在错误后未失效 返回验证码信息 分步验证验证码

漏洞点：任何存在图形验证码的功能中

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

五. 找回密码逻辑漏洞

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

漏洞原理：其实是验证码漏洞的一种： 验证码时间长可爆破 返回重置密码凭证 若加密的重置密码凭证

漏洞点：任何密码找回处（可延伸至相似具有验证功能） 修改接受校验码目标

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

六. 业务数据篡改（支付漏洞）

漏洞介绍：攻击者通过进行数值篡改进行攻击，从而获利

漏洞原理： 没有对传输数据添加相关的校验参数 后台未对参数值进行校验并直接使用数据包中的参数

漏洞点：抽奖、购买、转账、返现等功能

漏洞修复：
1.对于软件来说，需要保护好内存数据，防止内存数据篡改
2.计算传输数据的哈希，并将哈希附加在传输数据中作为校验值，避免被篡改
3.先校验数值，防止大整数和负数；接着利用传输的商品 ID 从数据库中获取商品单价重
4.新进行价格计算；最后生成订单（订单号应为随机值）

七. 执行顺序逻辑漏洞

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

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

漏洞点：任何分布逻辑且带步骤数字，或者利用 JS 进行步骤控制的功能中

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

八. 认证信息多系统通用

比如登录一个存在弱口令的账号，发现，认证信息再其他系统同样使用，或者小程 序和 web 端的认证信息通用

案例：新疆交通学院，波司登，东南大学，桐乡农商行

九. 其他类型逻辑漏洞

9.1 条件竞争漏洞（并发）

漏洞介绍：可以通过同时重放大量数据包进行漏洞利用，通常用于突破限量、限额的 问题都有奇效

漏洞原理：由于目标函数中，判断与数据修复两个步骤之间，或者两个数据修改步骤 之间存在时间差，且函数未进行同步锁定，则可以造成漏洞

漏洞点：程序中存在限制，可以猜测到后台有判断与修改操作的方法

修复思路：使用 synchronized 关键字，可以限制同一时间内访问方法的只有单一线程
but并不是每个条件竞争都必须修复

9.2 数据包重放漏洞

漏洞介绍：通过数据包重放，可以造成短信轰炸、邮件轰炸、重复提交订单等

漏洞原理：后台未进行相关操作的技术导致数据包重放

漏洞点：短信验证码、邮件校验、提交订单等功能。

修复方案与修复思路（针对短信、邮件）

1.构造一个 Hashmap<String，short>，存放邮箱或电话号码及对应次数要某个邮箱或者电话号码次数够了，就不能继续发送了
2.或者计算两次发送的时间间隔，时间过短就不继续发送了

通用修复方案

需要建立 token 机制或验证码机制，一次有效

十. 信息泄露巧思分享

目录遍历信息泄露（江苏海事局内池港船舶信息系统）数据包参数制空信息泄露（无锡大数据局，长沙县项目实战）

返回信息过多信息泄露（中信期货）

前端存在限制但数据包没有（杭州银行）

十一. SRC 中的漏洞总结（大部分并非全部）

1. 注册：

  1. 短信轰炸

  2. 验证码安全问题

  3. 密码爆破

  4. 邮箱轰炸

2. 用户任意注册、批量注册
3. 用户名枚举
4. XSS（有框的地方就可以尝试插 XSS）
5. 登录：

  1. 短信轰炸、验证码安全问题、密码爆破、邮箱轰炸

  2. SQL 注入

  3. 撞库

  4. 抓包把 password 字段修改为空值发送

  5. 认证凭证替换、比如返回的数据包中包含账号，修改账号就能登录到其

他账号

  1. Cookie 仿冒

  2. 修改返回包的相关数据，可能会登陆到其他的用户

6. 找回密码：

  1. 短信邮箱轰炸、短信邮箱劫持

  2. 重置任意用户账户密码、验证码手机用户未统一验证

  3. 直接跳过验证步骤

7. 购买支付、充值（要利用抓包去仔细查看每一个可用的参数）

  1. 交易金额、数量修改、更换支付模块（比如更换支付的模块金额）

  2. 交易信息订单编码/导致信息泄露

  3. 整数溢出，int 最大值为 2147483647，超过最大值4. 修改充值账户

  4. 支付绕过

8. 抽奖活动

  1. 刷奖品、积分

  2. 并发

9. 优惠卷、代金卷

  1. 并发逻辑漏洞（burp 批量获取优惠券）

  2. 修改优惠券金额、数量

10. 订单信息

  1. 订单信息遍历、泄露

  2. 订单信息泄露导致用户信息泄露

  3. 删除他人订单

11. 会员系统

  1. 修改个人信息上传文件，上传带弹窗的 html

  2. 如遇上上传 xlsx、docx，可能存在 XXE，上传恶意的文档盲测

  3. 图片上传也可能遇到 imagereagick 命令执行，上传恶意图片

  4. 视频上传如果使用 ffmpeg<3.2.4（视频按帧分割成图片），上传恶意 avi

盲测 ssrf

  1. 用户横向越权访问、遍历、导致用户信息泄露

  2. SQL 注入、个人简历处存储 XSS 个人信息注册的名称也可以插入 XSS

12. 传输过程

  1. 明文传输账户密码

  2. 修改信息处无 session/token 导致 csrf

  3. POST/COOKIE 注入

13. 评论

  1. POST 注入

  2. 存储型 XSS

  3. 无 session/token 导致 CSRF

措施与方法：

1. 验证码问题

  1. 万能验证码

  2. 返回包中存在验证码

  3. 删除验证码或者 cookie 中的值可以爆破账号密码

2. 短信轰炸

  1. 一直重放

  2. 删除修改 cookie，重放数据包

  3. 遍历参数发送数据包

  4. 手机号后面加空格或者前面加其他的比如+86 或者逗号分号等，然后重

发数据包

  1. 请求参数修改大小写，或者添加请求参数比如&id=1

  2. 一个站的登录处可能做了防护，但是再找回密码处可能没有安全防护，

或者在注册流程中没有安全防护，所以说多测试接口

  1. 如果对手机号一天的次数进行了限制，还可以再发一次短信，DO

intercept 之后修改为成功回显

3. 水平越权

  1. 主要登陆后还是修改参数，主要找到多个接口不断测试

  2. 关注网页源代码，有时候会有表单，但被 bidden（隐藏标签）给隐藏起

来了，可以修改返回包然后尝试获取数据检测

  1. 多个账号，主要分析请求参数
4. 数据泄露
  1. 再找回密码处，填写数据后抓包查看返回信息，有可能存在敏感数据返

回

5. 任意用户密码重置

  1. 目前大部分都是在修改密码处参数修改

  2. 有些是前端验证

支付逻辑漏洞

1. 边界值问题 : 正常的逻辑是用户购买商品，然后价格累加得到一个总价进行扣

款。这个时候就会产生逻辑问题：如果说用户购买的商品是负数了，那么计算的总数就是负数。反过来钱给用户

2. 顺序执行缺陷： 正常的逻辑是 a-b-c-d 循环渐进的进行流程操作。这个时候就

会产生逻辑问题：可以直接从中绕过某一个过程进入到下一步操作。如果说有

一项是支付的操作，那么也就会产生支付绕过，如果说有一项是验证机制，就

会绕过验证直接进入下一步。

3. 金额直接传输导致篡改： 直接对下单的金额进行修改值，这里可以使用 fd 或者

burp 抓包

4. 确定支付之后还可以加入购物车： 把商品放入购物车点击下单支付，会跳转到

微信，支付宝等第三方支付平台。这个时候还可以继续在购物车中加入商品，

支付结束之后，商家发放的商品是现在的购物车里面的东西。

5. 请求重放： 购买成功之后，继续重放请求，可以让购买的商品一直增加。购买

成功之后，会有一个银行对商户网站跳转的过程，如果反复进行操作，有几率

会导致商品反复购买和增加，但是不需要付更多的钱。

6. 请求参数干扰： 金钱做了签名认证之后，修改后不通过，但是在里面仍然会有

一个参数对金额产生影响导致问题产生。

7. 订单替换： 订单替换发生在支付之后的事件处理，同时向服务器发起二次支付

请求一个多一个少，支付金额少的，然后支付之后进行替换，告知服务器订单

支付完成，并且过程可以反复的回放。

8. 欺诈: 需要两个收款人，一个是正常的商家，一个是伪造的商家

9. 单位替换： 产生在 paypal 类似的国际支付的场景。

10. 用户替换： 在支付过程中发生用户替换现象，首先登陆自己的账户，然后取得

另外一个人的账户名等有效信息，在业务流程中用对方的用户名替换自己的用

户名，用对方的余额购买完成后，再替换自己的账户名，这样就形成别人的钱

买自己的东西

11. 强制攻击： 强制攻击发生在暴力破解的情况下，如果一个商家运用一个自己的

网店，接入第三方支付接口，由于设计上的不当导致商家与第三方支付约定的

密钥 Key 可以单独被 MD5 加密，导致可以使用 MD5 碰撞技术对密钥进行破

解，攻击者可以设计简单的密钥加密信息使得 MD5 加密是可以用 MD5 碰撞技

术进行暴力破解。

12. 秘钥泄漏： 内置支付功能的 app 为了设计上的方便有可能会把 Md5 或者是 RSA

的私钥泄漏导致攻击者反编译 apk 之后获取密钥信息使得交易信息可以被篡

改。

13. 函数修改： apk 反编译之后的函数修改，可能导致商家在最后一步向支付方提

交订单时未验证信息的准确性，仍然被篡改。

14. heart bleed： SSL（安全套接层）协议是使用最为普遍网站加密技术，而

OpenSSL 则是开源的 SSL 套件，为全球成千上万的 web 服务器所使用。Web

服务器正是通过它来将密钥发送给访客然后在双方的连接之间对信息进行加

密。URL 中使用 https 打头的连接都采用了 SSL 加密技术。在线购物、网银等

活动均采用 SSL 技术来防止窃密及避免中间人攻击。

该漏洞被归为缓冲过度读取。缓冲过度读取错误是软件可以读取比应该被允许还多的 数据。漏洞让特定版本的 openSSL 成为无需钥匙即可开启的“废锁”，入侵者每次可 以翻检户主的 64K 信息，只要有足够的耐心和时间，就可以翻检足够多的数据，拼凑 出户主的银行密码、私信等敏感数据。产生原因：数据在传输的两端是不加密的。一 些数据如果在传输过程中不加密则会泄露个人数据等信息。

avatar
文章
阅读
粉丝