【问题标题】:Restful API: Sensitive data in urlRestful API:url中的敏感数据
【发布时间】:2021-10-20 19:52:26
【问题描述】:

我想创建一个 API 来获取客户详细信息。

url 可以是 Get https://../customers/{customerId}。

我的问题是customerId很敏感,可以在url中传递吗?

如果没有,最好的方法是什么?

【问题讨论】:

  • 这里明显的答案是否定的,但是是什么让 customerId 敏感??
  • 您可以加密该值,或使用时间值对其进行散列,但我不明白您为什么要为 ID 费心费力。这意味着如果您担心用户可能通过错误的 ID,您的 API 的其他元素是不安全的

标签: api-design


【解决方案1】:

奇怪的是customerId 是信息的敏感部分。你也没有分享太多的背景。我能想到的使其安全的选项:

  • 将敏感的 customerId 替换为链接到 UUID 或其他非敏感信息,然后从 UUID 查找以找到真正的客户。
  • 使用 POST https,以便保护任何敏感信息

【讨论】:

  • 是的,第一个建议:它需要前端有一个映射机制,这可能有点矫枉过正。 POST 和 https 是否足够安全?
  • https 和 GET 安全吗?
  • 如果您有正确的设置(即 HTTPS 的有效证书),那么您通过 HTTPS 的 POST 的有效负载是安全的(银行和支付表单都是这样做的)。 HTTPS 上的 GET 对于 HTTP 标头是安全的,但对于 GET 的 URL 参数(即 senf 纯文本)则不安全。
【解决方案2】:

第一个问题,customerId真的敏感吗? 在某些时候,您的客户端会将资源标识符传递给 API。即使您加密了该值,或者将其作为 POST 请求打包到负载中,该值仍然可以被检查,并且仍然可以被真正想要访问或更改它的客户端或数据包嗅探器伪造。

答:可以,可以在url中传递customerId

这是一个标准的期望,实际上它可能与 尝试 解决在路由中传递 Id 的直觉相反,如果Id 是路由的一部分。

但有可能……

具体实现将取决于您的运行时和代码框架,但作为一种设计模式 可以将重写模块或中间件写入服务器,以便解密加密的查询字符串,然后将响应管道在内部重定向到 internalsecure 路线。通过这种方式,您可以在标准 API 处理之间注入这个 security 层,并且不必在每个端点编写任何特殊的 hack 代码来解析从客户端传递的 Id。

然而……

这意味着客户端必须加密或计算要发送到 API 的值,这意味着现在客户端拥有可以创建令牌的代码,因此对逻辑进行逆向工程并创建您自己的令牌给其他个客户。

代替加密

在我遇到的上一个项目中,这是一个虚荣问题。我们不希望用户通过更改 URL 中的 ID 来尝试破解系统,并且在某些情况下,他们只是不希望用户感觉像一个数字...

所以在这种情况下,它与真正的安全性或机密性无关,而 100% 我称之为虚荣

通过这种方式,客户端使用参数调用 API 上的端点,并返回一个 token。最后我确实使用了加密来避免存储原始参数,但关键是 API 返回一个它知道如何解密的令牌。

您可能熟悉 Tiny URL 服务,这几乎是相同的概念。

我发现用户加密更简单,在这种情况下,服务器同时拥有加密和解密密钥,因此我不担心客户端受感染的人可能会危及安全性,但同样,这不是作为安全功能实现的.

【讨论】:

  • 感谢您的回复。客户 ID 就是一个例子。如果我将数据放在有效载荷或标头中,有效载荷是否易于检查?另一个问题是将其存储在有效负载中是否也不安全。将其放入oauth令牌更好吗?
  • 喝酒之间的时间太长了!从标头和内容(有效负载)读取的工作几乎相同,除了标头不会被压缩,即使内容是。从漏洞的角度来看,headers 更容易受到攻击,因为在许多连接处,headers 比内容更有可能被记录,但从安全传输的角度来看,存在没有太大区别。此处重点讨论 SSL 加密:stackoverflow.com/q/187655/1690217
  • 谢谢,如果启用了https,在传输过程中头部和内容都会被加密,对吗?如果我启用 https,这是否意味着所有内容(内容和标题)都是安全的?
  • Https (TLS) 是标准的安全级别,但它只保护传输中的消息。还有其他原因,您可能会选择使用其他形式的加密或散列,但将客户 ID 视为敏感并不常见,因此文档中的指导较少。我有一个 API 配置为从身份验证令牌中提供的声明中提取 URL 令牌,这意味着 CustomerId 永远不会以纯文本形式记录或提供,但后端代码“认为”它是,所以我们不必这样做服务器端有什么特别的,但客户端需要改变
  • 但是,使用 https 时,标题和内容是安全的,只有 url 可以轻松访问。但我仍然对它为什么重要感到困惑。我认为解决这个问题很重要,因为它与正常实现相比是一个重大变化。在我看来这是一个 XY 问题:xyproblem.info
猜你喜欢
  • 2020-11-10
  • 2016-09-12
  • 1970-01-01
  • 2011-05-15
  • 2019-12-16
  • 1970-01-01
  • 1970-01-01
  • 2011-07-25
  • 1970-01-01
相关资源
最近更新 更多