通过 ssl 完成 OAuth 请求时是否需要验证 nonce？答案

【问题标题】：Is verifying the nonce necessary when OAuth request is done over ssl?通过 ssl 完成 OAuth 请求时是否需要验证 nonce？
【发布时间】：2017-06-10 04:51:02
【问题描述】：

我的应用程序实现了LTI，它使用 OAuth HMAC-SHA1 接收签名请求。它们看起来像：

oauth_version:1.0
oauth_nonce:0aaa53c5d8518ahh56203f5eac773023
oauth_timestamp:1497069755
oauth_consumer_key:foo-test
oauth_callback:about:blank
user_id:99
lti_version:LTI-1p0
lti_message_type:basic-lti-launch-request
oauth_signature_method:HMAC-SHA1
oauth_signature:qe5puCiqcU7UjIe/0NZ0oy4M/8c=

请求只能通过 SSL 发生（我们不实施其他连接选项）。所以我试图确定验证oauth_nonce 是否有任何目的。我相信nonce的目的完全是为了prevent replay attacks，这已经是SSL的一个特性了。

存储 nonce 值会花费每个用户的金钱和时间，所以我只想在有价值的情况下这样做。

当请求通过 SSL 发出时，存储 nonces 和拒绝任何重复请求是否有价值？

【问题讨论】：

视情况而定。您的威胁模型是否包括重放攻击？如果不是，那么您可能不需要随机数，因为不存在坏人重播先前消息的威胁。另请参阅 InfoSec.SE 上的 What is the use of a client nonce?。不要嘲笑消除你不喜欢或不想处理的威胁。 Web 和浏览器安全模型做了很多工作。消除不便的威胁是网络钓鱼在浏览器和其他用户代理中如此严重的原因。用户和针对他/她的一些攻击已从模型中删除。
但是，根据 this answer 在 InfoSec.SE 问题上的说法：“根据 RFC 2617，cnonce 和 nc 参数可以防止选定的明文攻击。” 听起来就像你需要验证它。
我绝对做的是防止重放攻击，但我相信这是 SSL 的一个特性，所以在这里是不必要的。我确实认识到在这里防止这种攻击的价值，我的第一直觉是验证随机数，但是由于存储它会花钱并占用用户时间，我不想无缘无故地这样做。
我投票结束这个问题，因为它不是关于特定的编程问题，而是更多关于特定协议的安全属性。因此最好在 security.stackexchange.com 上询问。
您引用的 RFC (2617) 用于通过普通 http 进行身份验证，不适用于（除了非常普遍）这个问题。

标签： security ssl oauth lti

【解决方案1】：

是与否，

SSL/TLS 通道本身使用 MAC 保护免受重放攻击，使用 MAC 密钥和序列号计算。（MAC 机制确保了 TLS 通信的完整性）。 See TLS 1.1 specification Appendix F.2

但是，这种保护只是防止第三方窃听者看到该应用程序请求，从而防止使用他们自己单独的 SSL/TLS 连接重放它。

但是，SSL/TLS 本身并不一定会阻止合法的初始用户重播请求。需要这种额外保护级别的协议和应用程序往往在应用程序级别具有基于 nonce 的机制（如 LTI OAuth 签名所做的那样）来解决此问题。

【讨论】：

这是一个很好的解决方法，谢谢。在这种情况下，用户多次重放自己的流量不是问题，因为他们无法更改任何内容 - 只能查看那里的内容。如果用户能够修改某些内容，或者如果查看两次是一个问题，那么我们将要验证每个请求的随机数。
同意——这是否在 SSL 中无关紧要。在正常流程中，这些值以自动提交的形式通过浏览器。进行重放攻击的向量是感染浏览器，在数据经过时抓取数据，然后再次发送。两个请求中的 SSL 将相同。

【解决方案2】：

我会观察到 LTI 应用程序通过确保时间戳在 300 秒内并且不太担心随机数来保护启动是很常见的。很多示例代码都实现了这一点。

问题在于，要处理随机数，您需要一个数据库来存储随机数至少与“时间戳窗口”一样长。

有两种实现 LTI 提供程序的通用方法之一。首先，验证启动有效性，然后将所有数据放入会话中并让用户登录。更复杂的应用程序实现会收集所有启动数据，包括随机数，并将其吸收到一组表中。

事实证明，大多数 LTI 实施都是紧急工作，因此他们对“将其置于会话”方法感到满意。构建更复杂的应用程序有很多好处 - 检查 nonce 只是好处之一。但这不是微不足道的。

我构建了一个框架来处理一个应用程序的繁重工作，该应用程序想要处理一组非常丰富的用例，称为“Tsugi”。您可以在以下位置查看 Tsugi 数据模型：

https://github.com/tsugiproject/tsugi/blob/master/admin/lti/database.php

您可以在此代码中查看 Tsugi 如何处理启动（包括随机数）：

https://github.com/tsugiproject/tsugi-php/blob/master/src/Core/LTIX.php

查找名为extractPost、loadAllData 和adjustData 的方法。它们很重要 - 但在单个 JOIN 中，代码会进行秘密查找、数据吸收和随机数检查（您的原始问题）。

我猜你会选择“TL;DR;”版本并只保留 5 分钟的窗口 - 但是如果您快速浏览一下 Tsugi 中的 LTIX 类，您会发现除了单点登录之外，LTI 还可以做很多事情。

【讨论】：