逻辑类漏洞挖掘指南

逻辑类漏洞挖掘指南

逻辑类漏洞严格的说不算传统漏洞，它是基于程序逻辑产生，本身并不是bug，但是但是逻辑不严禁确实也产生了安全风险，逻辑漏洞在漏洞挖掘中属于必测的环境，下面就总结一下常见的逻辑漏洞

1 支付绕过

描述：
网站如果未对交易金额，交易物品的数量进行了校验，可能导致的支付金额任意修改等问题。这个问题在电商刚火的时候，到处都是，甚至有的电商是因为支付逻辑漏洞关站的。
检测方法：
使用burp或者yakit截取数据包，更改金额与数量相关参数进行测试
1.整数溢出，int最大值为2147483647，超过最大值，可能导致结果为-1，也就不花钱
2.小数点多位后四舍五入，因为程序原则上会采用固定小数点位数，所以多为后四舍五入可能不花钱
2.修改为负值进行测试，可能也不花钱甚至反向充钱
3.修改金额，比如将99元改成0.001元，相当与不花钱
4.修改支付认证响应包包，根据实际情况来修改。
修复方案：
检查代码逻辑，严格校验相关参数，或只向服务器传输物品ID与数量，在服务器端进行最终金额的计算。支付逻辑使用微信和支付宝接口，可以绕过很多问题。

2 密码找回问题

描述：
密码找回功能存在逻辑缺陷，可能导致用户重置他人密码。
检测方法：

• 1.爆破验证码:验证码如果未设置时效性次数限制可被无限穷举

• 2.绕过限制爆破:如果存在限制，可观察具体限制条件，进行爆破

• 3.返回凭证：从响应包里找回密码凭证直接返回至前端（需要一个正常功能账号修密码找回然后获取响应包进行分析伪造）

• 4.弱Token：找回密码Token弱，可被破解。例如时间戳

• 5.如果密码找回功能是邮箱，可考虑拼接邮箱参数，比如mail=test@test.com&attack@test.com或者mail=test@test.com;mail=attack@test.com

• 6.如果密码找回是问题，可以考虑社会工程学方式设置问题答案列表进行爆破

• 7.如果密码找回功能是短信验证，可以考虑拼接手机号，比如mobile=13112341234&13212341234或者mobile=13112341234;mobile=13212341234

• 8.观察请求的参数，密码找回一般分为几个步骤，比如1,2，3步，尝试能否通过修改参数直接从第1步直接跨到第3步

• 9.如果发送重置密码链接到邮箱，检查这个链接是否可以在响应包中发现，如果发现，那也是漏洞

• 修复方案：
  加强验证码强度，增加时效性验证,对于密码找回逻辑，反复验证其中是否存在的逻辑bug，多人讨论。

3 任意密码登录

描述：
存在SQL注入或其他逻辑漏洞，允许任意密码登录。
检测方法：

• 1.通过对网站登陆接口进行fuzz sql注入测试，判断是否存在万能密码绕过，这种情况除了个人开发的小网站，几乎不存在了，现在很多web框架都集成了鉴权模块，就没有这类问题了。
• 2.改后台返回的response数据包，是否会造成后台误以为用户已成功登陆

修复方案：

• 1.对用户输入的数据进行过滤以及转义
• 2.使用预编译的方式进行存储传输
• 3.正确判断用户输入的账号密码是否正确，而不是根据response的数据包返回判断用户登录态。

4 绕过统一认证平台

描述：
存随着平台的多样性，用户需求的不断提高，为了方便用户通过一次性用户身份验证登录多个应用程序和网站，大多数平台都会使用 SSO 系统。但是简单地使用 SSO 并不能自动保护系统

检测方法：

• 1.找到sso认证的请求包，恶意修改里面的参数来判断是否可以绕过
• 2.找到sso认证的响应包，将失败的认证请求改成正常的包，比如状态码302改成200，fail改成success，1改成0 等
• 3.接受任意正确格式的认证，我曾经就遇到一个网站，随意构造一个正常的jwt认证请求，都可以认证成功
  修复方案：
  对于使用统一认证的方式的逻辑代码，多人反复review讨论

5 并发漏洞

