2021 OWASP TOP 4：不安全的设计

一、业务逻辑漏洞

1、业务逻辑漏洞的定义

当开发者在设计一个 Web 应用时，没有进行充分的逻辑考虑，导致 Web 应用的逻辑设计不够充分，就容易导致业务逻辑漏洞的产生。这么说有点抽象，我们一起来看一个示例：

在一个购物网站中，我们在购物的时候抓包，结果如下：

POST /cart HTTP/1.1
Host: acf51f0c1eaff6e6c0f28fae00f80084.web-security-academy.net
Cookie: session=R4pFnL8mM0tsrGHnit3y3ZdPgYQd9n1B
Content-Length: 50
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/95.0.4638.54
Referer: https://acf51f0c1eaff6e6c0f28fae00f80084.web-security-academy.net/product?productId=1
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

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

可以看到，我们在购物的时候，不仅仅可以输入数量，甚至还可以输入产品的价格。那我们就自然的会去尝试对它进行修改，这里我们将它改为 1试试，可见价格已经发生了改变：

这样，我们就可以花费很便宜的价格，去购买很昂贵的商品了。这就是一个业务逻辑漏洞，它的根本原因在于允许用户修改单价。

这就是应用开发者考虑不够充分导致的问题，他们可能认为只要前端页面无法修改单价就行，但是攻击者会有别的方式去修改，比如使用burpsuite进行抓包。

2、业务逻辑漏洞的危害

由于不同 Web 应用具有不同的业务逻辑，所以业务逻辑漏洞的影响范围很广很杂。但是很多的逻辑漏洞攻击，都可能会对整个 Web 应用造成很严重的后果。

比如登录授权机制上的逻辑漏洞就会对应用产生数据泄漏的影响，攻击者可以利用它进行权限提升或者绕过登录验证，从而获得一些敏感数据。

而经济交易中的逻辑漏洞，则可能会允许攻击者窃取资金或进行欺诈行为，导致很多的经济损失。比如低价购买商品，超额转账等。

这里推荐两篇文章，可以看看事实存在或者已经发生过的业务逻辑漏洞实例：

• https://wenku.baidu.com/view/be1c05dc740bf78a6529647d27284b73f242360e.html
• https://www.pianshen.com/article/1550503577/

4、业务逻辑漏洞的防御思路

单来说，抵御业务逻辑漏洞有两个关键。第一点，确保应用的开发者和测试者理解应用的功能。第二点，避免开发者对用户的行为以及应用其他部分的行为做出错误的预期。

展开来说，就是需要明确自己对应用输入作出的预期假设，并执行必要的逻辑验证去判断输入是否符合预期，在将所有的输入经过验证之后才予以使用。

二、包含敏感信息的报错

1、信息泄露的定义

当攻击者恶意发起一些 Web 应用设计者预期之外的操作，使得 Web 应用无意的将一些敏感信息展示给攻击者，这就是信息泄露漏洞。这些敏感信息可能是其他用户的隐私信息、敏感的商业信息以及 Web 网站的技术细节。

泄露用户的隐私信息和敏感的商业信息都是非常危险的，而 Web 网站的技术信息泄露其实也很重要，攻击者很可能会借助这些信息，进一步发起对这个 Web 应用的恶意攻击行为。

2、信息泄露的示例

导致信息泄露的方式有很多种，这里我们对其中的几种做一下简单介绍：

1) robots.txt 信息泄露

在我们的网站根目录下，大多会有这样一个文件：robots.txt。

个文件主要是用来限制整个站点的搜索引擎访问情况，即设置哪些内容可以被访问，哪些内容不可以被访问。如果在这个文件中，包含了用户不可见目录的信息、结构以及内容，那么攻击者就可以访问这个文件来获取这些隐私信息，这就是一个典型的信息泄露示例，比如下面这样：

2） 错误信息泄露

其实前面我们在进行SQL注入学习的时候，就已经提到过错误信息泄露的，但是我们这里单独的给他拿出来理一理。

在我们对 Web 应用进行错误的操作，那么就可能会得到一些报错信息，比如下面这个示例：

从图中，我们已经看到这条飞狗的详细描述了。此外，我们还发现，这个 Web 应用是通过 GET 方式上传参数 productId。为了让页面显示出报错信息，我们将 productId 的值改为一个字符类型例如 App，这样页面就可能会出现参数类型错误。可以看到，页面确实爆出来了很多错误信息。

这就是一个典型的错误信息泄露漏洞。

3）备份文件泄露

Web 应用管理者，在更新 Web 应用时，很可能会将网页内容进行备份。如果管理者出于方便考虑，直接将备份文件放到网站目录下，并且没有对它进行访问控制的设置，那么攻击者就可以直接访问这个文件名，来获取备份文件。

事实上我们作为攻击者来说，是并不知道这个备份文件的文件名的，但是我们可以通过目录爆破的方式来探测是否存在备份文件，比如下面这样的一个字典就是专门针对备份文件的一个爆破字典：

/2022.zip
/a.zip
/old.zip
/web.zip
/1.zip
/a.zip
/2021.zip
/1.rar
......

3、信息泄露的原因

信息泄露漏洞产生的方式多种多样，不过它可以分为三种类型：

• 第一类

  Web 应用的开发者在开发时需要写入一些调试信息，来方便自己及他人的合作开发，这是正确的行为。但是部分开发者在将 Web 应用正式部署上线时，忘记将这些信息删除干净，导致用户可以看到这些信息，这就导致了信息的泄露。
  

