Examples of business logic vulnerabilities——bp业务逻辑漏洞示例

yh野良

已于 2022-11-07 16:30:04 修改

阅读量1.4k

点赞数 2

分类专栏：笔记文章标签：服务器安全网络

于 2022-11-06 22:19:49 首次发布

本文链接：https://blog.csdn.net/weixin_46065653/article/details/127703299

版权

笔记专栏收录该内容

52 篇文章 5 订阅

订阅专栏

Excessive trust in client-side controls（对客户端控件的过度信任）
- Lab1：Excessive trust in client-side controls（对客户端控件的过度信任）
- Lab: 2FA broken logic（2FA逻辑故障）
Failing to handle unconventional input（未能处理非常规输入数量负数）
Making flawed assumptions about user behavior（对用户行为做出错误的假设)
Trusted users won't always remain trustworthy（受信任的用户并不总是值得信任）
- Lab：Inconsistent security controls（安全控制不一致）
Users won't always supply mandatory input（用户不会总是提供强制输入）
- Lab1: Weak isolation on dual-use endpoint（在对应端点的弱隔离不提供初始密码）
- Lab2: Password reset broken logic（密码重置破坏逻辑不验证token值）
Users won't always follow the intended sequence（用户不会总是遵循预期的顺序）
Domain-specific flaws（特定领域的缺陷-薅羊毛）
- Lab1: Flawed enforcement of business rules（业务规则的执行存在缺陷）
- Lab2: Infinite money logic flaw（无限金钱逻辑缺陷）
Providing an encryption oracle（提供加密预言机）
- Lab: Authentication bypass via encryption oracle（通过加密机绕过身份验证）

bp业务逻辑漏洞靶场

Excessive trust in client-side controls（对客户端控件的过度信任）

一个有根本缺陷的假设是，用户只会通过提供的web界面与应用程序交互。这是特别危险的，因为它导致了客户端验证将防止用户提供恶意输入的进一步假设。然而，攻击者只需在数据被浏览器发送后，但在数据被传递到服务器端逻辑之前，使用Burp Proxy等工具就可以篡改数据。这实际上使客户端控件变得无用。

在不执行正确的完整性检查和服务器端验证的情况下，以表面价值接受数据，可以使攻击者以相对最小的努力完成各种破坏。确切地说，他们能够实现什么取决于功能以及它对可控数据的处理方式。在正确的环境下，这种缺陷会对与业务相关的功能和网站本身的安全产生毁灭性的后果。

Lab1：Excessive trust in client-side controls（对客户端控件的过度信任）

漏洞分析：对客户端控制的过度信任，是因为没有充分验证用户输入。
运行bp，利用wiener登录并尝试购买皮夹克。登录后我们有$100,尝试购买订单被拒绝，因为我们没有足够的$。
在bp中，转到“代理”>“HTTP 历史记录”查看订单流程，然后发现当我们将商品添加到购物车时，相应的请求会包含一个price参数，这样我们利用bp拦截尝试篡改金额绕过。

Lab: 2FA broken logic（2FA逻辑故障）

漏洞分析：双重验证登录，先输入账号密码, 然后查看邮件, 填入验证码进行登陆，这里验证码为0000~9999随机，可以利用bp爆破出。
在bp运行时，登录wiener帐户，然后在POST /login2请求中，我们可以确定verify参数是确定正在访问的用户帐户。
可以看到我们登录成功，然后我们通过bp查看我们的登录流程，对数据包进行分析
将GET /login2请求包发送到Repeater，然后将verify参数的值更改为carlos并发送请求，确保服务器端生成carlos的临时验证码。
首先登陆测试账户密码，通过后，在GET 时更换verity为carlos 目的是让carlos在服务器端产生可使用的验证码。
将POST /login2请求发送到Intruder，在Intruder中，将verify参数设置为carlos参数并在mfa-code参数位置添加一个payload，暴力破解验证码。

在这里插入图片描述

得到验证码后，注意回到提交界面拦截post请求包并修改wiener为carlos

Failing to handle unconventional input（未能处理非常规输入数量负数）

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

