CSRF的原理与防御 | 你想不想来一次CSRF攻击?

简介:

CSRFCross Site Request Forgery的缩写,中文翻译过来是跨站请求伪造。这个漏洞往往能给用户带来巨大的损失,CSRF在等保安全检测中,也是一个非常重要的检测项。但是在我们的网站中,大部分都没有做CSRF的防御,小伙伴们想不想来一次CSRF攻击,体验一下做黑客感觉?如果想要做黑客,可要仔细的往下看哟~

CSRF攻击的原理

要想理解CSRF攻击的原理,我们从一个经典的案例出发,看看它是如何进行攻击的。假设你的银行网站的域名是www.a-bank.com,这个银行网站提供了一个转账的功能,在这个功能页面中,有一个表单,表单中有两个输入框,一个是转账金额,另一个是对方账号,还有一个提交按钮。当你登录了你的银行网站,输入转账金额,对方账号,点击提交按钮,就会进行转账。

当然,现在的银行网站不会有这么简单的转账操作了,我们在这里只是举一个简单的例子,让大家明白CSRF的原理。咱们可以发散思维,联想到其他类似的操作。

这个转账的表单项,如下所示:

<form method="post" action="/transfer">
    <input type="text" name="amount"/>
    <input type="text" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

当我们输入金额和账号,点击提交按钮,表单就会提交,给后端的银行网站服务发送请求。请求的内容如下:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded

amount=100.00&account=9876

请求成功后,你输入的转账金额100元,将转账到9876这个账户当中。假如你完成转账操作后,并没有退出登录,而是访问了一个恶意网站,这时,你的银行网站www.a-bank.com还是处于登录状态,而这个恶意网站中,出现了一个带有”赢钱“字样的按钮,这个”赢钱“字样的按钮后面是一个form表单,表单如下:

<form method="post" action="https://www.a-bank.com/transfer">
    <input type="hidden" name="amount" value="100.00"/>
    <input type="hidden" name="account" value="黑客的银行账户"/>
    <input type="submit" value="赢钱!"/>
</form>

我们可以看到这个表单中,金额和账户都是隐藏的,在网页上只看到了一个赢钱按钮。这时,你忍不住冲动,点了一个”赢钱“按钮,这时,将会发生什么操作呢?我们仔细看一下上面表单中的action写的是什么?action写的是你的银行网站的转账请求接口。你点了一下赢钱按钮,在这个不正规的网站中,将会发送https://www.a-bank.com/transfer这个请求,在发送这个请求的时候,会自动带上www.a-bank.com的cookie,不要问我为什么是这样,这是浏览器的标准,标准就是这样规定的。银行后台接到这个请求后,首先要判断用户是否登录,由于携带了cookie,是登录的,会继续执行后面的转账流程,最后转账成功。你点了一下”赢钱“按钮,自己没有赚到钱,而是给黑客转账了100元。

这就是CSRF攻击的原理,在其他的网站向你的网站发送请求,如果你的网站中的用户没有退出登录,而发送的请求又是一些敏感的操作请求,比如:转账,那么将会给你的网站的用户带来巨大的损失。

CSRF的防御

我们知道了CSRF攻击的原理,就可以做针对性的防御了。CSRF的防御可以从两个方面考虑,一个是后台接口层做防御;另一个则是在前端做防御,这种不同源的请求,不可以带cookie。

后端防御CSRF

我们先聊聊后端的防御,后端防御主要是区分哪些请求是恶意请求,哪些请求是自己网站的请求。区分恶意请求的方式有很多,在这里给大家介绍两种吧。

第一种,CSRF Token的方式。这种方式是在表单页面生成一个随机数,这个随机数一定要后端生成,并且对这个随机数进行存储。在前端页面中,对这个Token表单项进行隐藏。代码如下:

<form method="post" action="/transfer">
    <input type="hidden" name="_csrf" value="4bfd1575-3ad1-4d21-96c7-4ef2d9f86721"/>
    <input type="text" name="amount"/>
    <input type="hidden" name="account"/>
    <input type="submit" value="Transfer"/>
</form>

