csrf攻击防范的核心在于验证请求来源合法性。解决方案包括：1.referer头检查，通过nginx配置限制请求来源，但存在被伪造风险；2.origin头检查，相比referer更可靠，但浏览器兼容性需注意；3.双重提交cookie，前端生成token并同时置于cookie和请求参数中，nginx初步验证，安全性更高但实现复杂；4.自定义请求头验证，适用于api接口，避免跨域问题。选择方案时应权衡安全性和实现成本，结合多种方法提升防护效果。此外，nginx层防护不能替代后端验证，仍需后端进一步确认token有效性。其他手段如同步令牌模式、samesite cookie及用户行为验证也应纳入整体防御策略。
CSRF攻击防范的核心在于验证请求的来源是否合法。在Nginx层进行防护，可以有效拦截恶意请求，减轻后端服务器的压力。
解决方案：
-
Referer Header 检查: Nginx可以配置检查
Referer请求头。如果Referer头不存在或不在白名单内，则拒绝请求。 这种方法简单直接，但Referer头可以被篡改，因此并非万无一失。server { listen 80; server_name example.com; location / { if ($http_referer !~ "^https?://(www\.)?example\.com") { return 403; } proxy_pass http://backend; } } -
Origin Header 检查:
Origin头比Referer头更可靠，因为它不能被浏览器在跨域请求中修改。 Nginx可以配置检查Origin头，并只允许来自特定域的请求。 但要注意，Origin头并非所有浏览器都支持。server { listen 80; server_name example.com; location / { if ($http_origin !~ "^https?://(www\.)?example\.com") { return 403; } proxy_pass http://backend; } } -
双重提交 Cookie (Double Submit Cookie): 这种方法需要在前端生成一个随机的token，将其同时存储在cookie中和一个请求参数中。 Nginx可以配置验证这两个token是否一致。 虽然增加了复杂度，但安全性更高。
-
前端生成token并设置cookie: (假设使用JavaScript)
function setCookie(name,value,days) { var expires = ""; if (days) { var date = new Date(); date.setTime(date.getTime() + (days*24*60*60*1000)); expires = "; expires=" + date.toUTCString(); } document.cookie = name + "=" + (value || "") + expires + "; path=/"; } function generateToken() { // 简单示例，实际应用中应使用更安全的随机数生成方法 return Math.random().toString(36).substring(2); } const csrfToken = generateToken(); setCookie('csrf_token', csrfToken, 7); // 设置cookie有效期为7天 // 将csrfToken添加到表单或AJAX请求参数中 // 例如： -
Nginx配置: (这里假设后端服务会验证这个token，Nginx只做初步的检查)
server { listen 80; server_name example.com; location / { # 检查是否存在cookie和请求参数中的csrf_token if ($http_cookie !~* "csrf_token=([^;]+)") { return 403; } if ($request_method = POST) { if ($arg_csrf_token = "") { return 403; } # 这里无法直接比较cookie和参数的值，只能简单判断存在性 # 实际的token验证需要在后端进行 } proxy_pass http://backend; } }
-
-
自定义请求头验证： 类似于双重提交Cookie，但将Token放在自定义的请求头中。 这种方式避免了Cookie的跨域问题，更适用于API接口。
-
前端设置自定义请求头：
// 假设已经通过某种方式获取了CSRF token (例如从cookie中读取) const csrfToken = getCookie('csrf_token'); // 需要自己实现getCookie函数 fetch('/api/resource', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-CSRF-Token': csrfToken // 自定义请求头 }, body: JSON.stringify({ data: 'your data' }) }) .then(response => response.json()) .then(data => console.log(data)); -
Nginx配置：
server { listen 80; server_name example.com; location /api/ { if ($http_x_csrf_token = "") { return 403; } proxy_pass http://backend; } }
-
如何选择合适的CSRF防护方案？
选择哪种方案取决于你的应用场景和安全需求。 Referer和Origin检查简单易用，但安全性较低。 双重提交Cookie和自定义请求头验证安全性更高，但实现起来更复杂。 可以根据实际情况选择组合使用多种方案。 关键在于理解每种方案的优缺点，并根据自身情况进行权衡。
Nginx层防护CSRF的局限性是什么？
Nginx层主要负责请求的初步过滤，它无法完全替代后端服务器的CSRF防护。 例如，Nginx无法验证双重提交Cookie中的token是否与用户的session关联。 因此，即使在Nginx层进行了防护，后端服务器仍然需要进行更严格的验证。 Nginx主要起一个前置过滤的作用，减轻后端压力，提高整体安全性。
除了Nginx，还有哪些CSRF防护手段？
除了Nginx层防护，还有以下CSRF防护手段：
- 同步令牌模式 (Synchronizer Token Pattern, STP): 这是最常见的CSRF防护方法。 服务器为每个用户的会话生成一个唯一的CSRF令牌，并将该令牌嵌入到HTML表单中。 当用户提交表单时，服务器会验证表单中的CSRF令牌是否与会话中存储的令牌匹配。
-
SameSite Cookie:
SameSite属性可以控制Cookie是否随跨站请求发送。 设置SameSite=Strict可以完全阻止Cookie在跨站请求中发送，从而有效防止CSRF攻击。 但要注意，SameSite=Strict可能会影响某些正常的跨站请求，需要谨慎使用。SameSite=Lax则允许部分跨站请求（例如GET请求）携带Cookie。 - 用户行为验证： 例如，要求用户在执行敏感操作前输入密码或进行验证码验证。
这些方法通常需要在后端代码中实现。 结合Nginx层的防护，可以构建更强大的CSRF防御体系。
