REST API设计：GET需要不应存储在Web服务器日志中的敏感参数

Question

我正在设计一个（as-RESTful-as-possible）API，并想知道如何最好地解决以下问题：

• 假设我们正在设计一个TLS端点来检索某些资源：GET /objects/{id}
• 我们不希望将对象{id}s存储在我们的Web服务器日志中，因此我们希望避免使用查询字符串或URI参数;这让我们在请求体中留下了params。 （假设数据是敏感的，我们无法访问其他非敏感ID）
• 我知道建议不要在GET请求体中使用参数。 HTTP GET with request body
• 我知道建议不要使用POST来获取数据，因为它更倾向于RPC设计风格，并且通常会让人感到困惑。

我们如何（应该）设计API GET端点以避免使用可能被记录的查询或URI参数？
在这种情况下使用POST是否可以接受，还是有另一种创造性方式？
（注意：此API不会向第三方公开）

Answer 1

我认为有很多服务都面临着这个问题，即希望保护敏感标识符。但是，即使这个问题已经存在多年了，我也没有找到合适的解决方案。

所提供的仅更改您的Web服务器日志记录的解决方案并不十分完善（如上所述），但是却忽略了一个事实，即每个客户端在使用您的API时都应该做同样的事情（其中可能包括JavaScript客户端，通过代理，在浏览器中...祝您好运

我知道的解决方案是：

1. 加密参数；但这会使您的API更加复杂，并且需要加密密钥。

2. 使用伪ID，如@ jj-geewax所述；但是，这可能比加密（1）还要复杂，因为您必须为每个敏感参数实例交换一个伪ID：

   • 客户端在向服务器的请求中以伪ID发起，而不是向客户端请求的psuedo-ID解析请求！ （所以客户端也应该有一个端点！）
   • 客户端将敏感ID张贴到服务器，为其接收伪ID，该伪ID可在请求该ID时使用
   • 客户端和服务器已通过其他方式预先交换了伪ID

3. 在请求数据时将正文中的参数发布；这不是REST

   • （可选）使用X-HTTP-Method-Override使您实际请求数据的应用程序更明确。

解决方案3似乎是最简单/最容易实现的方法，尽管它违反了REST设计规则。但是我很想听听替代方法或其他见解。

更新：OWASP说了以下有关请求中敏感参数的信息

HTTP请求中的敏感信息

RESTful Web服务应该小心，以防止泄漏凭据。密码，安全令牌和API密钥不应出现在URL中，因为可以在Web服务器日志中捕获密码，这使它们具有内在的价值。

• 在POST / PUT请求中，敏感数据应在请求正文或请求标头中传输。
• 在GET请求中，敏感数据应在HTTP标头中传输。

https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html#sensitive-information-in-http-requests

这也许比使用（POST）正文要难一些，但是在研究如何实现REST时也要好很多。

Answer 2

如果您使用Apache作为网络服务器，则可以使用CustomLog删除/替换敏感值，this answer提供示例脚本。

Answer 3

通常，如果您坚持使用REST，则应将标识符保留在URL路径（例如/objects/{id}）中，并坚持使用GET HTTP方法，但我对此表示感谢你在挣扎。如果此ID以某种方式是秘密的，那么关闭此不可思议的秘密ID的日志记录绝对是一个好主意。也就是说，您遇到的问题可能表明您的API出现了更大的设计问题，并且阻止了日志记录可能无法解决更大的问题。

例如，这是否是“默默无闻的安全性”（例如，ID是一个秘密，可为任何知道它的人授予访问数据的权限）？还是只是保护敏感信息（例如，PII，例如美国社会保障号所标识的ID）？在这两种情况下，使用此值作为标识符可能都不是一个好主意。

如果此ID本身是敏感的，那么可能值得为每个资源生成一个随机标识符，然后开始传递它。如aip.dev/2510中所述，Google Cloud通过项目（ID与数字）来完成此任务。请注意，他们如何特别声明第三方无法使用项目ID，并且将始终以不透明的项目“数字”作为标识符。

如果这是出于安全考虑，那么您可能需要GET请求中的某种身份验证/授权令牌或标头，从RESTful的角度来看应该没问题。这意味着有人可以保留秘密标识符，因为没有其他一组凭据就没有用了。

我当然会警告不要将HTTP方法切换为POST，只是为了避免记录敏感内容。从长远来看，这将使从事该项目的新员工感到困惑，并阻止您使用任何对API进行RESTful假设的工具。