_csrf就是CSRF Token。我们看到他的value是一个UUID,这个UUID是后台生成的。当用户点击转账按钮时,会给银行的后台发送请求,请求中包含_csrf参数,如下:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid
Content-Type: application/x-www-form-urlencoded

amount=100.00&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

银行后台接收到这个请求后,判断_csrf的值是否存在,如果存在则是自己网站的请求,进行后续的流程;如果不存在,则是恶意网站的请求,直接忽略。

第二种,通过请求头中的referer字段判断请求的来源。每一个发送给后端的请求,在请求头中都会包含一个referer字段,这个字段标识着请求的来源。如果请求是从银行网站发出的,这个字段会是银行网站转账页的链接,比如:https://www.a-bank.com/transfer-view;如果是从恶意网站发出的,那么referer字段一定不会是银行网站。我们在做后端防御时,可以先取出每个请求的请求头中的referer字段,判断是不是以自己网站的域名开头,在咱们的示例中,如果referer字段是以https://www.a-bank.com/开头的,则继续执行转账操作;如果不是,则直接忽略掉这个请求。

以上就是后端防御CSRF攻击的两种方式,都需要在后端做特殊的处理。当然也可以在前端做处理,怎么做呢?我们接着往下看。

前端防御CSRF

既然CSRF攻击的危害这么大,为什么不能在前端禁止这种请求呢?各大浏览器厂商似乎也注意到了这个问题,谷歌提出了same-site cookies概念,same-site cookies 是基于 Chrome 和 Mozilla 开发者花了三年多时间制定的 IETF 标准。它是在原有的Cookie中,新添加了一个SameSite属性,它标识着在非同源的请求中,是否可以带上Cookie,它可以设置为3个值,分别为:

  • Strict
  • Lax
  • None

Cookie中的内容为:

POST /transfer HTTP/1.1
Host: www.a-bank.com
Cookie: JSESSIONID=randomid;SameSite=Strict;

Strict是最严格的,它完全禁止在跨站情况下,发送Cookie。只有在自己的网站内部发送请求,才会带上Cookie。不过这个规则过于严格,会影响用户的体验。比如在一个网站中有一个链接,这个链接连接到了GitHub上,由于SameSite设置为Strict,跳转到GitHub后,GitHub总是未登录状态。

Lax的规则稍稍放宽了些,大部分跨站的请求也不会带上Cookie,但是一些导航的Get请求会带上Cookie,如下:

请求类型 示例 Lax情况
链接 <a href="..."></a> 发送 Cookie
预加载 <link rel="prerender" href="..."/> 发送 Cookie
GET 表单 <form method="GET" action="..."> 发送 Cookie
POST 表单 <form method="POST" action="..."> 不发送
iframe frameLabelStart--frameLabelEnd 不发送
AJAX $.get("...") 不发送
Image <img src="..."> 不发送

上面的表格就是SameSite设置为Lax的时候,Cookie的发送情况。

None就是关闭SameSite属性,所有的情况下都发送Cookie。不过SameSite设置None,还要同时设置Cookie的Secure属性,否则是不生效的。

以上就是在前端通过Cookie的SameSite属性防御CSRF攻击,不过大家在使用SameSite属性时,要注意浏览器是否支持SameSite属性。

总结

到这里CSRF的攻和防都已经介绍完了,大部分网站都是没有做CSRF防御的,小伙伴们有没有想当黑客的瘾,找几个网站搞一下试试吧~~
qrcode_for_gh_9de0de9f17e4_258

