AngularJS SPA与RestfulAPI服务器安全

Question

快速背景：

与AngularJS服务器对话的完整Javascript SPA REstful客户端。我正在尝试为API服务器进行最好的身份验证。客户端将有角色，我不担心用户是否能够看到客户端的区域，因为服务器应该是密封的。

身份验证流程：

• 用户发布用户名和密码，比如/api/身份验证
• 如果用户，服务器生成api令牌(字段的沙散列或md5)和其他一些元数据，这些元数据决定要在回复后返回的角色。
• 令牌存储在会话cookie中(没有exp、仅http、ssl)。
• 身份验证后的每个请求都接受cookie中的令牌，并验证这是用户。
• 服务器上的SSL用户。

问题：

• 这是保护服务器的最佳方式吗？
• 我是否需要担心重放攻击w/ SSL？如果是最好的方法来处理这个问题呢？
• 我试图用AngularJS来实现HMAC安全，但我不能在javascript客户机上存储私钥。
• 我最初使用了http身份验证方法，但是发送用户名和密码，每个请求似乎都很奇怪。

如有任何建议或例子，将不胜感激。

Answer 1

我目前正在使用angularjs+node作为REST进行类似的情况，使用HMAC进行身份验证。

不过，我正在做这方面的工作，所以我的调子在任何时候都可能发生变化。不过，这是我有的东西。任何愿意在这方面戳洞的人，我也欢迎这一点：

1. 通过https进行用户身份验证、用户名和密码
2. 服务器(在我的例子中是node.js+express)向经过身份验证的用户发送临时通用私钥。这个键是用户用来签署HMACs客户端的，并且存储在浏览器上的LocalStorage中，而不是cookie (因为我们不希望它在每个请求上来回移动)。

- The key is stored in nodejs memory and regenerates every six hours, keeping record of the last key generated. For 10 seconds after the key changes, the server actually generates two HMACs; one with the new key, one with the old key. That way requests that are made while the key changed are still valid. If the key changed, the server sends the new one back to the client so its can flash it in LocalStorage. The key is a SHA256 of a UUID generated with node-uuid, hashed with crypto. And after typing this out, i realize this may not scale well, but anyway ...

​

1. 然后，密钥存储在浏览器上的LocalStorage中(如果在尝试登录之前不支持LocalStorage，则应用程序实际上会弹出一个浏览器太老的页面)。
2. 然后，在初始身份验证之后的所有请求都发送三个自定义标头：

- `Auth-Signature`: HMAC of `username`+`time`+`request.body` (in my case `request.body` is a `JSON.stringify()`'d representation of the request vars) signed with the locally stored key
- `Auth-Username`: the `username`
- `X-Microtime`: A unix timestamp of when the client generated its HMAC

​

1. 然后，服务器检查X-Microtime头，如果X-Microtime和now之间的间隔大于10秒，则删除请求作为潜在的重放攻击，并返回401。
2. 然后，服务器使用与客户端相同的序列生成自己的HMAC，Auth-Username+X-Microtime+req.body使用节点内存中的6小时私钥。
3. 如果HMACs是相同的，相信请求，如果不是，401。如果我们需要处理Auth-Username上任何特定于用户的内容，那么我们就有了API头。

显然，所有这些通信都是在HTTPS上进行的。

编辑：

在每次成功请求之后，必须将密钥返回给客户端，以便使客户端与动态密钥保持最新状态。这是有问题的，因为它所做的事情与cookie所做的基本相同。

您可以使密钥保持静态且永不更改，但这似乎不太安全，因为密钥永远不会过期。您还可以为每个用户分配一个键，在登录时返回给客户端，但是无论如何，您仍然必须对每个请求进行用户查找，最好在此时使用基本的auth。

编辑#2

所以，在做了一些自己的测试之后，我决定使用一个后端代理来使用我的REST，它仍然使用HMAC。

1. 角连接到同一域后端，后端从上面运行HMAC过程，私钥存储在此代理上。使用相同的域可以阻止cors。
2. 在成功的auth中，角只得到一个标志，我们将登录状态存储在LocalStorage中。没有键，但是一些标识用户的东西是可以公开的。对我来说，这个存储值的存在决定了用户是否登录。我们在他们注销时删除localStorage，或者我们决定使他们的“会话”无效。
3. 从角到相同域代理的后续调用包含用户头。代理检查用户头(因为我们阻止了跨站点访问而只能设置)，返回401 (如果没有设置)，否则只将请求转发到API，但HMAC希望如此。API将响应传递回代理，从而返回到角。

这使我们能够将私有比特保留在前端之外，同时仍然允许我们构建一个API，该API可以在不对每个请求进行DB调用的情况下快速进行身份验证，并且保持状态无状态。它还允许我们的API为其他接口服务，比如本地移动应用程序。移动应用程序将与私钥捆绑在一起，并为每个请求运行HMAC序列。