描述：
并发漏洞，常属于逻辑业务中的漏洞类型，例如攻击者通过并发http/tcp请求而达到次获奖、多次收获、多次获赠等非正常逻辑所能触发的效果。下面以简化的例子说明在交易的Web应用程序中潜在的并行问题，并涉及联合储蓄帐户中的两个用户（线程）都登录到同一帐户试图转账的情况：
帐户A有100存款，帐户B有100存款。用户1和用户2都希望从帐户A转10分到帐户B.
如果是正确的交易的结果应该是：帐户A 80分，帐户B 120分。
然而由于并发性的问题，可以得到下面的结果：
用户1检查帐户A （ = 100 分）
用户2检查帐户A （ = 100 分）
用户2需要从帐户A 拿取10 分（ = 90 分） ，并把它放在帐户B （ = 110 分）
用户1需要从帐户A 拿取10分（仍然认为含有100 个分）（ = 90 分） ，并把它放到B（ = 120 分）
结果：帐户A 90 分，帐户B 120 分

检测方法：
发送并发http/tcp请求，查看并发前后CGI 功能是否正常。例如：并发前先统计好数据，并发后再统计数据，检查2次数据是否合理
1.可以使用BurpSuite 的intruder模块
2.可以使用BurpSuite的并发插件Turbo Intruder

评价
万物即可并发，就是目前所有的功能点都可以并发，短信并发、优惠券并发、下单并发、支付并发、删除并发……，只要感觉网站的功能点和DB存在一定联系，即可并发。另外注意带CDN的网站会影响并发测试结果。

修复方案：

• 使用同步机制：在关键的代码段中使用同步机制来确保在同一时间只有一个线程可以访问共享资源。可以使用Java中的synchronized关键字或者ReentrantLock来实现同步。
• 使用事务管理：对于涉及到数据库操作的情况，使用Spring的事务管理机制来确保数据库操作的原子性和一致性。通过将相关操作放在事务中，可以避免在并发情况下出现数据不一致的问题。
• 使用乐观锁或悲观锁：在需要对共享资源进行更新的地方，可以考虑使用乐观锁或悲观锁来控制并发访问。乐观锁基于版本号或时间戳，而悲观锁则是在操作前获取锁。Spring Data JPA和Hibernate等持久化框架提供了对乐观锁的支持。
• 使用并发安全的数据结构：在需要使用共享数据结构的地方，使用并发安全的数据结构，如ConcurrentHashMap，可以减少并发访问带来的风险。
• 限制并发访问：可以通过限制同时访问某些资源的线程数或者请求频率来减少并发访问的压力。例如，使用限流算法或者队列来控制请求的处理速率。
• 使用分布式锁：如果应用是分布式的，考虑使用分布式锁来保护关键资源，以避免不同节点之间的并发冲突。Redisson等分布式锁的实现可以帮助解决这个问题。

6 慢速HTTP攻击

描述：
慢速攻击基于HTTP协议，通过精心的设计和构造，这种特殊的请求包会造成服务器延时，而当服务器负载能力消耗过大即会导致拒绝服务。HTTP协议规定，HTTP Request以\r\n\r\n（0d0a0d0a）结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送\r\n\r\n就会产生慢速攻击的漏洞，常见的Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b\r\n，导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求\r\n\r\n， 每隔几分钟写入一些无意义的数据流， 拖死机器。

检测方法：
1、 通过web扫描工具，可发现该类漏洞，但不一定准确。
2、 或者通过kali环境下的slowhttptest工具来进行检测，它是一款对服务器进行慢攻击的测试软件，包含了几种攻击方式，像Slowloris、SlowHTTP POST、Slow Read attack等。在执行相关的命令或者参数后，发现网站访问缓慢，则存在该漏洞
修复方案：
这里有一篇文章写的很好：https://mp.weixin.qq.com/s/iMgf-mmZHYQHPOpbudRUfw，包括原理，方式，和防御手段。

7 短信攻击

描述：
短信轰炸攻击时常见的一种攻击，攻击者通过网站页面中所提供的发送短信验证码的功能处，通过对其发送数据包的获取后，进行重放，如果服务器短信平台未做校验的情况时，系统会一直去发送短信，这样就造成了短信轰炸的漏洞
方法：
1、 手工找到有关网站注册页面，认证页面，是否具有短信发送页面，如果有，则进行下一步。
2、 通过利用burp或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看手机是否在短时间内连续收到10条以上短信，如果收到大量短信，则说明存在该漏洞。
3、可以尝试使用空格或者特殊字符尝试绕过：86，086，0086，+86，0，00，/r,/n, 以及特殊符号等
评价
更详细的内容可以参考认证与授权漏洞挖掘指南里面的相关内容
修复方案：
1、 合理配置后台短信服务器的功能，对于同一手机号码，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
2、 页面前台代码编写时，加入禁止针对同一手机号进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制。

8 邮件攻击

