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

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

对于软件工程师来说,他们可能很容易认为没有黑客会针对我们的应用,因为我们的应用并不大,也不出名。这种态度可能会导致鲁莽行事,降低应用数据保护措施。但是,重要的是要记住,组织收集的数据非常有价值。如果泄露用户的个人身份信息 (PII),还可能会产生法律后果,例如针对企业的诉讼。

什么是过度数据暴露?

API 响应返回的数据多于客户端需要的数据时,就会发生过度数据泄露。根据经验,例如,如果客户端应用程序需要三个字段,则不应返回整个对象。过度数据泄露是 API 安全方面的一大隐患,在设计 API 时,每个工程师都应首先考虑这一问题。

在本文中,您将了解 Ruby on Rails 中的过度数据暴露问题。读完本文后,您将了解以下主题:

  • 数据敏感度级别
  • Ruby on Rails 中过度数据暴露的示例
  • 过度数据暴露预防措施

数据敏感度级别

一旦从用户那里获取了数据,就会根据其敏感度对其进行分类,敏感度是指如果被第三方更改或窃取,会对组织造成何种影响。在本节中,您将了解应将数据分为哪四个级别。

  • 公开:这些数据在向公众展示时不会构成安全威胁。这些数据包括员工名录、密码验证提示等。
  • 内部:这是组织内部使用的数据,如果暴露给组织外部的人员,将会产生危害。例如,不包含机密信息的电子邮件通信。
  • 敏感数据:这是属于组织内用户且高度机密的数据。例如信用卡信息、社会保险号、API 密钥、访问令牌等。
  • 受限:这是只有组织中的少数成员才能访问的数据,例如高度机密的商业信息。

现在您已经了解了不同层级的数据敏感度,在下面的部分中,我们将查看一个示例 API 响应,以了解有关过度数据暴露的更多信息。

API 响应示例

对于此示例,假设显示用户个人资料的游戏应用程序 API 可能会向客户端应用程序返回类似以下代码片段的原始用户对象:

{
"id": 34,
"username": "trojan",
"level": 7,
"location": "Nairobi,Kenya",
"phone_no": "+254678543110",
"bio": "Kenyan gamer",
"address": "Corner Street, Karen, house 24",
"access_token": "FLWSECK_TEST-917984d85944319929e4280429ce5523-X"
}

乍一看,您可能没有注意到上述 API 响应有什么问题。但您将在下一节中看到返回此类原始数据如何导致 Rails 应用程序中的数据过度暴露。

过度数据暴露的例子

上述 API 响应会以下列方式导致过度数据暴露。

返回未过滤的数据

上述 API 响应返回未经过滤的原始数据,因此客户端应用程序需要过滤掉有关用户的敏感信息。客户端应用程序只需要用户名、个人资料和级别字段,因此返回的额外字段毫无用处。在这种情况下,返回的数据超过客户端应用程序需要的数据就属于数据暴露过多的情况。

如果黑客拦截此 API 响应,他们就可以查看所有敏感数据,更糟糕的是,还可以复制数据并在暗网上出售。

使用自动递增主键

除非另有说明,否则 Postgres 数据库默认使用自动递增主键。由于主键与 URL 一起作为 ID 发送,因此任何嗅探网站流量的人都可以访问该 ID,该 ID 是一个连续递增的整数。它让第三方知道数据库的数量级。例如,如果获取用户数据的 API 是/user/1870,他们就知道您的数据库已存储了数千名用户的数据。

在 API 响应中返回个人身份信息

PII 是可用于识别个人的任何数据,并且永远不会显示在网站或移动应用程序上。PII 包括个人的身份证号码、电子邮件、信用卡详细信息、社会安全号码、家庭住址、驾驶执照等。在 API 响应中返回 PII 是重大数据泄露和过度数据暴露的情况。如果黑客获得 PII 访问权限,这可能会导致用户在被发现后提起诉讼,进而导致小公司破产。API 安全对公司及其用户都极为重要。

您已经看到了过度数据暴露的例子,以及 API 设计流程如何导致安全漏洞。因此,在下一节中,让我们了解预防措施。

保护措施

下面列出了一些保护 Rails 应用程序免受过度数据暴露的方法。

不要使用自动递增主键

由于主键在 URL 和网络日志中作为 ID 值公开可发现,因此最好使用通用唯一标识符 ( UUID )。 UUID 是随机且唯一的,没有人可以猜出数据库的数量级。

实施服务器授权检查

使用CanCanCan授权 gem。它定义了访问规则,通过更改 URL 中的 ID 来限制某人查看其他人的记录。除非获得授权,否则用户不能更改 URL 中的 ID 来查看其他用户的个人资料数据。

使用数据屏蔽

数据屏蔽用于隐藏数据库中的敏感信息(例如用户的电子邮件),并且仅在 API 响应中显示非敏感信息。

加密您的数据

如果您的应用必须存储个人身份信息,则应将其全部加密。加密可保护所有敏感信息免遭窥探。通过加密,即使攻击者获得了您的数据库或 API 响应的快照,他们也无法理解数据。

不要返回未经过滤的原始 API 响应

设计 API 时,请使用最小权限原则,仅返回用户需要的数据。将未经过滤的原始数据返回给移动或 Web 应用程序绝不是一个好主意。检查每个 API 响应,并在将数据呈现给客户端之前在服务器上过滤掉用户不需要的数据。

不要存储敏感的 PII 数据

使用第三方存储敏感数据。例如,对于所有信用卡详细信息,您都应将其存储在Stripe等第三方中。在这种情况下,信用卡详细信息在任何情况下都不会显示在任何 API 请求中,因为您不会将它们存储在自己的数据库中。

您应该根据本文中学到的知识评估您的 API 是否安全。如果不安全,您应该考虑使用上述一些预防措施。

结论

在本文中,您了解了过度数据暴露是什么、数据敏感度级别,以及在设计 Rails API 时可能导致过度数据暴露的示例。最后,您了解了需要采取哪些措施来防止过度数据暴露。

数据是任何公司都应不惜一切代价保护的重要资产。确保用户数据安全可保护您的公司免受诉讼造成的损失并保护公司形象。对于 API 请求,您不应默认返回数据库中存储的所有字段。数据安全有助于客户信任您的企业并向其提供数据。

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

#你可能也喜欢这些API文章!
搜索、试用、集成国内外API!
幂简集成API平台已有 4677种API!
API大全