CSRF

CSRF,即 Cross Site Request Forgery,中译是跨站请求伪造,是一种劫持受信任用户向服务器发送非预期请求的攻击方式。
举个例子:
小明在刷gmail,突然看到一条链接,好奇点开了发现是个空白链接,就不管他,继续刷其他的。看似没有什么事情发生,但实际上攻击者利用这个所谓的空白页给小明偷偷设置了一个过滤规则,这个规则使他收到的邮件都转发给了攻击者。
1、攻击特点

攻击一般发起在第三方网站,而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证,冒充受害者提交操作;而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证,仅仅是“冒用”。
跨站请求可以用各种方式:图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中,难以进行追踪。

2、攻击流程

受害者登录a.com,并保留了登录凭证(Cookie)。
攻击者引诱受害者访问了b.com。
b.com 向 a.com 发送了一个请求:a.com/act=xx。浏览器会默认携带a.com的Cookie。
a.com接收到请求后,对请求进行验证,并确认是受害者的凭证,误以为是受害者自己发送的请求。
a.com以受害者的名义执行了act=xx。
攻击完成,攻击者在受害者不知情的情况下,冒充受害者,让a.com执行了自己定义的操作。

3、防范措施
CSRF通常从第三方网站发起,被攻击的网站无法防止攻击发生,只能通过增强自己网站针对CSRF的防护能力来提升安全性。
方法一:同源验证
既然CSRF大多来自第三方网站,那么我们就直接禁止外域(或者不受信任的域名)对我们发起请求。
判断是否来自外域:
在HTTP协议中,每一个异步请求都会携带两个Header,用于标记来源域名:

Origin Header
Referer Header

这两个Header在浏览器发起请求时,大多数情况会自动带上,并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名,确定请求的来源域。
注意:
Origin 在 IE11 中不存在,在 302 重定向中也不存在,Referrer 可以被前端隐藏不携带,如果不存在这两个请求头时,需要利用其它方式验证:
当访问源是外域时,直接拒绝访问,但要注意的是,需要过滤掉 html 页面请求,因为当请求来自搜索引擎结果页面时,也是外域访问,会被当做 CSRF 请求。
方法二、CSRF Token 验证
1、服务器生成一个Token,并把这个Token利用算法加密。要注意,这个Token不能放在Cookie中,要不然又会被冒用,一般是放在session中。
2、在页面加载时,在每个a标签和form标签中放入Token
3、服务器验证Token是否正确
缺点:实现较为复杂,工作量大,可能出现遗漏。
方法三、双重Cookie验证
利用CSRF攻击不能获取到用户Cookie的特点,我们可以要求Ajax和表单请求携带一个Cookie中的值。
1、在用户访问网站页面时,向请求域名注入一个Cookie,内容为随机字符串。
2、在前端向后端发起请求时,取出Cookie,并添加到URL的参数中。
3、后端接口验证Cookie中的字段与URL参数中的字段是否一致,不一致则拒绝。
优点:
无需使用Session,适用面更广,易于实施。
Token储存于客户端中,不会给服务器带来压力。
相对于Token,实施成本更低,可以在前后端统一拦截校验,而不需要一个个接口和页面添加。
缺点:
Cookie中增加了额外的字段。
如果有其他漏洞(例如XSS),攻击者可以注入Cookie,那么该防御方式失效。
难以做到子域名的隔离。
为了确保Cookie传输安全,采用这种防御方式的最好确保用整站HTTPS的方式,如果还没切HTTPS的使用这种方式也会有风险。
方法四、Samesite Cookie属性
Google起草了一份草案来改进HTTP协议,那就是为Set-Cookie响应头新增Samesite属性,它用来标明这个 Cookie是个“同站 Cookie”,同站Cookie只能作为第一方Cookie,不能作为第三方Cookie,Samesite 有两个属性值,分别是 Strict 和 Lax:
Set-Cookie: foo=1; Samesite=Strict
Set-Cookie: bar=2; Samesite=Lax
复制代码Samesite=Strict:严格模式
这个Cookie无论什么情况下都不能作为第三方的Cookie。
Samesite=lax:宽松模式
如果这个请求改变了当前页面或者打开新页面,且携带GET请求,则这个Cookie可作为第三方Cookie。
缺点:
1、Samesite 不支持子域,也就是说子域无法使用设置了 Samesite 的 cookie,这可能导致用户在主域登录后,前往子域页面仍需要重新登录
2、兼容性不好

