Rails安全性与API标头中的授权令牌有关

时间:2014-06-16 19:03:58

标签: ruby-on-rails security authorization

我正在构建一个API,我希望每个请求都包含一个令牌。我发现了一种非常简单的方法,但我想知道我是否遗漏了任何安全隐患。

我目前的做法是使用authenticate_or_request_with_http_token。我使用它来检查标题中的标记以及请求中用户的电子邮件。如果两者都是合法的 - 那么请完成请求。

我还对每个请求强制执行https。这对于安全的应用程序来说足够了吗如果某人拦截了请求,他们可以直接使用参数和标题并代表用户发出请求,但我认为ssl应该正确编码所有内容。我是否完全误解了ssl以及我构建它的其余方式?

1 个答案:

答案 0 :(得分:2)

我认为你基本上是正确的。

但最安全的API身份验证方式是使用hmac,其中令牌实际上是针对特定请求和时间生成的,所以即使有人看到了URL,他们仍然无法使用它重播相同的API请求,更不用说发出其他请求了。

http://rc3.org/2011/12/02/using-hmac-to-authenticate-web-service-requests/

例如,亚马逊使用基于HMAC的API方法。

但我认为您的分析是正确的,通常情况下,如果您强制执行https,则应该无法在请求中看到通过令牌客户端包含的内容。我无法解释为什么人们使用HMAC代替;也许只是因为有太多的东西可能会出错并导致有人在请求标题中看到令牌。包括几种不可能发生的中间人攻击,但如果在其他地方发生滑倒使得一种可能,那么基于HMAC的方法仍然会阻止一个人在这里在客户端到达服务器之前修改客户端要发送的请求。

ruby​​ stdlib中内置了HMAC。 stdlib中的摘要:: HMAC告诉你使用OpenSSL :: HMAC,但OpenSSL :: HMAC根本不包含任何文档,而Digest :: HMAC至少包含一些简单的示例文档。拥有更好的文档会很好,但是与上面链接的HMAC概述一起,你可以很容易地弄清楚如何使用stdlib ruby​​ hmac来实现你的auth。但是,它确实给客户带来了更大的负担,用他们选择的语言找到一个HMAC库,并根据你的应用程序的规范实现hmac auth(在如何将hmac合并到实际的auth流程中有几种选择)。

相关问题