校验Referer头,防范CSRF(跨站请求伪造)攻击的拦截器

本文介绍了一个用于管理员操作的CSRF防御拦截器实现,通过校验Referer头来防范跨站请求伪造攻击。
部署运行你感兴趣的模型镜像

 

 

	public final static	String domainName = "192.168.2.123";

 

 

package com.web.interceptors;

import org.apache.log4j.Logger;
import org.apache.struts2.ServletActionContext;

import com.opensymphony.xwork2.ActionInvocation;
import com.opensymphony.xwork2.interceptor.AbstractInterceptor;
import com.trace.web.utils.Constants;

/**
 * 对管理员操作,校验Referer头,防范CSRF(跨站请求伪造)攻击的拦截器
 * @author admin
 */
public class AuthInterceptor extends AbstractInterceptor {

	private static final long serialVersionUID = -2154056039548254482L;
	
	private static Logger log = Logger.getLogger(AuthInterceptor.class);

	@Override
	public String intercept(ActionInvocation invocation) throws Exception {
		String referer = ServletActionContext.getRequest().getHeader("Referer");
		if((referer!=null) && (referer.trim().startsWith(Constants.HTTP + Constants.domainName))){
			return invocation.invoke();
		}
		log.info("referer : " + referer);
		return "error";
	}

}

 

 

 

 

 

 

 

 

 

 

 

 

 

捐助开发者

在兴趣的驱动下,写一个免费的东西,有欣喜,也还有汗水,希望你喜欢我的作品,同时也能支持一下。 当然,有钱捧个钱场(右上角的爱心标志,支持支付宝和PayPal捐助),没钱捧个人场,谢谢各位。



 
 
 谢谢您的赞助,我会做的更好!

 

 

 

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型,相比 3.0 版本,它提升了图像质量、运行速度和硬件效率