让我们举一个网上商店的简单例子。订购产品时，用户通常指定要订购的数量。尽管理论上任何整数都是有效的输入，但例如，业务逻辑可能会阻止用户订购比当前库存更多的单位。

要实现这样的规则，开发人员需要预测所有可能的场景，并将处理这些场景的方法纳入应用程序逻辑。换句话说，他们需要告诉应用程序它是否应该允许给定的输入，以及它应该如何基于各种条件做出反应。如果没有用于处理给定情况的显式逻辑，这可能会导致意外和潜在的可利用行为。

例如，数字数据类型可能接受负值。根据相关功能，业务逻辑允许这样做可能没有意义。但是，如果应用程序没有执行足够的服务器端验证并拒绝此输入，攻击者可能会传递负值并引发不必要的行为。

考虑两个银行账户之间的资金转账。该功能几乎可以肯定地在完成转账之前检查发送方是否有足够的资金：

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

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

但是，如果该逻辑不能充分防止用户在金额参数中提供负值，攻击者可能会利用此漏洞绕过余额检查并将资金转移到“错误”的方向。如果攻击者向受害者的账户发送了1000美元，这可能会导致他们从受害者那里收到1000美元。逻辑将始终评估-1000小于当前余额，并批准转账。

这样的简单逻辑缺陷如果出现在正确的功能中，可能会造成毁灭性的后果。在开发和测试过程中，它们也很容易被忽略，特别是考虑到这样的输入可能会被web界面上的客户端控件阻止。

审核应用程序时，应使用BurpProxy和Repeater等工具尝试提交非常规值。特别是，在合法用户不太可能输入的范围内尝试输入。这包括异常高或异常低的数字输入以及基于文本的字段的异常长的字符串。您甚至可以尝试意外的数据类型。通过观察应用程序的响应，您应该尝试回答以下问题：

数据是否有任何限制？
当你达到这些极限时会发生什么？
是否对您的输入执行了任何转换或规范化？

这可能会暴露弱输入验证，从而允许您以不寻常的方式操作应用程序。请记住，如果您在目标网站上发现一个表单无法安全地处理非常规输入，那么很可能其他表单也会出现同样的问题。

Lab1：High-level logic vulnerability（高级逻辑漏洞）

在这里插入图片描述

这个实验的目的是买一个皮夹克，所以我们可以先添加一个皮夹克，然后再抓取其他订单的包，将其他的订单数量更改为负数，将订单内容的价格控制在0-100，这样我们就可成功购买了，后端应该提供了识别，但是能够绕过前端的认证。
登录wiener账户，把皮夹克和另一件添加到购物车中“Add to cart”点击购物车“My cart”，找到数量“Quantity”，抓＋数量的包
最后支付即可

Lab2：Low-level logic flaw（低危逻辑漏洞金额溢出）

在这里插入图片描述

实验思路：经过测试quatity参数添加不能超过3位数，每次提交的数量最多为99，这样我们把抓到的包发送到intruder，选择Null payloads，Payload Options选择 Contunue indefinitely（无限重放）
接着重复上一步步骤，利用intruder无限发包，然后观察页面使最终价格保持在$100以内且为正

Lab3：Inconsistent handling of exceptional input（异常输入处理不一致字符串溢出利用漏洞）

漏洞原理:因为255个字符长度的限制，导致读取邮箱时，误以为是高权限用户在注册，于是赋予了这个用户高权限。
尝试用wiener登录发现不行，有注册选项，尝试用注册的账号登录
注册成功，然后用我们的账号进行登录
登录后并没有发现管理后台的选项，这里我们也可以明白我们不是管理员用户，但我们知道他肯定有管理员的目录，这里使用BP抓包对网站进行嗅探在Target模块找到网址，右击进行目录扫描，结果发现admin子目录，尝试访问。
- 发现admin目录
我们尝试访问，结果返回错误消息Admin interface only available if logged in as a DontWannaCry user，表明DontWannaCry用户有访问权点击Email client进入邮件客户端
这样我们记下自己的电子邮件服务器域名中的 ID
exploit-0a4a00e203fc4421c0c5632801d50014.exploit-server.net
- 尝试注册DontWannaCry用户
重复上述步骤，注册成功，登录尝试访问admin还是不行
根据逻辑漏洞，新建特殊的用户根据提示，构造特殊的邮箱地址，用@dontwannacry.com构造255字符长度的邮箱，在末尾加上自己的邮件ID
可以看到这是他的最大字节数文本文字(字数,字符数,字节数)统计在线计算器
构造255个字节yyy2yyy2yyy2yyy2yyy2yyyy2yyy22yyy2yyy2yyy2yyyyyyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyyyyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy22yyy2yyy2yyy2yyy2@dontwannacry.com
在后面加上我们的邮箱id
yyy2yyy2yyy2yyy2yyy2yyyy2yyy22yyy2yyy2yyy2yyyyyyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyyyyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy2yyy22yyy2yyy2yyy2yyy2@dontwannacry.com.exploit-0a4a00e203fc4421c0c5632801d50014.exploit-server.net
然后注册登录，查看我的账户

