AngularJS SPA和RestfulAPI服务器安全 [英] AngularJS SPA and RestfulAPI Server Security

问题描述

快速背景：

完整的JavaScript SPA AngularJS客户端，会谈到一个RESTful API服务器。我试图制定出API服务器的最好验证。客户端将有角色，我不担心，如果用户可以看到他们是不允许客户端领域，因为服务器应该是气密性的。

Full Javascript SPA AngularJS client that talks to a REstful API server. I am trying to work out the best authentication for the API Server. The client will have roles and I am not concerned if the user can see areas of the client they aren't allowed because the server should be air tight.

认证流程：

• 用户帖子的用户名和密码，让我们说/ API /验证


• 如果用户的服务器生成API令牌确定角色传回1）发表回复和其他一些元数据（字段或MD5的SHA哈希码）。


• 令牌被存储在一个会话cookie（不EXP，只允许HTTP，SSL）


• 验证后的每个请求发生在cookie中的令牌，并验证这是用户。


• 在服务器的SSL用户。

问题：

• 这是为了确保服务器？
的最佳方法

• 请我需要担心重放攻击瓦特/ SSL？如果是最好的方式来管理这个？


• 我试图想办法做AngularJS HMAC的安全性，但我不能存储JavaScript客户端上的私钥。


• 我最初去的HTTP身份验证方法，但发送的用户名和密码，每个请求似乎很奇怪。

任何建议或例子是AP preciated。

Any suggestions or examples would be appreciated.

推荐答案

我目前在类似的情况工作使用angularjs +节点作为一个REST API，使用HMAC认证。

I'm currently working on a similar situation using angularjs+node as a REST API, authenticating with HMAC.

我在这方面的工作，虽然中间，所以我的曲调可以在任何一点改变。这里是我有什么，但。任何人都愿意万佛洞，在​​此，我欢迎，以及：

I'm in the middle of working on this though, so my tune may change at any point. Here's what I have though. Anyone willing to poke holes in this, i welcome that as well:

1. 用户认证，用户名和密码通过HTTPS

1. User authenticates, username and password over https

服务器（在我的案件的Node.js + EX preSS）发回一个临时普遍的私有密钥身份验证的用户。该键是用户将使用什么登入HMACs客户端和存储在localStorage的浏览器上，而不是一个cookie（因为我们不希望它来回于每个请求做）。

