CSRF防御之token认证

article/2025/9/24 7:01:07

一、CSRF是什么？

CSRF（Cross-site request forgery），中文名称：跨站请求伪造。攻击者盗用你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账…造成的问题包括：个人隐私泄露以及财产安全。

二、CSRF攻击原理

在这里插入图片描述

三、几种常见的攻击类型

1. GET类型的CSRF

针对get请求，黑客一般会给你发送一张图片，在图片的src里执行请求。

	<!-- GET类型csrf攻击 --><img src="http://127.0.0.1:10086/payfor?money=100&to=张三" alt="">

2. POST类型的CSRF

针对post请求，黑客一般会伪造一个表单，在表单提交的时候发送请求。

	<!-- POST类型csrf攻击 --><form action="http://127.0.0.1:10086/payfor" method="POST" target="_self"><input type="hidden" name="money" value="10000" /><input type="hidden" name="to" value="hacker" /></form><script> document.forms[0].submit(); </script>

3. 链接类型的CSRF

链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：

 <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">重磅消息！！<a/>

四、CSFR的特点:

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

四、防御CSRF的策略：

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。

上文中讲了CSRF的两个特点：

  1. CSRF（通常）发生在第三方域名。
  2. CSRF攻击者不能获取到Cookie等信息，只是使用。

针对这两点，我们可以专门制定防护策略，如下：

  • 阻止不明外域的访问
    • 同源检测
    • Samesite Cookie
  • 提交时要求 附加 本域才能获取的信息
    • CSRF Token
    • 双重Cookie验证

以下我们对各种防护方法做详细说明。

同源检测:

既然CSRF大多来自第三方网站，那么我们就直接禁止外域（或者不受信任的域名）对我们发起请求。

那么问题来了，我们如何判断请求是否来自外域呢？

在HTTP协议中，每一个异步请求都会携带两个Header，用于标记来源域名：

  • Origin Header
  • Referer Header

这两个Header在浏览器发起请求时，大多数情况会自动带上，并且不能由前端自定义内容。 服务器可以通过解析这两个Header中的域名，确定请求的来源域。

1. 使用Origin Header确定来源域名

在部分与CSRF有关的请求中，请求的Header中会携带Origin字段。字段内包含请求的域名（不包含path及query）。

如果Origin存在，那么直接使用Origin中的字段确认来源域名就可以。

但是Origin在以下两种情况下并不存在：

  • IE11同源策略： IE 11 不会在跨站CORS请求上添加Origin标头，Referer头将仍然是唯一的标识。最根本原因是因为IE 11对同源的定义和其他浏览器有不同，有两个主要的区别，可以参考MDN Same-origin_policy#IE_Exceptions

  • 302重定向： 在302重定向之后Origin不包含在重定向的请求中，因为Origin可能会被认为是其他来源的敏感信息。对于302重定向的情况来说都是定向到新的服务器上的URL，因此浏览器不想将Origin泄漏到新的服务器上。

2. 使用Referer Header确定来源域名

根据HTTP协议，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。 对于Ajax请求，图片和script等资源请求，Referer为发起请求的页面地址。对于页面跳转，Referer为打开页面历史记录的前一个页面地址。因此我们使用Referer中链接的Origin部分可以得知请求的来源域名。
注意：是否携带referer还需要看是哪种referer policy。参考Referrer Policy 介绍

这种方法并非万无一失，Referer的值是由浏览器提供的，虽然HTTP协议上有明确的要求，但是每个浏览器对于Referer的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不是很安全。在部分情况下，攻击者可以隐藏，甚至修改自己请求的Referer。

另外，前面说过，CSRF大多数情况下来自第三方域名，但并不能排除本域发起。如果攻击者有权限在本域发布评论（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源策略无法达到防护的作用。

综上所述：同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。

CSRF Token

前面讲到CSRF的另一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。

而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。