Making flawed assumptions about user behavior（对用户行为做出错误的假设)

Trusted users won’t always remain trustworthy（受信任的用户并不总是值得信任）

逻辑漏洞最常见的根本原因之一是对用户行为做出错误的假设。这可能导致一系列问题，开发人员没有考虑违反这些假设的潜在危险场景。在本节中，我们将提供一些应该避免的常见假设的警示示例，并演示它们如何导致危险的逻辑缺陷。

应用程序似乎是安全的，因为它们实现了看似健壮的措施来执行业务规则。不幸的是，有些应用程序错误地认为，在最初通过了这些严格的控制之后，用户及其数据可以无限期地受到信任。这可能导致从那时起相同控制的执行相对松懈。

如果业务规则和安全措施没有在整个应用程序中始终如一地应用，这可能会导致潜在的危险漏洞，可能被攻击者利用。

Lab：Inconsistent security controls（安全控制不一致）

漏洞原理 :没有对更改邮箱进行验证，可以随意更改邮箱地址，甚至是高权限用户的邮箱（直接修改邮箱为管理员邮箱）
正常注册登录，然后发现可以修改邮箱，然后将其修改为 yyy@dontwannacry.com成功越权

Users won’t always supply mandatory input（用户不会总是提供强制输入）

一个误解是，用户总是为必填输入字段提供值。浏览器可能会阻止普通用户在没有所需输入的情况下提交表单，但正如我们所知，攻击者可以在传输过程中篡改参数。这甚至扩展到完全删除参数。

在同一服务器端脚本中实现多个函数的情况下，这是一个特殊的问题。在这种情况下，特定参数的存在或不存在可以确定执行哪个代码。删除参数值可能允许攻击者访问本应无法访问的代码路径。

当探测逻辑缺陷时，您应该尝试依次删除每个参数，并观察这对响应的影响。您应确保：

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

这适用于URL和POST参数，但不要忘记检查cookie。这个简单的过程可以揭示一些可能被利用的奇怪的应用程序行为。

Lab1: Weak isolation on dual-use endpoint（在对应端点的弱隔离不提供初始密码）

漏洞原理：利用对输入参数的不完全检测，通过其他帐户可以更改密码功能来修改任意帐户的密码，从而达到越权。
解决方案：修改代码对输入内容进行过滤。
正常登录后，发现我的账号处可以修改密码，进行抓包查看
在修改密码的时候抓包，将其发送到 Repeater，发现完全删除current-password键也能请求成功可以看到请求值为200
知道管理员账户账号的条件下，可以可用此漏洞修改管理员账号密码

Lab2: Password reset broken logic（密码重置破坏逻辑不验证token值）

在这里插入图片描述

漏洞原理：利用设计上的缺陷，有TOKEN值但不验证来完成修改任意账户密码
解决方案：代码中加入对token值的验证
发现登陆界面有忘记密码的选项，先正常登录
抓取修改密码的数据包
修改数据包后放行，最后登录carlos账户即可

Users won’t always follow the intended sequence（用户不会总是遵循预期的顺序）

许多事务依赖于由一系列步骤组成的预定义工作流。web界面通常会引导用户完成此过程，每次完成当前工作流程时，都会将他们带到下一个工作流程步骤。然而，攻击者不一定会遵守这个预定的顺序。如果不考虑这种可能性，可能会导致危险的缺陷，而这些缺陷可能比较容易被利用。