Server (in my case node.js+express) sends back a temporary universal private key to authenticated users. This key is what the user will use to sign HMACs client side and is stored in LocalStorage on the browser, not a cookie (since we don't want it going back and forth on each request).

• 的密钥被存储在的NodeJS存储器和再生每六小时，保持所产生的最后一个键记录。对于变化的关键10秒后，服务器实际上产生两个HMACs;一个具有新的密钥，一个使用旧钥匙。而关键的改变是由这样的要求仍然有效。如果密钥改变，服务器发送新一回客户端，以便它可以在localStorage的闪光吧。最关键的是与节点UUID生成的UUID与加密散列的SHA256。并输入了这一点后，我意识到这可能无法很好地扩展，但无论如何...
  
  

键，然后存储在localStorage的浏览器（应用程序实际上吐出你的浏览器 - 是太旧如果不支持的localStorage之前，你甚至可以尝试登录页）。

The key is then stored in LocalStorage on the browser (the app actually spits out a your-browser-is-too-old page if LocalStorage is not supported before you can even try to login).

然后超出了最初的认证的所有要求送三自定义页眉：

Then all requests beyond the initial authentication send three custom headers:

• 验证签名：用户名 + 时间 + request.body （在我的情况 request.body 是 JSON.stringify（ ）倒是重新瓦尔请求presentation）与本地存储的密钥签署


• 验证，用户名：在用户名


• X-microtime中：当客户端生成的HMAC
  
  
的Unix时间戳

• 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
  
  

然后服务器会检查 X-microtime中头，如果 X-microtime中之间的差距和现在大于10秒，下降的要求作为一个潜在的重放攻击和投掷回401。

The server then checks the X-Microtime header, and if the gap between X-Microtime and now is greater than 10 seconds, drop the request as a potential replay attack and throw back a 401.

然后服务器产生是自己的HMAC使用相同的序列作为客户端，验证，用户名 + X-microtime中 + req.body 使用节点存储6小时的私人密钥。

Then the server generates is own HMAC using the same sequence as the client, Auth-Username+X-Microtime+req.body using the 6-hour private key in node memory.

如果HMACs是相同的，信任的要求，如果没有，401，我们有验证，用户名头，如果我们需要处理的任何具体的用户在API。

If HMACs are identical, trust the request, if not, 401. And we have the Auth-Username header if we need to deal with anything user specific on the API.

所有这些沟通的目的显然是通过HTTPS发生。

All of this communication is intended to happen over HTTPS obviously.

的关键将具有每个成功的请求，以保持在客户端最新的动态键之后被返回到客户端。这是问题，因为它确实是一个cookie基本上做同样的事情。

The key would have to be returned to the client after each successful request to keep the client up to date with the dynamic key. This is problematic since it does the same thing that a cookie does basically.

您可以使静态的关键，永不改变，但似乎不太安全，因为密钥永远不会过期。你也可以指定每个用户的关键，这被返回到在登录客户端，但你还是必须做对每个请求用户查找无论如何，还不如只使用基本身份验证在这一点上。

You could make the key static and never changing, but that seems less secure because the key would never expire. You could also assign a key per user, that gets returned to the client on login, but then you still have to do user lookups on each request anyway, might as well just use basic auth at that point.

所以，做一些我自己的测试之后，我决定去与后端代理仍然使用HMAC我的REST API。

So, after doing some testing of my own, i've decided to go with a backend proxy to my REST API still using HMAC.

1. 角所连接到同一个域的后端，后端运行从上面的HMAC过程中，存储在这个代理私钥。有了这对同一个域中使我们能够阻止CORS。

1. Angular connects to same-domain backend, the backend runs the HMAC procedure from above, private key stored on this proxy. Having this on same domain allows us to block cors.

在成功的权威性，棱角分明只是得到一个标志，并且我们存储登录状态的localStorage。无标识用户，并是确定键，但东西公开。对我来说，这种储值的presence才是决定用户是否登录。我们当他们注销或删除localStorage的我们决定无效的会话。

On successful auth, angular just gets a flag, and we store logged in state in LocalStorage. No keys, but something that identifies the user and is ok to be made public. For me, the presence of this stored value is what determines if the user is logged in. We remove the localStorage when they logout or we decide to invalidate their "session".

从角度到同一个域代理的后续调用包含用户头。用户头代理检查（这只能由我们来设置，因为我们已经阻止跨网站访问），返回401如果没有设置，否则只是通过对API请求转发，但HMAC'd像上面。 API传递响应返回给代理，从而回到棱角分明。

Subsequent calls from angular to same domain proxy contain user header. The proxy checks for user header (which can only be set by us because we've blocked cross-site access), returns 401 if not set, otherwise just forwards the request through to the API, but HMAC'd like above. API passes response back to proxy and thus back to angular.

这使我们能够保密的比特出了前端，同时还使我们能够建立一个可以快速验证没有DB在每次请求调用API，并保持国家少。这也让我们的API服务就像一个原生移动应用等接口。移动应用也只是用私钥捆绑并运行它们的每个请求的HMAC序列。

This allows us to keep private bits out of the front end, while still allowing us to build an API that can authenticate quickly without DB calls on every request, and remain state-less. It also allows our API to serve other interfaces like a native mobile app. Mobile apps would just be bundled with the private key and run the HMAC sequence for each of their requests.

这篇关于AngularJS SPA和RestfulAPI服务器安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！