仅使用nginx进行简单的CSRF保护

时间:2013-12-29 14:33:52

标签: security architecture xss csrf csrf-protection

我有一个提供普通HTML和JS文件的nginx服务器。

然后,js代码从API服务器调用各种REST API到GET / POST数据。

如果nginx收到/ api / location请求,它会将请求转发给另一个处理所有API的服务器。这个api服务器是用Ruby on Rails构建的。

由于我的所有纯HTML页面都是由nginx直接提供的,所以在渲染时我无法进行服务器端会话。

如何防止CSRF攻击?

3 个答案:

答案 0 :(得分:5)

CSRF令牌的要点是要求攻击者从您的域中读取值以发送请求。

因此,您可以在API中拥有一个单独的端点,它只返回一个CSRF表单令牌。

由于同源策略(由于他们无法从HTML源读取令牌的相同原因),攻击者将无法读取令牌,因此您将是安全的。
这样做的缺点是需要额外的HTTP请求。

此外,请确保响应无效Javascript,或者攻击者可以将其作为<script>标记运行并使用原型&amp;属性技巧读取值

答案 1 :(得分:2)

由于您无法进行服务器端会话,因此您需要一种不需要将令牌存储在服务器上的解决方案。相反,您需要做的是让您的nginx实现生成某种令牌,您将在浏览器的响应中包含该令牌。当攻击者代表另一个用户发送请求时(即应用程序生成的页面上隐藏的输入字段或元标记),此值应出现在请求中未自动包含的位置,并且还应存储在一个cookie(显然会在CSRF攻击中自动发送)。当您的应用程序收到请求时,它可以验证这两个值是否相同。如果是这样,您可以将请求转发给API。如果没有,您知道该请求不是来自您的网站,您可以拒绝。

至少有两种方法可以做到这一点:

○: csrf_cookie:abc123(cookie) csrf_param:abc123(参数或标题)

更好: session _ + _ csrf_cookie:sessionid_val _-- abc123 csrf_param:abc123(参数或标题)

第二种解决方案优于第一种解决方案的原因是第一种解决方案容易受到cookie强制攻击。第二个是安全的,因为如果MITM与你的会话cookie混淆,它将使会话无效。使用第二种解决方案,您可以在代理API之前简单地剥离令牌。

当然,所有这些都假设您使用的是HTTPS。

答案 2 :(得分:1)

安装WAF(Web应用程序防火墙)以检查HTTP / HTTPS流量,拒绝恶意请求,并且通常充当Web堆栈中的附加安全层。正确配置的WAF可以保护您的站点免受SQLi,XSS,CSRF和DDoS攻击,并提供强力攻击缓解和零日威胁修补。 nginx有一些开源WAF选项。见https://help.dreamhost.com/hc/en-us/articles/222784068-The-most-important-steps-to-take-to-make-an-nginx-server-more-secure

还有一个简单的nginx模块,它将引用者或原始头与主机头进行比较。如果域名不匹配,则返回HTTP响应403。 见https://github.com/gartnera/nginx_csrf_prevent