web渗透测试----22、业务逻辑漏洞--（1）示例

---

一、客户端验证的逻辑漏洞

假设：用户将仅通过提供的Web界面与应用程序进行交互，即开发人员假设通过客户端验证阻止用户提供恶意输入。这些数据是在浏览器发送完之后，然后再传递到服务器端逻辑中的但是，攻击者可以使用类似Burp Proxy之类的工具来篡改数据，导致客户端验证失效。

1.1、示例一

以下为一个添加购物车进行购物的请求：

POST /cart HTTP/1.1
Host: acd71f7d1e390c358025879b008300b4.web-security-academy.net
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Origin: https://acd71f7d1e390c358025879b008300b4.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: https://acd71f7d1e390c358025879b008300b4.web-security-academy.net/product?productId=1
Cookie: session=5pmT0ryydooGFx9PjY67M9UDnHXBjxyY

productId=1&redir=PRODUCT&quantity=1&price=133700

我们可以看到在请求正文中存在一个price参数，如果此时仅通过前端对其验证，那我们可以通过burp等工具将其更改为任意价格，绕过前端验证，达到低价购买商品的效果。

---

二、非常规输入导致的逻辑漏洞

应用程序逻辑的一个目标是将用户输入限制为符合业务规则的值。例如，可以将应用程序设计为接受某种数据类型的任意值，但是逻辑从业务角度确定此值是否可接受。许多应用程序将数字限制纳入其逻辑。这可能包括旨在管理库存，应用预算限制，触发供应链阶段等的限制。

以网上商店为例：订购产品时，用户通常会指定要订购的数量，理论上任何整数都是有效的输入，但是业务逻辑可能会阻止用户订购比当前库存更多的产品。假设，数字类型接受负值，如果应用程序未执行适当的服务器端验证并拒绝了此输入，则攻击者可能能够传递负值并引起服务器的不良反应。

2.1、示例一

考虑两个银行帐户之间的资金转帐，此功能会在完成转帐之前检查发件人是否有足够的资金：

$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();

if ($transferAmount <= $currentBalance) {
    // Complete the transfer
} else {
    // Block the transfer: insufficient funds
}

但是，如果逻辑不能充分阻止用户在amount参数中提供负值，则攻击者可能会利用这一点绕过余额检查并向错误方向转移资金，如果攻击者向受害者的帐户发送了-1000元，这可能会导致攻击者从受害者那里获得1000元。因为逻辑将始终判断-1000小于当前余额并批准转帐。

在进行逻辑漏洞测试，我们可以使用Burp Proxy和Repeater等工具尝试提交非常规值，特别是尝试输入合法用户不太可能输入的范围。比如：针对基于文本的字段的异常高、异常低的数字输入、异常长的字符串，也可以尝试意外的数据类型，通过观察应用程序的响应，观察以下情况是否发生：
1、数据对是否有任何限制？
2、达到这些限制时会发生什么？
3、是否对输入执行任何转换？
如果在目标网站上找到一种无法安全处理非常规输入的表单，则其他表单很可能也会遇到相同的问题。

2.2、示例二

POST /cart HTTP/1.1
Host: aceb1f1c1e7618d780da662e003a009a.web-security-academy.net
Content-Length: 36
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://aceb1f1c1e7618d780da662e003a009a.web-security-academy.net
Referer: https://aceb1f1c1e7618d780da662e003a009a.web-security-academy.net/product?productId=4
Cookie: session=4rjkbyvDwK3GfISd3BkeU74KMuRIkN9Y

productId=4&redir=PRODUCT&quantity=1

以上为一个购买数量的请求包，quantity参数表示购买数为1，此时我们将购买参数设置为负数，那么我们需要支付的金额也将变为负数，如果服务器限制了金额必须为正数，那么我们可以通过添加其他商品，将quantity参数变为负数，达到低价购买高价商品的目的。

2.3、示例三

1、“target>Site map>Engagement tools>Discover content”

2、点击Session is not running启动内容发现。

3、稍等一会，发现在site map中存在/admin路径。我们可以通过此功能进行一些尝试。

---

三、强制输入导致的逻辑漏洞

某些业务要求用户必须输入某个参数，在没有对此类输入的情况下，浏览器可能会阻止提交表单，但是攻击者可以篡改传输中的参数，甚至完全删除参数。

在同一服务器端脚本中实现多个功能的情况下，是否存在特定参数可以确定执行哪个代码，删除参数值可能会使攻击者访问应该无法访问的代码路径。在探查逻辑缺陷时，尝试依次删除每个参数，并观察其对响应的影响：

1、一次只删除一个参数，以确保到达所有相关的代码路径。
2、尝试删除参数名称和值，服务器通常会以不同的方式处理这两种情况。
3、遵循多阶段流程直至完成，有时在一个步骤中篡改参数会对工作流程中的另一步骤产生影响。

这适用于URL、POST参数、cookie等，这个简单的过程可以揭示一些可能被利用的奇怪的应用程序行为。

3.1、示例一

POST /my-account/change-password HTTP/1.1
Host: acef1ff91ecb7385808a1676004c005e.web-security-academy.net
Connection: close
Content-Length: 120
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
Origin: https://acef1ff91ecb7385808a1676004c005e.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: 
Referer: https://acef1ff91ecb7385808a1676004c005e.web-security-academy.net/my-account
Cookie: session=b8JKug7GN96DV0T0AlGSW01axT6GWmjs
……