例如，许多实施双因素身份验证（2FA）的网站要求用户在一个页面上登录，然后在单独的页面上输入验证码。假设用户将始终遵循此过程直到完成，因此，如果不验证他们是否遵循，则攻击者可能会完全绕过2FA步骤。

Lab1: 2FA simple bypass（绕过一个阶段(验证码)验证）

漏洞原因：应该是双因素验证不严谨，在我们修改url并进行跳转时只检查了cookie是否正确，但并没有检查是否已经通过了邮箱验证码来登录。
题目给了我们两个账号和密码
wiener:peter
carlos:montoya
正常用wiener进行登录,点击上方Email client获取验证码，分析url可知在/my-account
尝试登陆carlos账户
点击进入检查验证码界面，修改url为 https://0ae8008104eb0d75c15a999900ef0086.web-security-academy.net/my-account回车，成功绕过验证码检查登录网页

即使在相同的工作流或功能中，对事件的顺序进行假设也会导致广泛的问题。使用Burp
Proxy和Repeater等工具，一旦攻击者看到一个请求，他们就可以随意重播，并使用强制浏览来按照他们想要的顺序与服务器进行任何交互。这允许他们在应用程序处于意外状态时完成不同的操作。

要识别这些类型的缺陷，您应该使用强制浏览以意外的顺序提交请求。例如，您可能会跳过某些步骤，多次访问单个步骤，返回前面的步骤等等。请注意访问不同步骤的方式。尽管您通常只是向特定URL提交GET或POST请求，但有时您可以通过向同一URL提交不同的参数集来访问步骤。与所有逻辑缺陷一样，尝试确定开发人员所做的假设以及攻击面所在。然后，您可以寻找违反这些假设的方法。

请注意，这种测试通常会导致异常，因为预期变量的值为空或未初始化。在部分定义或不一致的状态下到达某个位置也可能导致应用程序投诉。在这种情况下，请务必密切注意您遇到的任何错误消息或调试信息。这些可能是信息泄露的宝贵来源，可以帮助您调整攻击并了解后端行为的关键细节。

Lab2: Insufficient workflow validation（工作流验证不足–直接发送购买成功验证报文）

在这里插入图片描述

漏洞原因：没有对购买流程进行一个严格的检测，最终决定商品是否能购买只取决于某一段报文，导致如果该报文被劫持，那么攻击者就可以不使用余额购买平台上任何商品。
/order-confirmation?order-confirmed=true
猜想是否可以通过伪造该数据包来购买其他价格在余额以上的商品进行测试，选择一件价格大于余额的商品并添加到购物车，购买后可以看到信用余额并未改变，但是显示订单成功完成了。

Lab3: Authentication bypass via flawed state machine（通过有缺陷的状态机制绕过身份验证丢弃身份选择数据包）

在这里插入图片描述

开启bp，正常登录，发现会有角色选择页面，然后我们返回bp代理http历史记录里分析每个数据包的作用
这里我们可以理解为他让我们选择自己的身份是用户还是商户
既然我们需要的是管理员的角色，而不是去选择用户或者商户，那我们可以尝试直接放掉login包，丢弃role-selector包，然后返回上一级页面进行绕过

Domain-specific flaws（特定领域的缺陷-薅羊毛）

在许多情况下，您会遇到特定于业务领域或站点目的的逻辑缺陷。

在线商店的折扣功能是寻找逻辑缺陷时的经典攻击面。这对于攻击者来说可能是一个潜在的金矿，折扣的应用方式中会出现各种基本的逻辑缺陷。

例如，考虑一家在线商店，对超过1000美元的订单提供10%的折扣。如果业务逻辑在应用折扣后未能检查订单是否已更改，则这可能容易被滥用。在这种情况下，攻击者可以简单地将物品添加到购物车中，直到达到1000美元的门槛，然后在下单之前删除不想要的物品。即使订单不再满足预定标准，他们也会收到订单折扣。