原理:
CSRF Token的防护策略分为三个步骤：

  1. 将CSRF Token输出到页面中

    首先，用户打开页面的时候，服务器需要给这个用户生成一个Token，该Token通过加密算法对数据进行加密，一般Token都包括随机字符串和时间戳的组合，显然在提交时Token不能再放在Cookie中了，否则又会被攻击者冒用。因此，为了安全起见Token最好还是存在服务器的Session中，之后在每次页面加载时，使用JS遍历整个DOM树，对于DOM中所有的a和form标签后加入Token。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的HTML代码，这种方法就没有作用，还需要程序员在编码时手动添加Token。

  2. 页面提交的请求携带这个Token

    对于GET请求，Token将附在请求地址之后，这样URL 就变成 http://url?csrftoken=tokenvalue。 而对于 POST 请求来说，要在 form 的最后加上：

  <input type=”hidden” name=”csrftoken” value=”tokenvalue”/>

这样，就把Token以参数的形式加入请求了。

  1. 服务器验证Token是否正确
    当用户从客户端得到了Token，再次提交给服务器的时候，服务器需要判断Token的有效性，验证过程是先解密Token，对比加密字符串以及时间戳，如果加密字符串一致且时间未过期，那么这个Token就是有效的。
总结：

Token是一个比较有效的CSRF防护方法，只要页面没有XSS漏洞泄露Token，那么接口的CSRF攻击就无法成功。

验证码和密码其实也可以起到CSRF Token的作用哦，而且更安全。
为什么很多银行等网站会要求已经登录的用户在转账时再次输入密码，现在是不是有一定道理了？

双重Cookie验证

利用CSRF攻击不能获取到用户Cookie的特点，我们可以要求Ajax和表单请求携带一个Cookie中的值。

双重Cookie采用以下流程：

  • 在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。
  • 在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）。
  • 后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

此方法相对于CSRF Token就简单了许多，但是，此方法并没有大规模应用，其在大型网站上的安全性还是没有CSRF Token高，原因我们举例进行说明。

由于任何跨域都会导致前端无法获取Cookie中的字段（包括子域名之间），于是发生了如下情况：

  • 如果用户访问的网站为www.a.com，而后端的api域名为api.a.com。那么在www.a.com下，前端拿不到api.a.com的Cookie，也就无法完成双重Cookie认证。
  • 于是这个认证Cookie必须被种在a.com下，这样每个子域都可以访问。任何一个子域都可以修改a.com下的Cookie。某个子域名存在漏洞被XSS攻击（例如upload.a.com）。虽然这个子域下并没有什么值得窃取的信息。但攻击者修改了a.com下的Cookie。攻击者可以直接使用自己配置的Cookie，对XSS中招的用户再向www.a.com下，发起CSRF攻击。
总结：

用双重Cookie防御CSRF的优点：

  • 无需使用Session，适用面更广，易于实施。
  • Token储存于客户端中，不会给服务器带来压力。
  • 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。

缺点：

  • Cookie中增加了额外的字段。
  • 如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
  • 难以做到子域名的隔离。
  • 为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

Samesite Cookie属性

防止CSRF攻击的办法已经有上面的预防措施。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，分别是 Strict 和 Lax。参考如下：Cookie 的 SameSite 属性

参考链接：

  1. CSRF 攻击和防御 - Web 安全常识
  2. 前端安全系列（二）：如何防止CSRF攻击？
  3. Web安全之CSRF实例解析

http://chatgpt.dhexx.cn/article/buCta7vp.shtml

相关文章

禁止访问 (403)CSRF验证失败. 请求被中断.

禁止访问 (403)CSRF验证失败. 请求被中断.

出现这个问题是因为django在收到表单提交过来的信息时&#xff0c;会检查提交过来的信息中是否有token,并会对token进行校验&#xff0c;如果校验通过&#xff0c;那就继续执行&#xff0c;反之就会认定这次的数据有伪造的风险。 解决方案&#xff1a; 在项目的settings.py文…
阅读更多...
禁止访问 (403) CSRF验证失败. 请求被中断.————错误处理（测试接口时遇到的问题）

禁止访问 (403) CSRF验证失败. 请求被中断.————错误处理（测试接口时遇到的问题）

问题描述 解决措施 在Header参数中添加Content-Type和X-CSRFToken信息&#xff0c;这样就不会报错了。 运行结果
阅读更多...
通过验证Referer解决CSRF安全防御问题

通过验证Referer解决CSRF安全防御问题

