CSRF的原理与防御 | 你想不想来一次CSRF攻击?-阿里云开发者社区

开发者社区> 小忽悠> 正文

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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
使用NAT网关轻松为单台云服务器设置多个公网IP
在应用中,有时会遇到用户询问如何使单台云服务器具备多个公网IP的问题。 具体如何操作呢,有了NAT网关这个也不是难题。
22525 0
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
4009 0
使用OpenApi弹性释放和设置云服务器ECS释放
云服务器ECS的一个重要特性就是按需创建资源。您可以在业务高峰期按需弹性的自定义规则进行资源创建,在完成业务计算的时候释放资源。本篇将提供几个Tips帮助您更加容易和自动化的完成云服务器的释放和弹性设置。
7580 0
windows server 2008阿里云ECS服务器安全设置
最近我们Sinesafe安全公司在为客户使用阿里云ecs服务器做安全的过程中,发现服务器基础安全性都没有做。为了为站长们提供更加有效的安全基础解决方案,我们Sinesafe将对阿里云服务器win2008 系统进行基础安全部署实战过程! 比较重要的几部分 1.
4963 0
阿里云服务器安全组设置内网互通的方法
虽然0.0.0.0/0使用非常方便,但是发现很多同学使用它来做内网互通,这是有安全风险的,实例有可能会在经典网络被内网IP访问到。下面介绍一下四种安全的内网互联设置方法。 购买前请先:领取阿里云幸运券,有很多优惠,可到下文中领取。
9307 0
阿里云服务器如何登录?阿里云服务器的三种登录方法
购买阿里云ECS云服务器后如何登录?场景不同,阿里云优惠总结大概有三种登录方式: 登录到ECS云服务器控制台 在ECS云服务器控制台用户可以更改密码、更换系.
5676 0
阿里云ECS云服务器初始化设置教程方法
阿里云ECS云服务器初始化是指将云服务器系统恢复到最初状态的过程,阿里云的服务器初始化是通过更换系统盘来实现的,是免费的,阿里云百科网分享服务器初始化教程: 服务器初始化教程方法 本文的服务器初始化是指将ECS云服务器系统恢复到最初状态,服务器中的数据也会被清空,所以初始化之前一定要先备份好。
10712 0
阿里云服务器ECS登录用户名是什么?系统不同默认账号也不同
阿里云服务器Windows系统默认用户名administrator,Linux镜像服务器用户名root
721 0
+关注
小忽悠
在技术的海洋里遨游
76
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载