您应特别注意根据用户操作确定的标准调整价格或其他敏感值的任何情况。尝试了解应用程序使用什么算法进行这些调整，以及在什么时候进行这些调整。这通常涉及操作应用程序，使其处于应用的调整与开发人员预期的原始标准不一致的状态。

要识别这些漏洞，您需要仔细考虑攻击者可能具有的目标，并尝试使用提供的功能找到实现这一目标的不同方法。这可能需要一定程度的领域特定知识，以便理解在给定环境中什么可能是有利的。举个简单的例子，你需要了解社交媒体，才能理解强迫大量用户关注你的好处。

如果不了解这个领域，你可能会忽视危险行为，因为你根本没有意识到其潜在的连锁反应。同样，您可能会很难连接这些点，并注意到两个函数如何以有害的方式组合。为了简单起见，本主题中使用的示例特定于所有用户都已经熟悉的域，即在线商店。然而，无论你是bug赏金猎人、pentesting，甚至只是一个试图编写更安全代码的开发人员，你都可能在某个时候遇到来自不太熟悉的领域的应用程序。在这种情况下，您应该阅读尽可能多的文档，并在可能的情况下与该领域的主题专家交谈，以获得他们的见解。这听起来可能有很多工作，但领域越模糊，其他测试人员就越有可能漏掉大量错误。

Lab1: Flawed enforcement of business rules（业务规则的执行存在缺陷）

在这里插入图片描述

随便输入一个邮箱，会得到优惠券
到这里我们共有两张优惠卷SIGNUP30和NEWCUST5，两个优惠券重复输入，即可把价钱薅到0

Lab2: Infinite money logic flaw（无限金钱逻辑缺陷）

在这里插入图片描述

账号:wiener密码:peter
漏洞逻辑：登录账户，领取优惠券：SIGNUP30,领取优惠券后，使用优惠券购买$10礼品卡,最后进入我的账户兑换礼品卡，得到$10，每经历一次该流程账户余额可增加$3这就是无限金钱逻辑漏洞。
开启bp后，正常登录，领取优惠卷SIGNUP30
尝试利用优惠卷购买礼品卡
得到兑换码，进行兑换$10，薅羊毛薅了$3,利用bp写宏，进行快速薅羊毛
使用burp实现自动薅羊毛
打开burp的“项目选项”->“会话”，设置“会话处理规则”，点击“添加”
点击“范围”选项卡，设置“网址范围”，选择包括所有的网址
选择“详细”选项卡，设置“规则行动”，选择“添加->运行宏”
进入“会话处理动作编辑器”，点击“添加”，进入“宏编辑器”与“宏记录器”，选择url
选择这五个数据包

POST /cart
POST /cart/coupon
POST /cart/checkout
GET/cart/order-confirmation?order-confirmed=true
POST /gift-card

在这里插入图片描述

在请求列表中，选择GET /cart/order-confirmation?order-confirmed=true,单击“项目设置",点击“添加”，为参数命名gift-card（注意这里只能命名为gift-card）并选中突出显示响应底部的礼品卡代码
选择POST /gift-card请求并再次单击“项目设置”，配置如下
宏编辑器中，单击“测试宏”,查看对GET /cart/order-confirmation?order-confirmation=true生成的礼品卡代码的响应并记下,看POST /gift-card请求,确保gift-card参数匹配并确认它收到了302响应,继续单击“OK”，直到返回主 Burp 窗口
将GET /my-account请求发送给 Burp Intruder。使用“Sniper”攻击类型并清除默认的有效载荷位置，在“有效载荷”选项卡上，选择有效载荷类型“没有载荷”。在“有效载荷选项”下，选择生成412有效载荷，转到“Resource pool”选项卡并将攻击添加到“Maximum concurrent requests”设置为1，注意必须设置线程为1，不可多线程，因为有顺序，最后开始攻击。
攻击完成后，我们将有足够的$来购买夹克并解决实验室问题,这里太慢了我就不截图了

Providing an encryption oracle（提供加密预言机）

当用户可控制的输入被加密并且随后以某种方式向用户提供得到的密文时，可能会发生危险的情况。这种输入有时被称为“加密预言机”。攻击者可以使用此输入使用正确的算法和非对称密钥加密任意数据。