• 第二类

  由于 Web 应用的开发者没有正确的对 Web 页面进行配置。这使得在 Web 页面出现错误时，会详细的给用户展示出很多包含敏感信息的报错内容。我们在查看飞狗页面引起的报错中，就属于这种情况。其实这更像是OWASP TOP 10中的配置错误漏洞，只不过他的直接表现形式是导致敏感信息泄露。
  

• 第三类

  最后一种情况是最为普遍的，这是因为 Web 应用开发者的不安全设计所导致的，也就是说在程序开发过程中，系统逻辑设计或者程序开发本身就存在问题，导致了信息泄露。
  

4、信息泄露的防御

因为造成信息泄露的途径多种多样，所以我们很难全面的去做好对信息泄露漏洞的防御。不过我们还是要采取一些措施，来降低信息泄露漏洞的可能性

首先，我们需要让所有的 Web 应用开发者知道什么是敏感信息，因为有些信息可能看起来很安全，没有什么危险之处，但事实上它的泄露会给应用造成极大的安全威胁。

其次，我们要做到让报错信息趋于通用化，而不是在报错信息中将一些关于应用运行方式的线索传递给攻击者。

最后，我们还要彻底地理解 Web 应用程序运行的配置信息以及安全执行策略，然后禁用掉其中不需要的功能，防止这些功能造成信息泄露问题。

三、用户账户安全

用户账户安全，主要包含了OAuth 授权漏洞、访问控制漏洞及权限提升以及身份验证漏洞这三个方面。下面我们对着三个漏洞做一下简单介绍.

1、OAuth 开放授权

现在很多的 Web 应用支持我们用其他 Web 应用的账号进行登录。使得我们不需要给每个 Web 应用都注册一个账号，这对我们来说非常方便。你可能会好奇这是如何实现的？为什么一个 Web 应用能用另一个 Web 应用的账号信息登录。事实上，它是使用 OAuth 框架来实现的这一方法的。

OAuth 是一种常用的授权框架。Web 应用程序可以利用它，对另一个 Web 应用的用户账户发起访问请求。因为如今使用的授权机制几乎都是 OAuth2.0，所以我们这里讲的 OAuth 指的是 OAuth2.0。

OAuth 的授权过程会有三方参与，它们分别是待授权的 Web 应用、授权用户以及 OAuth 服务提供者。

OAuth 有很多种不同的授权方式，我们往往会将这些不同的授权方式称为授权类型。目前，有两个授权类型得到了 Web 应用的广泛使用。它们分别为授权码授权和隐形授权，在授权过程中，它们都会经历下图中的六个阶段：

这就是OAuth 授权的理想实现方式。在部分授权类型中，OAuth 授权对用户身份的验证方法存在错误，这就会导致 OAuth 授权漏洞。

比如下面这个示例：

我们可以使用其他平台的账户授权登录，在授权时候需要输入密码，验证成功后就会对我们的应用进行授权，我们在登录成功后进行抓包：

POST /authenticate HTTP/1.1
Host: accd1fdc1ef72178c0ab064f006d0028.web-security-academy.net
Cookie: session=4XXdLxkBBr2PHqqJiuogfnxTH5o84ixX
Content-Length: 103
Accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

{
    
    "email":"[email protected]","username":"wiener","token":"G3dOwAKEb2Dg2UnFfoH2UjVpGIaq833HrGaJg2_nEWg"}

可以看到，我们这里的授权令牌就是我们token。现在我们已知另外一个用户的邮箱是[email protected]，尝试用如下报文修改邮箱后进行登录：

POST /authenticate HTTP/1.1
Host: accd1fdc1ef72178c0ab064f006d0028.web-security-academy.net
Cookie: session=4XXdLxkBBr2PHqqJiuogfnxTH5o84ixX
Content-Length: 103
Accept: application/json
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
Connection: close

{
    
    "email":"[email protected]","username":"wiener","token":"G3dOwAKEb2Dg2UnFfoH2UjVpGIaq833HrGaJg2_nEWg"}

这里我们仅仅改动了邮箱账号，继续使用了我们的token进行验证，结果成功的登录到了[email protected]这个账号，说明确实存在授权漏洞。

这就是一个典型的授权漏洞，我们简单的分析一下他的原因，其实不难猜到，我们的web程序在请求获取授权信息后，仅仅是通过判断是否存在授权码token来验证用户的登录状态的，并没有对这个token的可信成都进行检测，导致了这样 的问题。

2、权限提升漏洞

在我们的web程序中，权限提升漏洞，通俗的说就是我们的普通用户提升权限为admin用户，也就是我们所说的纵向越权漏洞。

关于越权漏洞，其实可以参考我们的OWASP TOP 1中的失效的访问控制，这里就不在做过多赘述。

3、身份验证漏洞

最常见的身份验证漏洞可能就是我们的登录账号爆破的问题，关于这个漏洞的介绍，也可以参考一下上面提到的失效的访问控制中提到的问题，也可以参考一下登录爆破的一些技术文章。这里也就不在赘述。

4、防御方法

对于OAuth漏洞来说，可以让授权令牌仅仅可用一次，这样就能很好地避免授权令牌的重复使用。对于待授权的客户端应用来说，可以将授权令牌绑定发起授权请求的用户，这样就使得攻击者无法使用自己的授权令牌来登录其他用户的账户。

对访问权限提升漏洞，我们可以将所有非公开的资源默认设置为拒绝访问，这样就可以避免因为忘记配置拒绝访问而导致的访问控制漏洞。

对于身份验证漏洞，我们应该遵循下面的原则：

• 注意验证用户的凭据，确保这个凭据只有用户拥有，且他人无法伪造
• 在登录时防止暴力破解，我们可以用验证码等操作来增加攻击者的攻击成本
• 多次检查身份验证逻辑，防止因为验证逻辑出现错误导致身份验证漏洞