csrf介绍

跨站点请求伪造 (CSRF) 是一种攻击类型，当恶意网站、电子邮件、博客、即时消息或程序导致用户的 Web 浏览器在用户通过身份验证时在受信任站点上执行不需要的操作时，就会发生这种攻击。CSRF 攻击有效，因为浏览器请求会自动包含所有 cookie，包括会话 cookie。因此，如果用户通过了站点的身份验证，站点就无法区分合法的授权请求和伪造的身份验证请求。当使用适当的授权时，这种攻击会被阻止，这意味着需要一种质询-响应机制来验证请求者的身份和权限。

成功的 CSRF 攻击的影响仅限于易受攻击的应用程序暴露的能力和用户的权限。例如，这种攻击可能会导致资金转移、更改密码或使用用户凭据进行购买。实际上，攻击者使用 CSRF 攻击使目标系统通过受害者的浏览器执行功能，而受害者不知道，至少在未经授权的交易被提交之前。

csrf攻击类型

GET类型的CSRF

<img src="http://bank.example/withdraw?account&=xx&amount=100&to=hacker" >

受害者访问了html标签里有img属性的页面以后，就会向该网站发送一个http请求，该网站也会收到包含受害者登录信息的一次跨域请求。

Post类型的CSRF

<form action = "https://bank.example/withdraw" method="POST"> <input type="hidden" name="account" value="xx" /> <input type="hidden" name="ammount" value="100" /> <input type="hidden" name="for" value="hacker" /> </form> <script> document.forms[0].submit(); </script>

访问带有该表单的页面以后会向bank网站发送一次post请求。

链接类型的CSRF

这种类型的csrf需要用户点击链接才能触发，通常会诱骗用户点击。各位lsp请注意一下

csrf的防御

同源检测

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

　　Origin Header

　　Referer Header

这两个Header不能由前端自定义内容。 服务器通过解析这两个Header中的域名，确定请求的来源域。

同步器令牌模式

CSRF 令牌在服务器端生成，它们可以为每个用户会话或每个请求生成一次。每个请求令牌比每个会话令牌更安全。在初始生成令牌后的每个会话令牌实现中，该值存储在会话中并用于每个后续请求，直到会话过期。

不应使用 cookie 传输 CSRF 令牌

CSRF 令牌可以通过隐藏字段、标题添加，并且可以与表单和 AJAX 调用一起使用。GET 请求中的 CSRF 令牌可能会在多个位置泄露。

双重提交 Cookie

双重Cookie采用以下流程：

　　双重Cookie采用以下流程：

　　在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）。

　　在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment? csrfcookie=v8g9e4ksfhw）。　

　　后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。

  • 用双重Cookie防御CSRF的优点：
    无需使用Session，适用面更广，易于实施。
    Token储存于客户端中，不会给服务器带来压力。
    相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。
    缺点：
    Cookie中增加了额外的字段。
    如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。
    难以做到子域名的隔离。
    为了确保Cookie传输安全，采用这种防御方式的最好用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。

Samesite Cookie属性

Samesite 有两个属性值，分别是 Strict 和 Lax。Strict表示严格模式，即不接受第三方cookie，意思很明了，就是通过百度跳转到淘宝京东的页面时，并不会是登录状态。Lax表示宽松模式，假如是跳转页面且是get请求时，可以作为第三方cookie