当应用程序中有其他用户可控制的输入期望使用相同算法加密数据时，这就变得危险了。在这种情况下，攻击者可能会使用加密预言机生成有效的加密输入，然后将其传递给其他敏感函数。

如果站点上有另一个用户可控制的输入提供相反的功能，那么这个问题可能会更加复杂。这将使攻击者能够解密其他数据以识别预期的结构。这为他们节省了创建恶意数据所需的一些工作，但不一定是成功利用漏洞所必需的。

加密预言机的严重性取决于哪些功能也使用与预言机相同的算法。

Lab: Authentication bypass via encryption oracle（通过加密机绕过身份验证）

在这里插入图片描述

此实验室包含一个逻辑漏洞，该漏洞会向用户暴露加密预言机
登录账户：wiener:peter
在勾选“Stay logged in”选项的情况下登录，找一篇文章发表评论
使用 Burp 的手动测试工具研究相应的请求和响应，观察stay-logged-incookie 是否已加密
邮箱格式正确的时候（xxx@xx.xx）评论正常
再写一个错误的邮箱测试，会得到一个错误提示,我们观察他的重定向包/post?postId=3
这里发现当我们尝试使用无效的电子邮件地址提交评论时，响应中会在将我们重定向到博客文章之前设置一个加密的cookie notification。
并且错误消息email以明文形式反映了我们从参数中输入的信息： Invalid email address: 1，因此推断必须从cookie notification 中进行解密。
用bp向Repeater发送POST /post/comment和后续GET /post?postId=3，（注意我这里重定向为GET /post?postId=3)请求,这个请求中也包含notification cookie
可以看出加密用的是数据包POST /post/comment
解密用的数据包是GET /post?postId=1，在解密请求中，复制我们的stay-logged-incookie 值并将其粘贴到notificationcookie 中，发送请求响应得到 wiener:1667736886083
这表明 cookie 的格式应该是username:时间戳，转到加密请求将电子邮件参数更改为administrator:your-timestamp. 我这里为administrator:1667736886083发送请求，然后notification从响应中复制新的cookie。
重新编码数据并将结果复制到notification解密请求的cookie 中，发送请求后，得到错误消息，说明其使用的是基于块的加密算法，并且输入长度必须是 16 的倍数。
所以我们需要Invalid email address: 用足够的字节填充“ ”前缀，以便字节数将删除的是 16 的倍数，即16*2-23=9，我们可以填充9个无关字节
email=yyyyyyyyyadministrator:1667736886083
这样删除字符的时候删除32个字符，只剩administrator:1667736886083就能确保解密正确

administrator:1667736886083无需确保一定要是16的倍数，分组加密算法会自动往结尾padding。这也是为什么一开始base64解密结果是64位的原因：64-23=41位，说明去掉前面前缀Invalid email address:后还剩41位的加密块，但是实际内容只剩下27位administrator:1667736886083，自动填充了14位，从而确保总数是16的倍数64.

在这里插入图片描述

接下来我们只需拦截抓包GET /post?postId=3，将sessioncookie彻底删除，将cookie替换stay-logged-in为我们自制的cookie密文，然后放包，这样我们就可以以管理员身份登录并可以访问管理面板。

yh野良

关注

2
点赞
踩
3

收藏

觉得还不错? 一键收藏
打赏
1
评论
Examples of business logic vulnerabilities——bp业务逻辑漏洞示例

然而，无论你是bug赏金猎人、pentesting，甚至只是一个试图编写更安全代码的开发人员，你都可能在某个时候遇到来自不太熟悉的领域的应用程序。在这种情况下，您应该阅读尽可能多的文档，并在可能的情况下与该领域的主题专家交谈，以获得他们的见解。在正确的环境下，这种缺陷会对与业务相关的功能和网站本身的安全产生毁灭性的后果。要识别这些漏洞，您需要仔细考虑攻击者可能具有的目标，并尝试使用提供的功能找到实现这一目标的不同方法。在本节中，我们将提供一些应该避免的常见假设的警示示例，并演示它们如何导致危险的逻辑缺陷。
复制链接

扫一扫