一、背景 JAVAWEB 类项目处于客户验收阶段&#xff0c;在安全扫描处出现 CSRF 问题&#xff0c;通过多个博客中解决思路都无法解决。后来通过同事提醒 可以试试判断 Referer页面来源参数&#xff0c;最终使用该方法解决问题。 二、环境 服务器&#xff1a;Linux 前端&#…
阅读更多...
CSRF实战案例—绕过referer值验证

CSRF实战案例—绕过referer值验证

在一个添加管理员的界面引起了我的注意 尝试添加一个管理员&#xff0c;如下添加成功&#xff0c;我们可以观察其请求包中并未存在token字段&#xff0c;可能存在csrf漏洞。但是存在“Referer”和“Origin”字段 我们把referer字段删了只剩origin&#xff0c;查看是否可以请求成…
阅读更多...
访问django后台，提示CSRF验证失败. 请求被中断.Referer checking failed - **** does not match any trust

访问django后台，提示CSRF验证失败. 请求被中断.Referer checking failed - **** does not match any trust

1.非debug模式看到的报错 2.settings打开debug模式&#xff0c;才能把报错信息看的详细 3.去settings.py中&#xff0c;找到CsrfViewMiddleware 中间件&#xff0c;点击进入 4.搜索匹配报错信息 5.往下看看用到这个关键字的地方 6.从源码第一行开始看 7.settings.py&…
阅读更多...
安全认证中的CSRF

安全认证中的CSRF

1、什么叫做CSRF攻击 简单地说&#xff0c;就是说恶意网站&#xff0c;虽然没有盗取你的用户名和密码信息&#xff0c;但是却可以伪装成你&#xff0c;然后登录到银行&#xff0c;或者等危险网站&#xff0c;模拟你进行操作。利用的就是cookies这个特性&#xff0c;即浏览器提供…
阅读更多...
csrf验证问题 -- 不同域名下Iframe嵌套Cookie失效导致csrf验证失败

csrf验证问题 -- 不同域名下Iframe嵌套Cookie失效导致csrf验证失败

问题原因 Cookie:SameSite Chrome 51 开始&#xff0c;浏览器的 Cookie 新增加了一个SameSite属性&#xff0c;主要用于防止CSRF攻击和用户追踪。 cookie的SameSite属性用来限制第三方Cookie&#xff0c;从而减少安全风险(防止CSRF)。 SameSite可以有下面三种值&#xff1a;…
阅读更多...
接口报403，报CSRF验证失败的问题

接口报403，报CSRF验证失败的问题

问题定位&#xff1a;后台两个接口重名&#xff0c;走了优先级更高的接口&#xff0c;接口没有过滤CSRF&#xff1b; 一、csrf是什么 CSRF&#xff08;Cross-site request forgery&#xff09;跨站请求伪造&#xff0c;是一种常见的web安全漏洞&#xff0c;概括地说就是指&…
阅读更多...
Django的csrf豁免：解决CSRF验证失败，请求被中断问题

Django的csrf豁免：解决CSRF验证失败，请求被中断问题

1.CSRF介绍 跨站请求伪造&#xff08;英语&#xff1a;Cross-site request forgery&#xff09;&#xff0c;也被称为 one-click attack 或者 session riding&#xff0c;通常缩写为 CSRF 或者 XSRF&#xff0c; 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的…
阅读更多...
解决：禁止访问 (403) CSRF验证失败

解决：禁止访问 (403) CSRF验证失败

在测试Django框架POST请求方式时&#xff0c;程序报错如下 在确保访问安全的情况下有一下两种方式&#xff1a; 1、在相应html文件form代码块中添加如下代码&#xff1a; <form method"post" action"/method_show/">{% csrf_token %} <!-- 改行…
阅读更多...
Ubiquant LGBM Baseline 九坤量化大赛 版本44

Ubiquant LGBM Baseline 九坤量化大赛 版本44

数据描述&#xff1a; 该数据集包含来自数千项投资的真实历史数据的特征。你的挑战是预测与做出交易决策相关的模糊指标的价值。 Your challenge is to predict the value of an obfuscated metric relevant for making trading decisions. 这是一个代码竞赛&#xff0c;它依…
阅读更多...
lgbm的roc曲线，auc计算