csrf=phsCC5hP85Zem2lHptjy4P99SOp6egSD&username=wiener&current-password=peter&new-password-1=123456&new-password-2=123456

1、可以观察到这个更改密码的请求，此时，如果我们尝试删除current-password参数，发现，不用输入原密码即可更改成功。
2、也是对应该请求，更改密码的参数决定于username参数，此时，我们将username=wiener更改为username=administrator，尝试使用administrator登录。

---

四、用户不遵循web业务流程导致的逻辑漏洞

许多业务依赖于由一系列步骤组成的预定义工作流，Web界面通常会指导用户完成此过程，并在每次完成当前操作时将他们带到工作流程的下一步。但是，攻击者不一定会遵循此预期顺序。

4.1、示例一

例如，许多实施双因素身份验证（2FA）的网站要求用户在一页上登录，然后在另一页上输入验证码。假设用户将始终遵循此过程直至完成，并且结果是未验证自己是否这样做，则可能使攻击者完全绕过2FA步骤。
2FA验证导致的逻辑漏洞：

GET /my-account?id=wiener HTTP/1.1
Host: accc1f631ed62c5280883d4c00ba002b.web-security-academy.net
Connection: close
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: https://accc1f631ed62c5280883d4c00ba002b.web-security-academy.net/my-account
Cookie: session=kd7yszRARlwBDIIAaDjIjeLqQ9S2sXhS

此双因素认证流程中，在获取验证码进行登录时，URL如上，当我们退出该账号，使用其他用户的账号密码进行登录，此时我们因为没用验证码而导致无法登录，但是，我们手动将受害者获取验证码的URL更改为我们登录时获取验证码的URL，可能导致直接绕过。

4.2、示例二

即使在相同的工作流程或功能内，对事件的不同进行顺序也可能导致各种各样的问题，使用Burp Proxy和Repeater之类的工具，一旦攻击者看到请求，他们便可以随意重放请求，并使用以他们想要的任何顺序执行与服务器的任何交互，这使他们可以在应用程序处于意外状态时完成不同的操作。
为了识别这些类型的缺陷，可以使用强制浏览以意外的顺序提交请求。例如：可以跳过某些步骤、不止一次访问一个步骤，、回到较早的步骤，依此类推。通常攻击者只是向特定的URL提交GET或POST请求，但是有时可以通过向同一URL提交不同的参数集来访问步骤。与所有逻辑缺陷一样，尝试确定开发人员做出了哪些假设以及攻击面在哪里。
这种测试通常会导致异常，因为期望的变量具有空值或未初始化的值，密切注意遇到的任何错误消息或调试信息，这些可以成为信息泄露的宝贵资源，可以帮助我们微调攻击并了解有关后端行为的关键细节。
①工作流程验证不足：

POST /cart/checkout HTTP/1.1
Host: aca91ff71fc5edf18082198f003c0037.web-security-academy.net
Connection: close
Content-Length: 37
Cache-Control: max-age=0
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Origin: https://aca91ff71fc5edf18082198f003c0037.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Referer: https://aca91ff71fc5edf18082198f003c0037.web-security-academy.net/cart
Cookie: session=tPUOpzSPLh4vx3IjTsuSb2wzZgm2yKyS

csrf=yeebEUys5bdm0DzR8XifGzF2BXvs5lQl

这是一个购买商品的请求包，但是由于逻辑错误，请求发送之后，页面重定向到了订单确认页面

GET /cart/order-confirmation?order-confirmed=true HTTP/1.1
Host: aca91ff71fc5edf18082198f003c0037.web-security-academy.net
Connection: close
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
sec-ch-ua: " Not;A Brand";v="99", "Google Chrome";v="91", "Chromium";v="91"
Referer: https://aca91ff71fc5edf18082198f003c0037.web-security-academy.net/cart
Cookie: session=tPUOpzSPLh4vx3IjTsuSb2wzZgm2yKyS

我们重新添加一件商品到购物车，此时，重放POST /cart/checkout，此时可以发现，新商品购买成功，但是并未扣费。此漏洞导致的原因是购买流程中的验证不足导致的。

---

五、特定领域的缺陷

当寻找逻辑缺陷时，在线商店的折扣功能是经典的攻击面。
例如：一个在线商店，对$ 1000以上的订单提供10％的折扣，如果业务逻辑在应用折扣后无法检查订单是否已更改，则可能容易受到滥用。在这种情况下，攻击者可以将商品添加到购物车中，直到达到1000的门槛，然后在下订单之前将不需要的商品删除。然后，即使他们不再满足预期的标准，他们也将获得订单的折扣。
应特别注意根据用户操作确定的标准调整价格或其他敏感值的任何情况。尝试了解应用程序使用哪些算法进行这些调整以及在什么时候进行这些调整。

5.1、示例一：业务规则执行存在缺陷

当我们使用优惠券进行购物时，假设有两张优惠券，连续使用同一张时，服务器拒绝。依次使用时，成功，那我们可以依次重复使用两张优惠券，达到低价购买商品的目的。

---