security - 身份验证和 session 管理的 SPA 最佳实践

Question

在使用 Angular、Ember、React 等框架构建 SPA 风格的应用程序时，人们认为身份验证和 session 管理的最佳实践是什么？我可以想到几种方法来考虑解决这个问题。

假设 API 和 UI 具有相同的原始域，则对待它与使用常规 Web 应用程序进行身份验证没有区别。
这可能涉及 session cookie、服务器端 session 存储和一些 session API 端点，经过身份验证的 Web UI 可以访问这些端点以获取当前用户信息，以帮助进行个性化，甚至可能确定客户端的 Angular 色/能力。当然，服务器仍然会强制执行保护数据访问的规则，UI 只会使用这些信息来定制体验。

像对待任何使用公共(public) API 的第三方客户端一样对待它，并使用某种类似于 OAuth 的 token 系统进行身份验证。客户端 UI 将使用此 token 机制对向服务器 API 发出的每个请求进行身份验证。

我在这里算不上什么专家，但#1 对于绝大多数情况似乎完全足够，但我真的很想听听一些更有经验的意见。

Answer 1

这个问题已经以略有不同的形式详细地在此处解决:

RESTful Authentication

但这从服务器端解决了它。让我们从客户端看一下。不过，在我们这样做之前，有一个重要的前奏:

Javascript 加密是无望的

Matasano 关于此的文章很有名，但其中包含的教训非常重要:

https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

总结一下:

中间人攻击可以用 <script>
function hash_algorithm(password){ lol_nope_send_it_to_me_instead(password); }</script> 轻松替换您的加密代码

对于通过非 SSL 连接提供任何资源的页面，中间人攻击是微不足道的。

一旦你有了 SSL，无论如何你都在使用真正的加密。

并添加我自己的推论:

成功的 XSS 攻击可能会导致攻击者在您客户端的浏览器上执行代码，即使您使用的是 SSL - 因此，即使您已经关闭了每个舱口，如果您的攻击者找到执行的方法，您的浏览器加密仍然可能失败其他人浏览器上的任何 javascript 代码。

如果您打算使用 JavaScript 客户端，这会使许多 RESTful 身份验证方案变得不可能或愚蠢。我们看看吧!

HTTP 基本身份验证

首先，HTTP 基本身份验证。最简单的方案:只需为每个请求传递一个名称和密码。

当然，这绝对需要 SSL，因为您在每个请求中都传递了一个 Base64(可逆)编码的名称和密码。任何在线收听的人都可以轻松提取用户名和密码。大多数“基本身份验证不安全”的论点来自“基于 HTTP 的基本身份验证”的地方，这是一个糟糕的主意。

浏览器提供了内置的 HTTP 基本身份验证支持，但它很丑陋，您可能不应该将它用于您的应用程序。不过，另一种方法是在 JavaScript 中存储用户名和密码。

这是最 RESTful 的解决方案。服务器不需要任何状态知识，并验证与用户的每个单独交互。一些 REST 爱好者(主要是稻草人)坚持认为，维护任何类型的状态都是异端邪说，如果您想到任何其他身份验证方法，就会吐口水。这种符合标准的理论上有好处 - 它由 Apache 开箱即用 - 如果您愿意，您可以将您的对象作为文件存储在受 .htaccess 文件保护的文件夹中!

问题 ?您正在客户端缓存用户名和密码。这让 evil.ru 更好地破解它 - 即使是最基本的 XSS 漏洞也可能导致客户端将其用户名和密码发送到恶意服务器。您可以尝试通过对密码进行散列和加盐来减轻这种风险，但请记住: JavaScript 加密是无望的 .您可以通过将其留给浏览器的基本身份验证支持来减轻这种风险，但是.. 丑陋如前文所述。

HTTP 摘要身份验证

Is Digest authentication possible with jQuery?

更“安全”的身份验证，这是一个请求/响应哈希挑战。除了 JavaScript 加密是无望的 ，所以它只能在 SSL 上工作，你仍然需要在客户端缓存用户名和密码，这使它比 HTTP 基本身份验证更复杂，但并不更安全。

使用附加签名参数查询身份验证。

另一个更“安全”的身份验证，您可以使用随机数和计时数据加密参数(以防止重复和计时攻击)并发送。最好的例子之一是 OAuth 1.0 协议(protocol)，据我所知，这是在 REST 服务器上实现身份验证的一种非常棒的方式。

