业务逻辑漏洞

权限绕过

原理

Web应用在接收某个请求执行特定的操作或者访问请求的资源时，要验证此请求是否由正确的用户发出。若此处验证操作存在缺陷，可能导致攻击者可以访问其他用户的敏感数据，甚至获得执行其它用户对应功能的权限。包括：交易支付、密码修改、密码找回、越权修改、越权查询、突破限制等各类逻辑漏洞

即：应用程序允许攻击者执行他没有资格执行的操作

分类

水平权限绕过

指允许用户控制相同类型下其他用户的资源，例如：一个普通用户可以修改其他同组用户的密码

垂直权限绕过

垂直权限绕过是指无权限或低权限的用户，可以控制有权限或高权限用户的资源。例如：普通用户可以使用管理员用户特有的功能，或者非会员时访问会员才能访问的资源

高危触发点

  • 密码修改、找回
  • 订单处理
  • 用户中心
  • 资源下载

危害

未授权访问

  • 资源、敏感信息泄露

未授权操作

  • 资料修改
  • 密码重置
  • 修改支付信息
  • 散播违规/违法信息

防御

原则

  • 不信任用户提交的关于访问权限的参数，应用程序应该只信任服务端完整信任链中的数据，任何用户传送至服务端的权限标识，都应该重新确认
  • 仔细确认应用程序每个功能单元的权限需求，并进行严格的管理
  • 对于关键业务逻辑（如：订单处理），应该对每次提出请求的相应权限进行冗余验证或者双重授权

Web逻辑层权限鉴定

通过session信息得到提交请求的操作者，通过数据库查询得到目标对象的权限所有者。判断两者是否一致，若不一致则阻断

限控制转移到数据接口层

当进行数据操作时，在数据库接口就进行判断

1
2
3
4
5
# 原语句
SELECT something FROM xxx WHERE addressID = $addressID

# 修改后语句
SELECT something FROM xxx WHERE addressID = $addressID AND ownerID = $userID

增加token校验

在生成表单时，增加一个token参数。Token可以使用与此次操作相关的参数生成，例如：

1
token = md5(addressID + sessionID + key)

在处理请求时，使用addressID、sessionID和key开检验token，以此判断请求的操作是否越权

支付逻辑漏洞

原理

在一些交易网站上，开发者一般设计如下：
用户购买商品，然后根据价格，得到一个总价，随后根据总价来扣钱
但此逻辑若处理不当，则会出现许多问题例如：
若用户购买商品是负数，则计算的总计就是负数了，这样系统的处理反而会给用户钱

一般支付流程

  1. 挑选商品加入购物车
  2. 确认购物车信息
  3. 输入物流及收货人信息
  4. 确认订单进入支付环节
  5. 交易成功等待发货

又例如：
某网站流程为A==>B==>C==>D，开发者意图为必须顺序执行，也认为用户会按照预定顺序执行每一步，这是因为在浏览器中导航是如此处理的
但此开发者的假设是存在缺陷的，用户若控制着他们给应用程序发送的每一个请求，因此能够按照任何顺序进行访问。于是如C是支付过程或验证过程，用户直接跳过C过程，买到了商品或绕过了验证

常见种类

金额直接传输导致篡改

抓包改包，即可改变传输的金额

确认支付后仍可加入购物车

攻击者在将商品加入购物车点击支付后，支付会转向一个第三方支付。此时攻击者还能往购物车内加入商品，当支付完成后，商家发放的商品是现有购物车里的东西

请求重放

购买成功后，重放其中请求，可以使购买的商品一直增加。购买成功后，会有一个从银行向商户网站跳转的过程，若此过程反复重放，可能会导致商品的反复购买和增加，但用户不用支付更多的货币

订单替换

订单替换的攻击方式发生在支付之后的事件处理，攻击者同时向服务器发起两次支付，请求一个多的和一个少的，支付金钱数目少的，支付完成后，替换支付的订单，告诉服务器此订单支付完成，并且此过程可反复回放，因为在服务器端保存的订单状态即使逻辑上处理检查过是否发放商品

单位替换

此过程产生在paypal类似国际支付的场景

强制攻击

