CSRF（跨域请求伪造）
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
你这可以这么理解CSRF攻击： 攻击者盗用了你的身份，以你的名义发送恶意请求。 CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账……造成的问题包括：个人隐私泄露以及财产安全。
从上图可以看出，要完成一次CSRF攻击，受害者必须依次完成两个步骤：
登录受信任网站A，并在本地生成Cookie。
在不登出A的情况下，访问危险网站B。
看到这里，你也许会说：“如果我不满足以上两个条件中的一个，我就不会受到CSRF的攻击”。是的，确实如此，但你不能保证以下情况不会发生：
1.你不能保证你登录了一个网站后，不再打开一个tab页面并访问另外的网站。
2.你不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束。
3.上图中所谓的攻击网站，可能是一个存在其他漏洞的可信任的经常被人访问的网站。
1.提交验证码
在表单中增加一个随机的数字或字母验证码，通过强制用户和应用进行交互，来有效地遏制CSRF攻击。
2.Referer Check（referer：标志请求来源）
检查如果是非正常页面过来的请求，则极有可能是CSRF攻击。
3.token验证
在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有
token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
token需要足够随机
敏感的操作应该使用POST，而不是GET，以form表单的形式提交，可以避免token泄露。
4. 在 HTTP 头中自定义属性并验证
这种方法也是使用 token 并进行验证，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
csrf过滤器：
referer检查如果是非正常页面过来的请求，则极有可能是CSRF攻击。
自定义请求头“supporter”，根据电话、邮箱、日期、特殊字符、base64前台加密，后台过滤器解析。
请问常见的网络攻击技术有哪些
常见的网络攻击技术有：
1，跨站脚本攻击。
跨站脚本攻击可以将代码注入到用户浏览的网页上，这种代码包括HTML和JavaScript。
2，跨站请求伪造攻击。
跨站请求伪造攻击是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。
3，SQL注入攻击。
这种攻击的原理是服务器上的数据库运行非法的SQL语句，主要通过拼接来完成。
更多关于常见的网络攻击技术有哪些，进入：查看更多内容
CSRF(跨站请求伪造)
2021-11-24
跨站点请求伪造(Cross—Site Request Forgery)，伪装来自受信任用户的请求来利用受信任的网站。简单来说CSRF就是获取凭证伪造身份去做事。
详细点说：假如A网站中存在CSRF漏洞，攻击者构造一个利用的POC，发送给受害者(在浏览器中处于登陆状态)，让受害者点击POC，导致受害者在A网站上的的资料被修改或者钱财被转移。
所有用户进行操作的位置都可能存在CSRF，修改信息、密码、头像。
1.利用浏览器中缓存的cookie
2.没有一次型的token验证
1.修改受害者的一些资料、转账或者改密码
2.如果获取到应用程序中的管理员cookie，攻击者完全可以控制应用的所有数据和功能
1.资源包含
资源包含是在大多数介绍CSRF概念的演示或基础课程中可能看到的类型。这种类型归结为控制HTML标签（例如image、audio、video、object、script等）所包含的资源的攻击者。如果攻击者能够影响URL被加载的话，包含远程资源的任何标签都可以完成攻击。
2.基于表单
通常在正确使用安全的请求方式时看到。攻击者创建一个想要受害者提交的表单; 其包含一个JavaScript片段，强制受害者的浏览器提交。
3.XMLHttpRequest
基于XHR的CSRF通常由于SOP而以XSS有效载荷的形式出现。没有跨域资源共享策略 (Cross-Origin Resource Sharing, CORS)，XHR仅限于攻击者托管自己的有效载荷的原始请求。
通过CSRF-token或者验证码来检测用户提交
验证 Referer/Content-Type
对于用户修改删除等操作最好都使用POST操作
避免全站通用的Cookie，严格设置Cookie的域
1.跨账户使用令牌
2.替换相同的长度
3.从请求中删除csrf token
4.解码CSRF token
5.通过HTML提取CSRF token
6.只使用token的静态部分
参考链接：
跨站请求伪造与 Same-Site Cookie
跨站请求伪造（又被称为 CSRF 或者 XSRF ），它源自一个域网站向另一个域网站发起请求的简单功能。攻击者通过一些技术手段欺骗用户使用浏览器去访问一个自己曾经认证过的网站并执行一些敏感操作（如转账）。
一个域网站向另一个域的网站发起请求的方式有很多，例如点击一个超链接、加载静态资源、提交表单以及直接发起 ajax 请求等。如：
如果用户之前在 a.com 认证过，即浏览器保持有效的 cookie ，这些请求也会携带相应的 cookie ，而用户可能并不知情。
Same-Site Cookies 出现以前我们并没有一种简单而有效的方式去阻止 CSRF 攻击，其中一种方式是通过检查 origin 和 referer 来校验，缺点是依赖浏览器发送正确的字段，而这并不总是准确有效的；另一种方式则是通过给表单添加随机 token 的方式来校验，但是部署比较麻烦。
Same-Site Cookies 的出现就是为了解决这个问题，它可以完全有效的阻止 CSRF 攻击。Same-Site Cookies 非常容易部署，只需要将你原来的设置 cookie 的地方，如下：
改为：
准确的说 SameSite 这个属性有两个可选值，分别是 Strict 和 Lax 。其中 Strict 为严格模式，另一个域发起的任何请求都不会携带该类型的 cookie，能够完美的阻止 CSRF 攻击，但是也可能带来了少许不便之处，例如通过一个导航网站的超链接打开另一个域的网页会因为没有携带 cookie 而导致没有登录等问题。因此 Lax 相对于 Strict 模式来说，放宽了一些。简单来说就是，用 「安全」的 HTTP 方法（GET、HEAD、OPTIONS 和 TRACE）改变了当前页面或者打开了新页面 时，可以携带该类型的 cookie。具体见下表：
现在 a.com 域下设置传统的 cookie，如下：
现在 b.com 的网页加载 a.com 的 css 文件时会携带该 cookie，如下：
b.com 的网页中的表单向 a.com 中的接口提交数据时也会携带该 cookie，如下：
现在将该 cookie 改为 SameSite = Strict，如下：
现在 b.com 的网页加载 a.com 的 css 文件时不会再携带该 cookie，如下：
b.com 的网页中的表单向 a.com 中的接口提交数据时也不会再携带该 cookie，如下：
b.com 的网页中通过点击超链接打开的 a.com 的网页也不会携带该 cookie，如下：
现在将该 cookie 改为 SameSite = Strict，如下：
SameSite = Lax 时表现与 SameSite = Strict 时完全一致，除了通过点击超链接打开的 a.com 的网页时会携带该 cookie，如下：
什么是 CSRF 攻击，如何避免
CSRF攻击，全称为“Cross-site request forgery”，中文名为跨站请求伪造，也被称为“One Click Attack”或者“Session Riding”，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。
XSS主要是利用站点内的信任用户，而CSRF则通过伪装来自受信任用户的请求，来利用受信任的网站。与XSS相比，CSRF更具危险性。
如何防御CSRF攻击?
1、重要数据交互采用POST进行接收，当然POST也不是万能的，伪造一个form表单即可破解。
2、使用验证码，只要是涉及到数据交互就先进行验证码验证，这个方法可以完全解决CSRF。
3、出于用户体验考虑，网站不能给所有的操作都加上验证码，因此验证码只能作为一种辅助手段，不能作为主要解决方案。
4、验证HTTP Referer字段，该字段记录了此次HTTP请求的来源地址，最常见的应用是图片防盗链。
5、为每个表单添加令牌token并验证。
0条大神的评论