lgbm的roc曲线，auc计算

lgbm模型画ROC曲线 1、得到分类的概率 import numpy as npimport pandas as pdimport lightgbm as lgbfrom sklearn.model_selection import train_test_splitX_train, X_test, y_train, y_test \train_test_split(data.iloc[:, 0:-1], # featuredata.iloc[:, -1], # label…
阅读更多...
LightGBM C++使用问题

LightGBM C++使用问题

~~~~~~~~~~~~~~~~~~~~串行single sample predict~~~~~~~~~~~~~~~~~~~~~~~~~ python下已测试通过&#xff0c;无问题&#xff1a; 然而C下问题是&#xff1a; 1&#xff0c;首先是与python下概率不一致&#xff1b; 2&#xff0c;然后是所有输入的结果都一样 初步怀疑版本问题…
阅读更多...
kaggle学习笔记-otto-baseline5-LGBM的使用

kaggle学习笔记-otto-baseline5-LGBM的使用

数据处理 import polars as pltrain pl.read_parquet(../input/otto-train-and-test-data-for-local-validation/test.parquet) train_labels pl.read_parquet(../input/otto-train-and-test-data-for-local-validation/test_labels.parquet)def add_action_num_reverse_chr…
阅读更多...
LightGBM（LGB）

LightGBM（LGB）

转载自littlemichelle LightGBM&#xff08;Light Gradient Boosting Machine&#xff09;是一个实现GBDT算法的框架&#xff0c;支持高效率的并行训练&#xff0c;并且具有更快的训练速度、更低的内存消耗、更好的准确率、支持分布式可以快速处理海量数据等优点。 背景 常用…
阅读更多...
lgbm参数分析及回归超参数寻找

lgbm参数分析及回归超参数寻找

参考&#xff1a;lgbm的github: https://github.com/Microsoft/LightGBM/blob/master/docs/Parameters.rst 代码来源参见我另一篇博客&#xff1a; https://blog.csdn.net/ssswill/article/details/85217702 网格搜索寻找超参数&#xff1a; from sklearn.model_selection imp…
阅读更多...
LGBM 模型结果 图形展示

LGBM 模型结果 图形展示

一、LGBM 模型结果 图形展示&#xff1a; 1、模型训练 train_x train[feas_x] train_y train[target].astype(int).copy() test_x, test_y test[feas_x], test[target] lgb_clf lgb.LGBMClassifier(objectivebinary,metricauc,num_leaves20,max_depth2,learning_rate0.06,…
阅读更多...
Python量化交易05——基于多因子选择和选股策略(随机森林，LGBM)

Python量化交易05——基于多因子选择和选股策略(随机森林，LGBM)

参考书目:深入浅出Python量化交易实战 在机器学习里面的X叫做特征变量&#xff0c;在统计学里面叫做协变量也叫自变量&#xff0c;在量化投资里面则叫做因子&#xff0c;所谓多因子就是有很多的特征变量。 本次带来的就是多因子模型&#xff0c;并且使用的是机器学习的强大的非…
阅读更多...
LightGBM（lgb）详解

LightGBM（lgb）详解

1. LightGBM简介 GBDT (Gradient Boosting Decision Tree) 是机器学习中一个长盛不衰的模型&#xff0c;其主要思想是利用弱分类器&#xff08;决策树&#xff09;迭代训练以得到最优模型&#xff0c;该模型具有训练效果好、不易过拟合等优点。GBDT不仅在工业界应用广泛&#…
阅读更多...
[机器学习] 模型融合GBDT(xgb/lgbm/rf)+LR 的原理及实践

[机器学习] 模型融合GBDT(xgb/lgbm/rf)+LR 的原理及实践

目录 一、原理 GBDT LR 是什么,用在哪 二、说明 GBDT LR 的结构 RF LR ? Xgb LR? GBDT LR 模型提升 三、实践 1 如何获得样本落在哪个叶子节点 2 举例 2.2.1 训练集准备 2.2.2 RFLR 2.2.3 GBDTLR 2.2.4 XgboostLR 2.2.5 单独使用RF, GBDT和Xgboost 2.2.6 …
阅读更多...
推荐文章

Copyright @ 2022~2023