描述：
一般存在于网站向用户发送邮件的接口处，下发邮件时未做校验可造成邮件炸弹，或者自定义邮件内容，造成钓鱼邮件的可能

检测方法：
1、 手工找到有关网站注册页面，认证页面，是否具有邮件发送页面，如果有，则进行下一步。
2、 通过利用burp或者其它抓包截断工具，抓取发送验证码的数据包，并且进行重放攻击，查看邮箱是否在短时间内连续收到10条以上邮件，如果收到大量邮件，则说明存在该漏洞。
修复方案：
1、 合理配置后台邮件服务器的功能，对于同一邮件，发送次数不超过3-5次，并且可对发送的时间间隔做限制。
2、 页面前台代码编写时，加入禁止针对同一邮箱进行的次数大于N次的发送，或者在页面中加入验证码功能，并且做时间间隔发送限制

9 批量注册

描述：
注册用户时无校验措施，可造成批量用户注册，一般存在于注册入口处。
检测方法：
使用burp截断注册请求包，对多个被修改过用户名或手机号和邮箱的请求包进行请求重放
评价
批量注册本身并没有太多问题，但是在注册过程中，修改请求包，同一个短信验证码同一个手机号同一个 邮箱可以批量注册多个账户这种逻辑则要多多注意。
修复方案：
检查IP注册频率，增加验证码。

10 绕过IP限制进入管理后台

描述：
系统是通过 用户可自定义的参数，比如x-forward-for来获得访客的ip，再进行登录校验的。

检测方法：
在测试过程中对后台进行爆破，发现账号密码为admin和111，但是无法正常登录，经测试，nginx服务器设置是通过x-forward-for来获得访客的ip，再进行登录校验的。因此，在登陆的时候伪造XFF头为127.0.0.1，即可以成功登录，进入管理后台。

修复方案：
设置对外NGINX反向代理服务器上配置Remote_ADDR获取IP地址。

11 充值逻辑漏洞（小数精度问题）

描述：
页面系统没有对充值订单进行强加密校验，攻击者可修改订单金额进一步对平台造成严重经济损失。

检测方法：

• 1.使用burp截断充值请求包，修改小数点值。经测试，发现本系统充值处对金额进行四舍五入时存在漏洞，充值为0.016，实际支付0.01，实际得到进行了四舍五入为0.02。
  评价
  支付漏洞场景小合集，这些场景都可尝试
• 1.直接的价格修改
• 2.修改支付状态
• 3.修改购买数量
• 4.支付附属值修改
• 5.订单替代支付
• 6.支付接口替换
• 7.重复支付
• 8.最小额支付及最大支付(金额溢出)
• 9.四舍五入导致支付漏洞
• 10.首单优惠，无限重购
• 11.越权支付
• 12.并发数据包
• 13.盲盒类抽奖
• 14.直播打赏类

修复方案：
-充值时，仅保留两位小数，多余的小数忽略不计。或对充值业务订单跟金额加校验值、时间戳等进行绑定，一旦生成订单金额不允许中途修改。

12 代币可刷漏洞（小数精度问题）

描述：
系统没有对交易订单进行强加密校验，攻击者可篡改交易金额进一步对平台造成严重经济损失。
检测方法：
在链钱包到交易钱包互转的过程中，如果链钱包向交易钱包转币数量的小数点后第17位为5以上，可以在交易钱包中看到转入币的数量第16位四舍五入为1，但是链钱包中的低位金额并没有减少，交易钱包中多出1E-16的币。重复这个步骤可以无限刷币，该漏洞存在于BTC和EOS的划转过程中。测试时使用EOS重复该步骤成功刷币的数量为1E-13。

图：BTC向交易钱包中转入成功

图：BTC链钱包只减少0.001

图：BTC交易钱包多出1E-16的币

• 修复方案：
  对交易订单金额使用时间戳、签名、校验值等进行强校验，不允许中途对交易金额进行修改。

13 参数可控导致拒绝服务攻击

描述：
系统获取图片时，需要传入url，content，width，height四个参数，此处url与content参数未做校验及过滤，可以输入任意参数。Width与height控制图片的大小，修改图片大小可以影响服务器的响应时间，将width与height值设置很大时，将会导致服务器拒绝服务或宕机
检测方法：
对相关可控值进行修改发包

图1 Weight与height设置10

图2 Weight与height设置10000

修复方案：
对url与content参数进行过滤与校验，禁止使用恶意链接，严格限制生成的图片大小，防止造成设置图片大小过大，对服务器资源造成压力。

14 常见支付逻辑汇总

• 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技术来防止窃密及避免中间人攻击。