目录
相关文章
|
28天前
|
存储 Web App开发 安全
如何防范 CSRF 攻击
CSRF(跨站请求伪造)攻击是一种常见的安全威胁。防范措施包括:使用Anti-CSRF Token、检查HTTP Referer、限制Cookie作用域、采用双重提交Cookie机制等,确保请求的合法性与安全性。
|
28天前
|
网络安全 数据安全/隐私保护
什么是 CSRF 攻击
CSRF(跨站请求伪造)攻击是指攻击者诱导用户点击恶意链接或提交表单,利用用户已登录的身份在目标网站上执行非授权操作,如转账、修改密码等。这种攻击通常通过嵌入恶意代码或链接实现。
|
1月前
|
安全 前端开发 Java
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第26天】Web安全是现代软件开发的重要领域,本文深入探讨了XSS和CSRF两种常见攻击的原理及防御策略。针对XSS,介绍了输入验证与转义、使用CSP、WAF、HTTP-only Cookie和代码审查等方法。对于CSRF,提出了启用CSRF保护、设置CSRF Token、使用HTTPS、二次验证和用户教育等措施。通过这些策略,开发者可以构建更安全的Web应用。
83 4
|
1月前
|
安全 Go PHP
Web安全进阶:XSS与CSRF攻击防御策略深度解析
【10月更文挑战第27天】本文深入解析了Web安全中的XSS和CSRF攻击防御策略。针对XSS,介绍了输入验证与净化、内容安全策略(CSP)和HTTP头部安全配置;针对CSRF,提出了使用CSRF令牌、验证HTTP请求头、限制同源策略和双重提交Cookie等方法,帮助开发者有效保护网站和用户数据安全。
66 2
|
1月前
|
存储 安全 Go
Web安全基础:防范XSS与CSRF攻击的方法
【10月更文挑战第25天】Web安全是互联网应用开发中的重要环节。本文通过具体案例分析了跨站脚本攻击(XSS)和跨站请求伪造(CSRF)的原理及防范方法,包括服务器端数据过滤、使用Content Security Policy (CSP)、添加CSRF令牌等措施,帮助开发者构建更安全的Web应用。
83 3
|
1月前
|
SQL 存储 安全
什么是XSS攻击?什么是SQL注入攻击?什么是CSRF攻击?
理解并防范XSS、SQL注入和CSRF攻击是Web应用安全的基础。通过采用严格的输入验证、使用安全编码实践以及实现适当的身份验证和授权机制,可以有效防止这些常见的Web攻击,保障应用程序和用户的数据安全。
37 0
|
3月前
|
SQL 安全 数据库
从入门到精通:Python Web安全守护指南,SQL注入、XSS、CSRF全防御!
【9月更文挑战第13天】在开发Python Web应用时,安全性至关重要。本文通过问答形式,详细介绍如何防范SQL注入、XSS及CSRF等常见威胁。通过使用参数化查询、HTML转义和CSRF令牌等技术,确保应用安全。附带示例代码,帮助读者从入门到精通Python Web安全。
94 6
|
4月前
|
Web App开发 存储 安全
就一次!带你彻底搞懂CSRF攻击与防御
与XSS攻击相比,利用CSRF漏洞发动攻击会比较困难,这也是在网络上看起来CSRF的人气小于XSS的原因之一。下面我们来利用CSRF漏洞发起攻击,并针对攻击进行防御,彻底弄懂CSRF,话不多说,我们直接开冲。
|
5月前
|
运维 安全 Java
什么是 CSRF?如何防止 CSRF 攻击?
CSRF 攻击是一种常见且危险的 Web 安全漏洞,攻击者可以通过伪造用户请求,执行恶意操作,作为程序员,为了防御 CSRF 攻击,常见的策略包括使用 CSRF Token、检查 Referer 或 Origin 头、设置 SameSite Cookie 属性以及双重提交 Cookie。 因为程序员对于 CSRF 攻击可以做的事情还是很有限,所以,承担主要责任的是安全部门或者运维部门,但是作为程序员,我们需要具备这些安全意识,在安全等级比较高的需求中也需要把这些安全因素考虑在内。
|
7月前
|
JavaScript 安全 前端开发
js开发:请解释什么是XSS攻击和CSRF攻击,并说明如何防范这些攻击。
XSS和CSRF是两种常见的Web安全威胁。XSS攻击通过注入恶意脚本盗取用户信息或控制账户,防范措施包括输入验证、内容编码、HTTPOnly Cookie和CSP。CSRF攻击则诱使用户执行未经授权操作,防范手段有CSRF Tokens、双重验证、Referer检查和SameSite Cookie属性。开发者应采取这些防御措施并定期进行安全审计以增强应用安全性。
129 0