所有文章 > 技术杂货铺 > Spring 过度数据暴露:示例与预防
Spring 过度数据暴露:示例与预防

Spring 过度数据暴露:示例与预防

API 本质上是一种为客户端提供软件接口的工具——这就是它们的作用。 

一些 API 方法会修改应用程序状态,一些会将数据返回给客户端。此外,一些方法可以同时执行这两种操作。一旦我们将数据返回给客户端,我们需要确保只返回必要的数据,并且不会泄露任何敏感信息。 

本文将介绍 API 中过度的数据暴露,并提供示例和预防方法。示例将在 Java Spring 框架的背景下给出。 

REST API 结构

通常,REST API 遵循 API 调用的标准结构。该结构通常由域名、资源、子资源和特定端点组成。例如,类似这样的 URL(http://domain.com/artitsts/artist/albums/album1/song3)将允许用户使用不同的 HTTP 方法(GET、POST、PUT)检索、更新和上传特定艺术家的特定专辑中的歌曲。 

其他端点可以是 http://domain.com/artitsts/albums/album1,它将返回专辑中所有歌曲的列表,以及 http://domain.com/artitsts,它将返回项目列表。 

API 结构嗅探漏洞

如果攻击者猜测或收到端点列表,则可能出现与此结构相关的第一个漏洞和过多的数据暴露。 

如果暴露敏感数据的端点不需要身份验证(如此处所述),攻击者可以访问他无权查看的数据。 

也就是说,攻击者可以使用暴力手段来识别 API 端点。这可以通过随机尝试生成将返回响应的 URL 来实现,或者通过使用常用路径列表来查看服务器是否为它们返回响应。 

例如,一个流行的 REST API 路径是 /users/info。另一个是 /admin。因此,攻击者将创建一个脚本,检查这些路径与域名的组合(http://domain.com/users/info、http://domain.com/admin),并查看其中是否有任何路径返回响应。 

嗅探 API 结构的另一种方法

REST API 标准包括一项名为 HATEOS 的规范,其基本意味着每个 API 响应都应返回与该特定端点相关的其他 API 端点的链接列表。 

如果 API 开发人员只是盲目地返回系统中所有 API 端点的列表,或者返回应该受密码保护但实际上没有的 API 端点,他就会将数据暴露给攻击者。

以下是HATEOS 回应的一个示例,取自相关维基百科条目: 

HTTP/1.1 200 OK 
{ "account":
{ "account_number": 12345, "balance": { "currency": "usd", "value": 100.00 },
"links":
{ "deposits": "/accounts/12345/deposits",
"withdrawals": "/accounts/12345/withdrawals",
"transfers": "/accounts/12345/transfers",
"close-requests": "/accounts/12345/close-requests" }
}
}

API 端点嗅探

攻击者获取敏感信息的另一种方法甚至不需要额外努力去嗅探未记录的 API 方法。 

如果 API 端点返回的信息超出要求,并且依赖前端开发人员来过滤额外数据,那基本上意味着对于这样的端点(http://domain.com/users/user1),应该返回一些基本详细信息,如用户名、电子邮件和上次登录日期,而服务器返回其他数据,如全名和地址。 

服务器依赖前端开发人员过滤掉不需要的信息,并在浏览器/应用中仅显示应该出现的基本详细信息。但是,攻击者可以使用浏览器的开发人员工具或使用外部工具(如 postman)执行 API 请求,并查看服务器返回的完整数据。因此,普通用户将看到类似这样的内容 

HTTP/1.1 200 OK { "user: 
{ "username": "john doe", "email":"johndoe@gmail.com"  }
{

攻击者将看到完整的输出: 

HTTP/1.1 200 OK { "user: 
{ "username": "john doe", "email":"johndoe@gmail.com",
"name: John Doe Smith", "address": "Smith's road 1, NY, NY"  }
{

防止过度数据暴露

什么使数据变得敏感以及什么表明数据过度暴露在很大程度上取决于具体情况。在一个 API 中构成过度数据的东西在另一个 API 中可能是完全合理的响应。 

因此,这意味着自动化工具通常无法帮助您识别和缓解此漏洞。开发人员需要加强 API 以防范此漏洞。 

漏洞缓解

首先,我将提供一些缓解此漏洞的一般准则。然后,我将提供一些特定于 Java Spring 的示例。 

1. 永远不要依赖前端来清理数据

实现 API 的后端开发人员应该只返回非敏感数据。您不应该依赖前端来过滤掉这些数据。

即使前端开发人员正确地过滤掉了不需要的数据,如上所示,攻击者也可以通过独立访问 API 来访问整个响应。 

在下一节中,我将提供一个示例,说明如何避免在 Java Spring 的 API 响应中返回过多的数据。 

2.保护需要身份验证和授权的 API 端点

正如我所描述的,您应该使用身份验证和授权来保护每个返回敏感数据的 API 端点。 

3. 不要通过 HATEOS 公开所有 API 端点

如果您将 HATEOS 作为 REST API 的一部分实现,请不要返回整个 API 方法列表。因此,仅返回与特定端点相关的方法列表。 

Spring Boot

Spring框架是一个用于创建Web应用程序和企业应用程序的卓越Java框架。 

2005 年,Pivotal 开发了 Spring 框架,至今仍非常流行。自从 Pivotal 开发了 Spring 框架以来,他们已经向核心 Spring 容器添加了各种模块。 

Spring Boot 是最常用的框架之一,代表了 Spring 框架的约定优于配置部分。Spring Boot 让你可以用极少的配置进行编码。 

缓解 Spring Boot 中的过度数据暴露漏洞

让我们回到前面讨论的用户端点 API 示例: 

HTTP/1.1 200 OK { "user: { "username": "john doe", "email":"johndoe@gmail.com", "name: John Doe Smith", "address": "Smith's road 1, NY, NY" } {

我们可以在 Spring Boot 中使用以下类来表示它: 

public class User {
    private String username;
    private String email;
    private String fullName;
    private String address;
}

正如我之前提到的,我们希望 API 仅使用用户名和电子邮件进行响应。为此,我们可以将属性添加@JsonIgnore到我们想要在 API 响应中排除的字段: 

public class User {
    private String username;
    private String email;
    @JsonIgnore
    private String fullName;
    @JsonIgnore
    private String address;
}

这会阻止全名和地址出现在响应中。 

结论

API 是许多应用程序和网站的支柱。它们为客户提供关键服务。 

过度数据暴露漏洞是一种严重的漏洞,可能对组织造成安全风险。在这篇文章中,我展示了这种漏洞的利用方式和不同的攻击媒介。 

同样,我添加了一些缓解它的标准方法,并针对 Java Spring Boot 提供了一个具体示例。它成立于 2005 年,是一个非常流行的创建 Java 后端应用程序的框架,并且它仍然是 Java 世界中最流行的框架之一。 

不要依赖前端来过滤敏感数据;相反,手动检查您的端点并确保只返回必要的数据。 

此外,避免提供 API 中所有方法的链接,除非您正在构建 API 文档,并且通常尽可能强化您的 API。 

文章来源:Spring Excessive Data Exposure:Examples and Prevention

#你可能也喜欢这些API文章!