Question

Application logic errors , or business logic vulnerabilities , are ways of using the legitimate logic flow of an application that result in a negative consequence to the organization. Sound a bit abstract? The best way to understand them is to look at a few examples.

应用程序逻辑错误或业务逻辑漏洞是利用应用程序的合法逻辑流程导致组织出现负面后果的方式。听起来有点抽象？了解它们的最好方法是看一些示例。

A common application logic error I’ve seen in the websites I’ve targeted is a flaw in the site’s multifactor authentication functionality. Multifactor authentication , or MFA , is the practice of requiring users to prove their identities in more than one way. MFA protects users in the event of password compromise by requiring them to authenticate with both a password and another proof of identity—typically a phone number or an email account, but sometimes via an authentication app, a physical key, or even fingerprints. Most MFA implementations prompt the user to authenticate using both a password and an authorization code delivered via email or text message.

我在攻击的网站中经常遇到的常见应用逻辑错误是网站的多因素认证功能的漏洞。 多因素认证（MFA）是一种要求用户以多种方式证明其身份的做法。 MFA 通过要求用户使用密码和另一种身份证明方式（通常是电话号码或电子邮件帐户，但有时也会通过认证应用程序，物理钥匙甚至指纹）进行身份验证，保护用户在密码泄露事件中的安全。 大多数 MFA 实施会提示用户使用密码和通过电子邮件或短信提供的授权代码进行身份验证。

But MFA implementations are often compromised by a logic error I call the skippable authentication step , which allows users to forgo a step in the authentication process. For example, let’s say an application implements a three-step login process. First, the application checks the user’s password. Then, it sends an MFA code to the user and verifies it. Finally, the application asks a security question before logging in the user:

但是 MFA 实现通常会受到我称之为可跳过身份验证步骤的逻辑错误的影响，这使得用户可以跳过身份验证过程中的某一步骤。例如，假设一个应用程序实现了一个三步登录过程。首先，该应用程序检查用户的密码。然后，它发送一个 MFA 代码给用户并验证它。最后，该应用程序在登录用户之前询问一个安全问题。

Step 1 (Password Check) ▶ Step 2 (MFA) ▶ Step 3 (Security Questions)

步骤 1（密码检查）▶ 步骤 2（多因素认证）▶ 步骤 3（安全问题）

A normal authentication flow would look like this:

一个正常的身份验证流程应该是这样的：

1. The user visits https://example.com/login/ . The application prompts the user for their password, and the user enters it.
2. If the password is correctly entered, the application sends an MFA code to the user’s email address and redirects the user to https://example.com/mfa/ . Here, the user enters the MFA code.
3. The application checks the MFA code, and if it is correct, redirects the user to https://example.com/security_questions/ . There, the application asks the user several security questions and logs in the user if the answers they provided are correct.

Sometimes, though, users can reach step 3 in the authentication process without clearing steps 1 and 2. While the vulnerable application redirects users to step 3 after the completion of step 2, it doesn’t verify that step 2 is completed before users are allowed to advance to step 3. In this case, all the attacker has to do is to manipulate the site’s URL and directly request the page of a later stage.

有时，用户可能会在身份验证过程中达到第 3 步，而无需清除第 1 和第 2 步。 虽然易受攻击的应用程序在完成第 2 步后将用户重定向到第 3 步，但在允许用户进入第 3 步之前，它并未验证是否已完成第 2 步。 在这种情况下，攻击者所要做的就是操纵站点的 URL 并直接请求一个后期阶段的页面。

If attackers can directly access https://example.com/security_questions/ , they could bypass the multifactor authentication entirely. They might be able to log in with someone’s password and answers to their security questions alone, without needing their MFA device.

如果攻击者可以直接访问 https://example.com/security_questions/，他们可以完全绕过多因素身份验证。他们可能只需要使用某人的密码和安全问题的答案就能够登录，而无需使用他们的 MFA 设备。

Another time application logic errors tend to manifest is during multistep checkout processes. Let’s say an online shop allows users to pay via a saved payment method. When users save a new payment method, the site will verify whether the credit card is valid and current. That way, when the user submits an order via a saved payment method, the application won’t have to verify it again.

另一个应用程序逻辑错误往往在多步结帐过程中显现。假设一个在线商店允许用户通过保存的付款方式支付。当用户保存新的付款方式时，网站将验证信用卡是否有效和当前。这样，当用户通过保存的付款方式提交订单时，应用程序就不需要再次验证。

Say that the POST request to submit the order with a saved payment method looks like this, where the payment_id parameter refers to the ID of the user’s saved credit card:

POST 请求识别出具有已保存付款方式的订单，其形式如下，其中 payment_id 参数指的是用户保存的信用卡的 ID：

POST /new_order
Host: shop.example.com

(POST request body)
item_id=123
&quantity=1
&saved_card=1
&payment_id=1

Users can also pay with a new credit card for each order. If users pay with a new credit card, the card will be verified at the time of checkout. Say the POST request to submit the order with a new payment method looks like this:

用户还可以使用每个订单的新信用卡进行付款。如果用户使用新信用卡付款，该信用卡将在结帐时进行验证。提交带有新付款方式的 POST 请求如下所示：

POST /new_order
Host: shop.example.com

(POST request body)
item_id=123
&quantity=1
&card_number=1234-1234-1234-1234

To reiterate, the application will verify the credit card number only if the customer is using a new payment method. But the application also determines whether the payment method is new by the existence of the saved_card parameter in the HTTP request. So a malicious user can submit a request with a saved_card parameter and a fake credit card number. Because of this error in payment verification, they could order unlimited items for free with the unverified card:

强调一下，只有当客户使用新的支付方法时，应用程序才会验证信用卡号。但是，应用程序还通过 HTTP 请求中已保存的 card 参数来确定付款方式是否为新，因此恶意用户可以提交一个带有 saved_card 参数和虚假信用卡号的请求。由于付款验证中的这个错误，他们可以使用未经验证的卡无限制免费订购商品。

POST /new_order
Host: shop.example.com

(POST request body)
item_id=123
&quantity=1
&saved_card=1
&card_number=0000-0000-0000-0000

Application logic errors like these are prevalent because these flaws cannot be scanned for automatically. They can manifest in too many ways, and most current vulnerability scanners don’t have the intelligence to understand application logic or business requirements.

应用程序逻辑错误像这样是普遍的，因为这些漏洞无法自动扫描。它们可能以太多方式表现出来，并且大多数当前的漏洞扫描器没有理解应用程序逻辑或业务要求的智能。