在研究保护Web服务的方法时，除了使用TLS之外，我还发现了一个哈希部分URL的应用程序。我还发现了一个规范，建议通过生成散列并验证内容服务器端来验证请求的主体（规范如下）：
Final: OAuth Request Body Hash
在说明书中，它提到：
Nonce检查和使用https可以降低此风险，但在某些环境中可能无法使用。即使使用随机数检查和https，签署请求主体也会提供额外的防御层。
看看OAuth 2.0规范，似乎他们在正确配置/编码应用程序时认为这些步骤是不必要的，而是依靠TLS来提供安全功能，我相信这些功能包括防篡改功能。虽然这个规范曾经像前主要作者那样受到批评，但在适当实施的情况下（同一个人）也有人说它是安全的。
这些哈希程序有什么实际好处吗？是否存在可能危及仅使用Nonce和TLS验证有效性的Web服务的已知攻击？
答案 0 :(得分：0)
据我所知，快速阅读文档（我对OAuth没有多少了解），你会混淆哈希的目的。包含哈希意味着将覆盖请求的其他部分的签名扩展到正文：
OAuth Core规范仅为application / x-www-form-urlencoded请求主体提供正文完整性检查。其他类型的请求主体是未签名的。
请注意，仅在URL中包含哈希不会提供任何额外的安全性。相反，他们所做的是将其包含在已签名的部分中：
将oauth_body_hash参数设置为获得的值。
根据[OAuth Core 1.0] section 9对请求进行签名。 oauth_body_hash参数必须与其他请求参数一起包含在签名基本字符串中。
因此，他们的声明“即使使用随机数检查和https，签署请求正文也提供了额外的防御层。”指通过RSA（或通过HMAC“签名”）签署URL参数（以及其他内容）的做法，因此也通过包含的散列验证身体。如果URL参数未签名（使用“PLAINTEXT”方法），则通过包含正文的哈希值不会获得任何额外的安全性。