强制攻击发生在暴力破解的情况下，若一个商家运用一个自己的网站，接入第三方支付接口，由于涉及上的不当，导致商家与第三方支付约定的密钥key可以单独被MD5加密，导致可以使用MD5碰撞技术对密钥进行破解，攻击者可以设计简单的密钥加密信息，使得MD5加密是可以用MD5碰撞技术进行暴力破解

防范：经常更换密钥。由于商家不是开发者，对于密钥没有深刻的理解，甚至可能随意泄露了自己的密钥信息，以及在功能正常的情况下不对密钥进行更改

密钥泄露

内置支付功能的app为了设计上的方便可能会把MD5或者RSA的私钥泄露，导致攻击者反编译apk之后，获取密钥信息，使得交易信息可以被篡改

函数修改

apk反编译之后的函数修改，有可能导致商家在最后一步向支付方提交订单时未验证信息的准确性，虽然此时以对信息进行签名，但是仍然被篡改

防范

支付流程注意事项

支付前 支付中 支付后
1.检查支付金额边界值 漏洞一般很少出现 1.检测签名是否正确
2.检查支付数量边界值 因为由银行或者是第三方管理 2.检测订单号是否正确
3.金额不要直接传输 目前可以利用的有SSL以及根证书欺骗问题 3.检测订单号对应的金额是否正确
4.使用订单号的方式传输订单 4.检测订单号对应的金额是否正确
5.对所有的购买信息进行签名 5.检测订单号对应的产品是否正确
6.经常更换签名密钥 6.检测收款人是否正确

检测模型

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# 订单号
Order/OrderId/Order_id/out_trade_no/tradeNo/*trade*/*order*/payno*/payment_id/paymentId/merc_tranid/*tranid*
# 价格
*Price*/*total_fee*/*amount*/*amt*

# 数量
*Number*/*quantity*

# 物品ID
itemId/Item_id

# 用户
User/usr

# 通知地址
Notifyurl/notify_url/return_url/returnurl/show_url/showurl

# 商户
Default_partner/*partner*

# 签名方式
Sign_type/signtype

# 密钥
PRIVATE/private_key/*MD5*/*key*

# 签名
Sign/*verity_sign*/*auth*

密码找回漏洞挖掘

原理

修改密码

  • 需要旧密码

    • 验证不输入旧密码可否修改，或尝试抓包将提交旧密码参数删除
    • 验证旧密码输入处是否存在sql注入
    • 验证是否可跳过输入旧密码步骤直接修改新密码

  • 不需要旧密码

    • 验证修改密码提交数据中是否包含了用户身份信息
    • 验证提交的用户身份信息被修改后是否可以成功修改
    • 验证修改Cookies中的每一项包含用户身份的信息是否会影响修改结果
    • 验证是否可以在不登陆的情况下直接提交修改密码的请求进行修改
    • 验证是否可以越权修改任意用户密码

基本流程

  1. 走一遍正常密码修改流程，把过程中所有环节的数据包全部保存
  2. 分析流程中哪些步骤使用了哪些身份认证信息，使用了哪些认证方法
  3. 分析哪个步骤可以跳过，或可以直接访问某个步骤
  4. 分析每个认证方法是否存在缺陷，可否越权
  5. 首先尝试正常密码找回流程，选择不同找回方式，如：邮箱、手机、密码提示问题等
  6. 分析各种找回机制所采用的验证手段，如：验证码有效期、有效次数、生成规律、是否与用户信息关联等
  7. 抓取修改密码步骤的所有数据包，尝试修改关键信息，如：用户名、用户ID、邮箱地址、手机号等

防御方式

原则
密码找回漏洞本质仍然属于权限漏洞的一种，所以需要遵守权限绕过的防御规则

  • 不信任用户提交的关于访问权限的参数，应用程序应该只信任服务端完整信任链中的数据，任何用户传送至服务端的权限标识，都应重新确认
  • 在进行密码修改逻辑的过程中，应对每次提交请求的相应权限进行冗余验证或者双重验证

补充

Google Hacking基本语法

Site 指定域名
Intext 正文中存在关键字的网页
Intitle 标题中存在关键字的网页
Info 一些基本信息
Inurl URL存在关键字的网页
Filetype 搜索指定文件类型

您的支持是我前进的动力！