<think>首先,用户的问题是:“我想查找解决系统未校验Referer请求导致CSRF漏洞风险的方法”。这个问题的核心是解决CSRF漏洞风险,特别是由于系统没有校验Referer请求而导致的。 用户提供了两个站内引用: - 引用[1]:解释了Referer验证如何防御CSRF攻击。它描述了Referer字段的作用、验证方法、优缺点。 - 引用[2]:定义了CSRF漏洞,强调了它XSS的区别。 我的回答需要: - 使用中文回答。 - 遵循系统级指令:行内数学表达式用$...$,独立公式用$$...$$(但在这个问题中可能不涉及数学公式,所以我可以忽略)。 - LaTeX语法正确(同样,可能不适用)。 - 回答结构清晰,逐步解决问题。 - 末尾自然地添加引用标识。 - 生成相关问题。 从参考引用中,我提取关键信息: - Referer验证:检查HTTP请求Referer,确保它来自可信域名。 - 缺点:Referer可能被篡改,有些浏览器可能不发送Referer。 - 引用中提到“实际应用中通常采用第二种方法来防御CSRF攻击”,但引用中只提到了Referer验证,没有指定第二种方法是什么。我需要回想常见的CSRF防御方法。 标准CSRF防御方法包括: 1. **Referer检查**:验证Referer是否来自可信域名。 2. **Anti-CSRF Tokens**(CSRF令牌):最常用的方法。服务器生成一个唯一的、不可预测的令牌,嵌入在表单或请求中;用户提交时,服务器验证令牌是否匹配。 3. **SameSite Cookie属性**:设置cookie的SameSite属性为Strict或Lax,限制跨站请求。 4. **其他方法**:如双重提交cookie、使用自定义等。 回答结构: 1. **介绍问题**:解释什么是CSRF风险和Referer验证的意义。 2. **解决方法**:提供多种解决未校验Referer导致的CSRF风险的方法。 - 修复Referer验证:如果可行,实施Referer检查。 - 替代方法:由于Referer验证有缺点,推荐使用更可靠的方法如CSRF令牌。 3. **步骤指导**:清晰地说明如何实施这些方法。 4. **引用来源**:自然地融入引用内容。 5. **生成相关问题**:在末尾添加相关问题。 生成相关问题: - 基于CSRF主题,如Token实现、SameSite属性、测试方法等。 完整回答框架: 1. **引言**:简要解释CSRF风险和Referer验证的作用。 2. **核心解决方法**: - 方法1:实施Referer验证。 - 如何做:在服务器端添加拦截器,检查Referer。 - 优缺点:参考引用[1]。 - 方法2:使用CSRF Token。 - 描述如何实现。 - 方法3:使用SameSite Cookie属性。 - 强调推荐方法(如CSRF Token)。 3. **步骤总结**:给用户一个清晰的行动指南。 4. **结尾**:添加引用标识。 5. **相关问题**:列出几个相关问题。 确保语言自然、流畅。 </think>### 解决系统未校验Referer请求导致的CSRF漏洞风险方法 CSRF跨站请求伪造)漏洞风险源于网站对用户浏览器的信任被滥用,攻击者可以强制用户执行非预期的操作(如转账或数据修改)[^2]。当系统未校验Referer请求时,攻击者更容易伪造请求,因为Referer字段能标识请求的来源域名(如合法应为`xxx.com`)[^1]。针对此风险,以下是几种有效的解决方法。我将逐步解释每种方法,包括实施步骤、优缺点,并优先推荐更可靠的技术。 #### 1. **实施Referer验证(直接修复方案)** 这是最直接的修复方式,通过在服务器端校验Referer来确保请求来自可信域名。 - **实施步骤**: - 在网站后台(如Web应用服务器)添加一个拦截器或中间件。 - 对每个敏感请求(如转账或数据修改操作)检查HTTP中的Referer值。 - 验证Referer是否以可信域名开(例如`https://xxx.com`),否则拒绝请求。 - 示例代码(以Python Flask框架为例): ```python from flask import request @app.before_request def check_referer(): trusted_domain = "https://xxx.com" sensitive_paths = ["/transfer", "/update_profile"] # 定义敏感端点 if request.path in sensitive_paths: referer = request.headers.get('Referer', '') if not referer.startswith(trusted_domain): return "Invalid request: Referer verification failed.", 403 ``` - **优点**: - 简单易行,只需后台代码修改,无需前端变更。 - 适用于大部分场景,能有效拦截外部站点发起的攻击[^1]。 - **缺点**: - Referer可能被篡改(低级浏览器漏洞)或被用户禁用(高级浏览器隐私设置),导致合法请求被误拒[^1]。 - 可靠性较低,不建议作为唯一防御机制。 此方法可作为初步修复,但需结合其他方案增强安全性。 #### 2. **使用Anti-CSRF Token(推荐方法)** 实际应用中,Referer验证的缺陷使其不完美,因此业界更推荐使用Anti-CSRF Token(CSRF令牌)作为核心防御。该方法在请求中嵌入一个唯一的、不可预测的令牌,服务器验证其有效性。 - **实施步骤**: - **生成令牌**:用户登录时,服务器生成一个令牌(如随机字符串),存储在用户会话中。 - **嵌入令牌**:将令牌嵌入表单或请求(如作为隐藏字段`<input type="hidden" name="csrf_token" value="随机值">`)。 - **验证令牌**:用户提交请求时,服务器比较请求中的令牌会话存储的值是否匹配。 - **示例流程**: 1. 用户访问页面时,服务器返回表单:`<form action="/transfer" method="POST"><input type="hidden" name="csrf_token" value="abcd1234"></form>`。 2. 用户提交表单后,服务器验证`csrf_token === session.get('csrf_token')`。 - 代码片段(Node.js Express示例): ```javascript const express = require('express'); const csrf = require('csurf'); const app = express(); app.use(csrf()); // 启用CSRF中间件 app.get('/form', (req, res) => { res.render('form', { csrfToken: req.csrfToken() }); // 传递令牌到前端 }); app.post('/transfer', (req, res) => { // 自动验证令牌,失败则拒绝 if (!req.csrfTokenValid) { return res.status(403).send("CSRF Token验证失败"); } // 处理合法请求 }); ``` - **优点**: - 高度可靠:令牌由服务器控制,攻击者无法预测或篡改。 - 兼容性强:不受浏览器Referer设置影响。 - 行业标准:被OWASP(开放Web应用安全项目)推荐为首选防御机制。 - **缺点**: - 需要前后端协同修改,实施稍复杂。 - 对API请求需额外处理(如使用自定义)。 #### 3. **结合SameSite Cookie属性(增强防御)** 作为补充方案,设置Cookie的SameSite属性可以限制跨站请求,减少CSRF风险。 - **实施步骤**: - 在设置会话Cookie时,添加`SameSite`属性为`Strict`或`Lax`。 - `Strict`:完全禁止跨站请求携带Cookie。 - `Lax`:允许安全方法(如GET)的跨站请求,但阻止POST等危险方法。 - 示例Cookie设置(HTTP响应): ``` Set-Cookie: session_id=123; Secure; HttpOnly; SameSite=Lax ``` - 适用于所有现代浏览器(Chrome、Firefox等)。 - **优点**: - 简单高效:一行代码即可强化防御。 - Referer验证或CSRF Token互补,提升整体安全性。 - **缺点**: - 单独使用不充分:攻击者可能绕过(如旧版浏览器支持不足)。 - 需确保Cookie标记为`Secure`和`HttpOnly`以防止XSS泄露。 #### 实施建议总结 - **优先采用CSRF Token**:这是最可靠的防御方法,尤其适合新系统或高风险场景。 - **组合使用**:针对未校验Referer的漏洞,建议: 1. 新增CSRF Token作为核心防御。 2. 添加SameSite Cookie属性(设置为Lax)。 3. 可选:实施Referer验证作为辅助层(例如用于日志监控)。 - **测试验证**:部署后,使用工具(如OWASP ZAP或Burp Suite)扫描CSRF漏洞,确保修复有效。 通过上述方法,您能有效解决因未校验Referer导致的CSRF风险,大幅提升系统安全性[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值