http://tools.ietf.org/html/rfc5849

哦，但是没有任何用于 JavaScript 的 OAuth 1.0 客户端。为什么？

JavaScript 加密是无望的 ， 记住。 JavaScript 不能在没有 SSL 的情况下参与 OAuth 1.0，并且您仍然必须在本地存储客户端的用户名和密码 - 这将其与 Digest Auth 放在同一类别中 - 它比 HTTP Basic Auth 更复杂，但也没有更安全。

token

用户发送用户名和密码，并作为交换获得可用于验证请求的 token 。

这比 HTTP 基本身份验证稍微安全一些，因为一旦用户名/密码事务完成，您就可以丢弃敏感数据。它也不太 RESTful，因为 token 构成“状态”并使服务器实现更加复杂。

SSL 仍然

不过，问题是您仍然必须发送初始用户名和密码才能获得 token 。敏感信息仍会触及您的可妥协 JavaScript。

为了保护您用户的凭据，您仍然需要让攻击者远离您的 JavaScript，并且您仍然需要通过网络发送用户名和密码。需要 SSL。

token 到期

强制执行 token 策略是很常见的，例如“嘿，当此 token 存在时间过长时，将其丢弃并让用户再次进行身份验证。”或“我很确定唯一允许使用此 token 的 IP 地址是 XXX.XXX.XXX.XXX”。这些政策中的许多都是非常好的主意。

火羊

但是，使用没有 SSL 的 token 仍然容易受到称为“sidejacking”的攻击: http://codebutler.github.io/firesheep/

攻击者无法获得您用户的凭据，但他们仍然可以冒充您的用户，这可能非常糟糕。

tl;dr:通过网络发送未加密的 token 意味着攻击者可以轻松获取这些 token 并伪装成您的用户。 FireSheep 是一个使这变得非常容易的程序。

一个独立的、更安全的区域

您运行的应用程序越大，就越难绝对确保它们无法注入(inject)一些改变您处理敏感数据方式的代码。你绝对信任你的 CDN 吗？你的广告商？你自己的代码库？

信用卡详细信息常见，用户名和密码不常见 - 一些实现者将“敏感数据条目”保存在与其应用程序其余部分不同的页面上，该页面可以尽可能严格地控制和锁定，最好是这样的页面很难对用户进行网络钓鱼。

Cookie(仅表示 token )

将身份验证 token 放在 cookie 中是可能的(并且很常见)。这不会使用 token 更改 auth 的任何属性，它更像是一件方便的事情。所有先前的论点仍然适用。

session (仍然只是表示 token )

session 身份验证只是 token 身份验证，但有一些差异使它看起来有点不同:

用户从未经身份验证的 token 开始。

后端维护一个与用户 token 相关联的“状态”对象。

token 在 cookie 中提供。

应用程序环境从您那里抽象出细节。

不过，除此之外，它与 Token Auth 并没有什么不同，真的。

这与 RESTful 实现的差距更大——有了状态对象，您将在有状态服务器上的普通 ol' RPC 路径上越走越远。

OAuth 2.0

OAuth 2.0 着眼于“软件 A 如何让软件 B 访问用户 X 的数据而软件 B 无法访问用户 X 的登录凭据”的问题。

该实现在很大程度上只是用户获取 token 的标准方式，然后第三方服务会“是的，这个用户和这个 token 匹配，你现在可以从我们这里获取他们的一些数据。”

不过，从根本上说，OAuth 2.0 只是一个 token 协议(protocol)。它表现出与其他 token 协议(protocol)相同的属性——您仍然需要 SSL 来保护这些 token ——它只是改变了这些 token 的生成方式。

OAuth 2.0 可以通过两种方式帮助您:

向他人提供身份验证/信息

从他人处获取身份验证/信息

但归根结底，你只是......使用 token 。

回到你的问题

因此，您要问的问题是“我应该将我的 token 存储在 cookie 中并让我的环境的自动 session 管理来处理细节，还是我应该将我的 token 存储在 Javascript 中并自己处理这些细节？”

答案是:做任何让你快乐的事情。

然而，关于自动 session 管理的事情是在幕后发生了很多神奇的事情。通常，自己控制这些细节会更好。

我 21 岁，所以 SSL 是肯定的

另一个答案是:一切都使用 https，否则强盗会窃取您用户的密码和 token 。