### CSRF 的定义 跨站请求伪造 (Cross-Site Request Forgery, CSRF) 是一种攻击方式,它利用用户的浏览器向目标网站发送未经授权的请求。这种攻击通常发生在用户已经登录到某个站点的情况下,恶意网站通过诱导用户点击链接或加载脚本等方式,在后台提交表单或其他操作,从而执行一些未经用户同意的操作[^1]。 例如,如果用户在一个银行网站上保持登录状态,而此时又访问了一个恶意网页,则该页面可能包含一段 JavaScript 或隐藏的 HTML 表单,自动触发对银行服务器的有效请求。由于这些请求来自已验证过的会话,因此可能会被误认为合法行为并被执行。 ### 实现机制 CSRF 攻击的核心在于滥用当前用户的认证凭证来发起非法请求。以下是其基本工作流程: 1. 用户登录受信任的应用程序 A 并获得有效的会话令牌。 2. 用户随后浏览另一个不受信的网站 B。 3. 网站 B 包含一条指向应用程序 A 的 URL 链接或者嵌入了一张图片标签等资源引用地址。 4. 当用户无意间交互时(比如点击按钮),就会向应用 A 发送 GET/POST 请求。 5. 如果此请求不需要额外的身份确认步骤(如二次验证码输入),那么就有可能成功完成预期外的动作。 为了更清楚地理解这一点,下面是一个简单的例子展示如何构造这样的攻击代码片段: ```html <!-- 假设这是由攻击者创建的一个HTML文件 --> <form action="https://bank.example.com/transfer" method="POST"> <input type="hidden" name="toAccount" value="attacker_account"/> <input type="hidden" name="amount" value="1000"/> </form> <script>document.forms[0].submit();</script> ``` 当受害者打开这个页面的时候,上面这段JavaScript将会立即提交转账表格给银行系统。 ### 防御措施 针对 CSRF 的有效防范策略可以从多个角度入手: #### 同步Token模式(Synchronizer Token Pattern) 最常见也是推荐的方法之一就是在每次HTTP POST请求之前生成随机数作为唯一标识符(token),并将之附加于表单项之中传递至客户端;之后再随响应一起返回给服务端用于校验真实性。只有当两个token匹配一致时才允许继续处理业务逻辑[^4]。 示例实现如下所示: ```python import secrets def generate_csrf_token(): return secrets.token_hex(16) @app.route('/some_form', methods=['GET']) def show_some_form(): csrf_token = generate_csrf_token() session['csrf_token'] = csrf_token return render_template('form.html', csrf_token=csrf_token) @app.route('/process_data', methods=['POST']) def process_data(): user_supplied_token = request.form.get('csrf_token') expected_token = session.pop('csrf_token', None) if not compare_secure_strings(user_supplied_token, expected_token): abort(403) # Invalid token # Proceed with processing data... ``` 这里需要注意的是存储在session中的实际值应该具有一定的有效期,并且最好采用HTTPS协议传输数据以保护敏感信息免遭窃听风险。 #### 双重Cookie验证(Double Submit Cookie) 另一种可行的技术叫做双重递交Cookies(DSC), 它的工作原理是在设置好HttpOnly属性后的常规Session ID之外单独设立一个新的非HttpOnly类型的Anti-CSRF-Cookie ,然后要求前端开发者把它的内容复制粘贴进每一个Ajax调用或者其他任何形式的数据提交动作里去当作参数携带过去让后端做对比分析即可[^1]. 这种方法的优点是可以减少对于修改现有架构的需求量级,缺点则是增加了少量额外开销以及潜在的安全隐患——因为cookies本身也存在被盗取的可能性所以必须谨慎对待整个生命周期管理过程. 另外还可以考虑启用现代浏览器自带的一些特性支持像SameSite Cookies选项,默认情况下限制第三方上下文中无法正常读写特定标记下的项目从而间接达到抵御此类威胁的效果[^2]. 最后提醒一点就是无论采取哪种具体手段都应当结合实际情况综合评估成本效益后再决定最终实施方案!
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值