我正在为一组网站设计API.这些站点非常相似(有点像StackOverflow,SuperUser和ServerFault),它们有一个共享的后端是有意义的.因此,我们决定尝试使用一个漂亮的REST API作为后端,以及一堆非常相似但不同的前端消耗所述API.前端应该最好都是静态的,但如果结果是不可能的话,这并不是一个很难的要求.
我现在正在设计该API,我担心安全问题,特别是CSRF.根据我对CSRF攻击的基本了解,它们包含两个重要组成部分:
能够命名资源和请求正文.
欺骗用户/浏览器使用环境身份验证(如会话)向看起来经过身份验证的资源发出请求.
许多修复CSRF攻击的经典方法都是基于会话.由于我的REST API并不真正进行会话,这既可以防止很多向量,也可以防止所有修复它们的方法.例如,双重提交没有意义,因为没有什么可以双重提交.
我最初的方法涉及攻击CSRF攻击的第2部分.如果我验证所有请求(例如使用HTTP Basic Auth),并且浏览器没有保存这些凭证(例如某些JS发出请求),只有拥有凭据的JS可以发出请求,我们就完成了.明显的缺点是应用程序需要知道用户的凭据.另一个稍微不那么明显的缺点是,如果我想在API端安全地存储凭证,那么验证密码应该花费一个固定的,非平凡的时间.如果安全地验证密码需要100毫秒,那么每个其他请求将花费至少100毫秒+ eps,并且它将需要一些非常聪明的客户端技巧来使这感觉不慢.我可能能够缓存它(因为凭证将始终是相同的),如果我非常小心,我可能设法做到这一点,而不会引入时间漏洞,但这听起来像一个大黄蜂的巢.
OAuth 2.0似乎有点过头了,但我想它毕竟可能是最好的解决方案,以免我最终执行得不好.我想我现在可以做HTTP Basic Auth的事情,当我们有第三方应用程序开发人员时,我会转到OAuth.
与OAuth有一点阻抗不匹配.OAuth真的想帮助应用程序访问另一个应用程序上的东西,基本上.我希望用户在这样的帐户存在之前注册其中一个前端.
我还考虑通过使URL随机化来攻击点1 - 即将标记添加到查询字符串中.这肯定会起作用,并且它非常接近于表单中传统的随机令牌如何工作,并且鉴于HATEOAS它甚至应该相当RESTful,尽管这提出了两个问题:1)你从哪里开始？是否存在使用HTTP Basic Auth登录的强制API起点？2)如果他们无法预先预测URL,那么它会让应用程序开发人员满意多少,HATEOAS会被诅咒？
我已经看到如何在RESTful应用程序中阻止CSRF？,但我不同意随机URI必然是不可靠的前提.此外,这个问题并没有真正令人满意的答案,也没有提到OAuth.此外,会话双提交解决方案无效,正如我上面提到的(静态前端的不同域比API端点).
我意识到我从根本上试图在这里做的是尝试允许来自一个域的跨站点请求而不允许它们从另一个域中进行,这并不容易.当然必须有一些合理的解决方案吗？
众所周知，Rest 服务是无状态的，一般的身份验证策略是使用基于令牌的身份验证。
在登录服务中，它需要返回令牌的凭据。
此令牌可能会在客户端 cookie 中设置，并且所有后续请求都使用此令牌进行验证并在令牌有效的情况下处理新请求。
现在我的问题是如何验证令牌？如果有人窃取了令牌并试图通过编辑cookie来使用窃取的令牌访问休息服务，那么如何识别和限制它呢？
我们永远无法知道令牌是否由有效用户获取并且同一用户是否正在尝试访问后续请求。但是有哪些可能的方法可以使其变得更加困难，例如验证请求是否来自同一来源？
一个一般建议是设置令牌/cookie 的老化时间，但直到该令牌/cookie 的老化时间为止它仍然没有帮助。
任何建议，将不胜感激。