【開山安全笔记】跨站请求伪造CSRF，2024年最新2024网络安全春招面试真题详解

最新推荐文章于 2024-10-16 17:15:20 发布

2401_83739777

最新推荐文章于 2024-10-16 17:15:20 发布

阅读量970

点赞数 9

分类专栏： 2024年程序员学习文章标签：安全 web安全笔记

本文链接：https://blog.csdn.net/2401_83739777/article/details/137803521

版权

2024年程序员学习专栏收录该内容

279 篇文章 1 订阅

订阅专栏

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

在这里插入图片描述

典型的CSRF攻击

一个CSRF漏洞攻击的实现，其需要由三个部分来构成

有一个漏洞存在（无需验证、任意修改后台数据、新增请求）；

伪装数据操作请求的恶意链接或者页面；

诱使用户主动访问或登录恶意链接，触发非法操作

2 CSRF防御

CSRF的防御可以从两个方面考虑，一是后台接口层做防御，另一个则是在前端做防御。

2.1 后端防御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.1Host: www.a-bank.comCookie: JSESSIONID=randomidContent-Type: application/x-		www-form-urlencoded
amount=100.00&account=9876&_csrf=4bfd1575-3ad1-4d21-96c7-4ef2d9f86721

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

二、通过请求头中的referer字段判断请求的来源

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

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

2.2 前端防御CSRF

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

Cookie中的内容为：

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

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

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

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

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

3 常见问题

1. CSRF 与 SSRF 区别

CSRF (Cross-Site Request Forgery) 即跨站请求伪造，伪造用户请求，冒用用户身份。

SSRF (Server-Side Request Forgery) 即服务端请求伪造，就是伪造一个服务端请求，攻击者伪造服务端的请求发起攻击，攻击者借由服务端为跳板来攻击目标系统。

用非常通俗的语言讲的话，CSRF 更像是钓鱼的举动，是用户攻击用户的；而对于 SSRF 来说，是由服务器发出请求，用户攻击服务器的。

2. XSS 与 CSRF的区别

XSS (Cross Site Scripting) 跨站脚本攻击与 CSRF 的最大区别在于对 Cookie 的使用，XSS 把受害者的 Cookie 偷过来，而 CSRF 则是借用了受害者的 Cookie。

3. samesite防御CSRF的原理

在原有的Cookie中，新添加了一个SameSite属性，它标识着在非同源的请求中，是否可以带上Cookie，它可以设置为3个值，分别为：Strict Lax None

4. json格式的CSRF如何防御？

前景知识：

json格式的CSRF存在的条件是POST 传参采用 JSON 格式，而不是传统的parameter=value的格式。一般采用 Json 格式传输参数时，请求包中都有 Content-Type 头，一般服务器也会验证 Content-Type 值是否为 application/json，当服务器验证 Content-Type 时，若不符合要求，则会抛出异常，导致传输的数据失效。
1）用户操作验证，在提交数据时需要输入验证码
2）请求来源验证，验证请求来源的referer
3）表单token验证