一篇文章学会csrf
本篇文章我们将详细的介绍一下CSRF的相关知识，包括原理、分类、攻击手法、修复方法等。
注意测试尽量在测试环境进行，生产环境最好知道自己该干什么不该干什么！！！
注意测试尽量在测试环境进行，生产环境最好知道自己该干什么不该干什么！！！
注意测试尽量在测试环境进行，生产环境最好知道自己该干什么不该干什么！！！
**什么是CSRF
**
**
**
跨站请求伪造 （Cross-site request forgery） 就是攻击者通过一定的手段使用户的浏览器去访问用户之前登录过并且令牌没有失效的网站，并执行他们本来不打算执行的操作。
比如一个网站存在 CSRF，那么攻击者通过 payload 可能会让用户在不经意间完成 修改账号绑定的邮箱、修改账号密码、转账 等等，通过这些操作攻击者就能完全控制受害者的账号。而如果受害者是系统管理员呢？那危害可能更大。
**
**
**前提条件
**
**
**
- 这个网站上有值得你去攻击的功能。比如上面提到的修改邮箱、密码、转账、手机号 等，再不济也得有个增删改的功能吧，如果这个网站只是一个查看数据的地方，那你发起 CSRF 也没什么用，因为你拿不到对方查看的数据。
- 基于 cookie 的会话处理。这个网站对于客户端发起请求只通过 cookie 进行用户验证，没有其他的会话跟踪和用户验证机制。
- 没有不可预测的参数。比如 在修改密码的时候需要输入验证码或者原密码，这两个参数攻击者既不知道，也猜不到，那这个功能就不会被 CSRF 成功攻击
**
**
**测试方法
**
**
**
对于 CSRF 的测试方法其实很简单
- 打开burp
- 找到你要测试的那个请求
- 右键 -> engagement tools -> Generate CSRF PoC
4.视情况改改 POC
5.点击 Test in browser -> copy
6.打开浏览器，粘贴刚才复制的 URL 到浏览器导航栏
7.回车之后如果执行成功那就是有 CSRF 漏洞
8.失败的话就看看报错是什么引起的来判断是POC的问题还是不存在 CSRF 漏洞，这个就需要具体情况具体分析了
**
**
**利用方法
**
**
**
CSRF 的传播和反射型XSS的利用方式基本上是一样的：
- 攻击者把恶意代码放在其自己控制的网站上，诱导受害者访问这个网站
- 通过邮件、短信、社交软件进行传播
- 放在存在该漏洞的网站上，等待有缘人，比如评论区
CSRF 和 XSS 的区别
- XSS 允许攻击者在受害者的浏览器上执行 js 代码；而 CSRF 不行
- XSS 通过窃取受害者的 cookie 来实现账号接管，如果目标站点使用了 httponly 这就行不通了；CSRF 通过浏览器发起请求，自动携带受害者的cookie信息，即使有 httponly 也不影响 CSRF 攻击的实现
- XSS 的危害更大。攻击者如果成功实现了 XSS 攻击，那通常意味着他可以使用受害者在这个网站的所有功能，而 CSRF 只限于特定的存在漏洞的功能
- CSRF 无法让攻击者获取到服务器返回的数据，由于请求是由受害者的浏览器发起的，那么服务器的响应最后还是给到了受害者那里，攻击者是拿不到这部分数据的，所以对于一些查询类功能，即便没有做任何防御 CSRF 的措施，它也几乎是没有利用价值的；而 XSS 由于可以执行js代码，这也就使得攻击者可以将它想要的数据发送到自己的服务器上，比如前面 XSS 章中提到的回传 cookie。
**
**
**防御方法
**
**
**
1.【最保险】CSRF Token：通过服务器生成一个唯一的、不可预测的值，然后发送给客户端。当用户要执行敏感操作，比如提交表单的时候，要求客户端在请求包中携带上这个 CSRF Token，这样攻击者就很难去构造一个属于这个用户的有效请求，从而防止 CSRF 的发生。
2.SameSite cookie：该属性可以用于指定是否允许 Cookie 被跨站点请求使用。SameSite 属性有三个可选值：
(1) Strict（严格模式）：Cookie 在任何跨站点请求中都不会被发送，这样可以防止 CSRF 攻击。但这可能会导致某些功能受限，特别是当网站需要在跨站点请求中使用 Cookie 时。
(2) Lax（宽松模式）：Cookie 只在顶级导航（例如从外部网站链接进入的页面）以及 GET 方法的跨站点请求中发送。POST、PUT、DELETE 等请求不会发送 Cookie。这样可以在一定程度上保护用户的隐私和防范 CSRF 攻击。
(3) None（无限制模式）：Cookie 在任何情况下都会被发送，即使是跨站点请求。需要注意的是，使用 None 模式时，必须同时设置 Secure 属性（仅通过 HTTPS 传输）才能生效，并且该模式存在一定的安全风险和隐私问题，应谨慎使用。
3.【可能会有坑】校验 Referer 头：有的网站可能通过验证请求的 referer 是否来自网站自己的域名来防止 CSRF 攻击，但是在一些情况下，这种验证可能无法起到防止 CSRF 的作用
**案例详解
**
任务简报
这个实验室在修改邮箱的地方存在一个CSRF漏洞，要解决这个实验室你需要制作一个 POC 来修改受害者的邮箱。
任务过程
1.使用提供的账号密码登录实验室 wiener:peter
2.可以看到此时默认邮箱是 wiener@normal-user.net ，我们先随便修改一个抓个包，修改后的 111@normal-user.net
3.我们可以看到，这里只提交了一个修改后的邮箱，这里我们可以使用 burp 自带的功能来生成 POC
4.现在我们要做的就是把邮箱修改成我们自己的 13333333333@qq.com，所以我们只需要修改 value 中的值就可以了
5.对于我们平时的测试来说，下一步点击 Test in browser -> copy 然后在同一个浏览器打开，来模拟受害者点击我们传播的 url 即可
6.此时我们会发现邮箱已经被改变了，对于日常的测试来说到这里就可以了，但是想要通过这个实验室，还需要后面的几步，这里让我们回到第4步，同时把邮箱改回 111@normal-user.net，以便下面的演示
7.将我们刚才修改后的POC复制到，实验室对应的利用服务器上
8.将 HTML 复制到 body 中，同时点击 store 保存
9.现在我们就要模拟受害者在登录了 web-security-academy.net 这个网站的时候，受到攻击者诱导，在攻击者的网站 exploit-server.net 上点击了一个功能 (View exploit) 然后浏览器自动发起修改 web-security-academy.net 上用户绑定邮箱的场景。点击 View exploit
10.可以看到，网站自动跳转到 web-security-academy.net 并将邮箱从 111@normal-user.net 修改为了 13333333333@qq.com，那么点击 deliver exploit to victim 将你的 POC 传播给受害者们就可以通过这个实验室了
**
**
**绕过思路
**
**
**
CSRF token 绕过
在本章节，重点在于各种情况下的绕过 CSRF token 的方式，一些重复性的操作就不再赘述
未限制请求方法
这种漏洞出现的原因就是研发人员没有限制请求方法，且没有完善的逻辑来处理各种情况
任务简报
这个实验室的修改邮箱处存在 CSRF 漏洞，并且它试图通过 CSRF token 来阻止CSRF攻击
任务过程
- 前面的过程我们就直接略过，我们看看它的修改邮箱的功能是如何实现的
2.这里我们可以看到是存在一个 CSRF token 的，我们删了它看看会怎么样，万一这玩意儿就是用来吓唬人的呢
\3. 很遗憾，看来他还是有用的，但是不要放弃，我们都知道由于一些奇奇怪怪的原因，研发在写代码的时候可能会出现一些奇怪的 bug，可能他们没有想到有些用户他不喜欢老老实实的使用他们开发的系统，这里我们用的就是这个思路
\4. 当你在使用 get 方法提交一些数据的时候，我们也可以使用 POST 来提交，那这里我们能不能用 get 来修改邮箱呢，那我们就试试
\5. surprise，它居然可以，那我们删了 CSRF 这个参数看看它的处理逻辑有没有变化
\6. 哈 get 方法居然没有校验 CSRF 了，那我们就继续老样子，右键生成 POC，保存到 利用服务器 就完事了
\7. 收工下班
未校验参数是否存在
这种漏洞出现的原因就是没有校验参数的完整性。
任务简报
这个实验室的修改邮箱处存在 CSRF 漏洞，并且它试图通过 CSRF token 来阻止CSRF攻击
任务过程
- 老样子，我们看看他是怎么修改邮箱的
\2. 和上面的案例没什么区别，那我们还是看看删除 CSRF 这个参数的结果怎么样
\3. 哈 这个更简单了，直接干，右键生成 POC，上传 利用服务器，就完事了，这里就不赘述了
使用公共的 CSRF token 池
这种情况是由于这个应用没有将一个用户的 session 和他的 CSRF token 进行绑定，而是做了一个公共的 CSRF token 池，只要是这个池里的 token，都是有效的。
那么大家应该也有思路了，那就是直接自己登录上去获取到一个 token 即可绕过
任务简报
这个实验室的修改邮箱处存在 CSRF 漏洞，并且它试图通过 CSRF token 来阻止CSRF攻击
任务过程
- 这个演示需要两个账号 wiener:peter 和 carlos:montoya
- 我们先登录 wiener，看看它的修改邮箱是怎么实现的
\3. 请求包还是一样的，我们看下上面的两种方式还能不能绕过 （当然不行，这里就不演示了）
4.这里我们先记录一下wiener的token值 roVAju4ZU5DLlKwBO9n0GzqvERfXumk8，然后登出当前账号，再次重新登录 carlos 看看刚才的 token 还能不能使用
\5. 这里我们使用 Intercept 拦截修改 CSRF 的值之后发现是无效的，现在就有几种可能，一是 token 和 session 绑定，不能使用别人的 token 来绕过校验；二是 token 是一次性的，用后即焚；三的话就是我们的主题 是公共token池，但是用后即焚
\6. 第一种可能上面已经验证过了，那么我们来验证第二种，其实也很简单，再修改一下邮箱，看看服务器有没有下发新的 CSRF token 就行了，或者看看两次传递的 token 是不是一样的
\7. 不太妙啊，居然是一次性的，那我们只能试试第三中情况了，让我们保存下现在的 token 不要用它 0wSAAuvFa8JFRSpD1BgSQifWo75xeJyt 然后登出 carlos 登录 wiener 在修改邮箱的时候替换 CSRF 的值，看看结果如何
\8. 哈哈 成功了，那么它的逻辑就很清楚了，用户每次修改邮箱的时候需要一个服务器下发的一次性 CSRF token，但这个 token 并没有与session绑定，而是从 公共token池 中提取的，那么我们就可以通过自己的账号来获取一个有效的 CSRF token 来绕过这个校验机制，只不过每次有用户上钩之后我们需要刷新这个 token 值
\9. 思路清晰之后我们只有重复上面案例中的过程就可以了，这里就不再赘述了
csrf token 直接在 cookie 中获取
这种情况下想要利用还需要有 CRLF 这里的漏洞来配合，或者有其他的可以注入 cookie 的漏洞，使得你可以控制 cookie 的数据进而控制 csrf token 的数据。
这样的防御思路是通过 cookie 和 请求体参数 双重提交token，服务器判断两个值是否相等来防御 csrf 漏洞，这样做的好处是服务器不需要进行多余的计算、保存 csrf token 值，在生成 cookie 的时候就可以一起完成。但是就像上面说的当用户可以定义 se-cookie 的时候，这种做法就不再安全了。
任务简报
这个实验室的修改邮箱处存在 CSRF 漏洞，并且它试图通过双重提交 CSRF token 来阻止CSRF攻击
任务过程
- 我们还是来看它的修改邮箱是如何实现的
\2. 这里可以看出他们是相同的，那么我们就需要一个地方来想办法注入 set-cookie，巧的是在搜索这里存在一个 CRLF 漏洞 payload %0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None
\3. 那么我们就可以在自己的服务器上（exploit-server.net）构造一个响应，让它去请求 web-security-academy.net 上的资源，然后发起一个请求来实现 CRLF 注入，之后再发送请求去修改邮箱就好了，思路有个那下面就是payload了
\4. 老样子我们先生成一个 CSRF 的POC
\5. 下面我们来做一下修改，让它来实现我们的功能，其实只需要修改
-
<html><!-- CSRF PoC - generated by Burp Suite Professional --><body> <form action="https://0a7c00ee0362ba6884d4dc8700fe006e.web-security-academy.net/my-account/change-email" method="POST"> <input type="hidden" name="email" value="111@normal-user.net" /> <input type="hidden" name="csrf" value="123456" /> <input type="submit" value="Submit request" /> </form> <img src="https://0a7c00ee0362ba6884d4dc8700fe006e.web-security-academy.net/?search=test%0d%0aSet-Cookie:%20csrf=123456%3b%20SameSite=None" onerror="document.forms[0].submit();"/></body></html>
\6. 上面的代码我们主要是利用了 img 标签去请求 web-security-academy.net 上的一个不存在的图片，当它发送这个请求的时候， web-security-academy.net 的 cookie 中的 csrf 键将被设置为 csrf=123456，当请求失败的时候，就会提交我们的 CSRF 代码来修改邮箱，那么我们来看看效果
\7. 这样我们的攻击就完成了，后边提交通过实验室的过程就不再赘述了
绕过 referer 头校验
有些网站通可能会通过校验 referer 头来判断请求是不是来自自己的网站，并以此来防御 CSRF 漏洞，但是这种防御方法在某些情况下也可能会被绕过。
删除 referer 头
这种情况存在于开发人员在写代码的时候没有考虑到 referer 头不存在的情况下的处理逻辑，导致绕过了 referer 校验。
但由于 referer 头是浏览器自动添加的请求头，所以通过上面的方式去要求 referer 头等于某个特定的值来绕过 referer 校验是不可行的。
知识点：meta 标签用于提供关于 HTML 文档的元数据信息，也可以用来控制客户端发起请求的时候是否携带某个请求头，如
任务简报
本实验室在修改账号邮箱的地方存在 CSRF 漏洞，但是网站通过 referer 头进行 CSRF 防御，通过 exploit-server 修改账号的邮箱来通关本实验室
点击进入靶场
任务过程
- 前面的过程我们先跳过，直接看看他是怎么发起修改邮箱的请求的
\2. 这里可以看到成功修改的话会自动跳转，同时请求包里有 referer 头，那我们看看把他该一下会是什么响应
\3. 这里报错无效的 referer，那我们看看删了它会有什么响应，毕竟对于很多情况下删除某些参数往往会有意外之喜
\4. 可以看到同样修改成功了，那么下一步就是如何在 POC 里让它不发送 referer 头了，这里就用上我们上面提到的 meta 标签了，下面我们看看有 meta 和没有的区别
\5. 老样子，还是生成一个 POC
\6. 可以看到，这样的POC发送的请求是含有 referer 头的，那我们给它稍微加点料 payload
\7. 神奇的事情发生了，referer 头没有了，那就意味着这个referer校验被我们绕过了，收工下班
包含目标网址的域名
还有一种情况是，对方的校验逻辑太过简单，比如检验 referer 是否以自己的域名开始，或者是否包含自己的域名 比如(if “www.baidu.com” in referer…)
这两种都可以用一种简单的办法绕过，那就是买一个域名，然后自己添加一个含有目标站点的子域名，比如 www.baidu.com.test.cn，其中的 www.baidu.com 就是子域名
对于后面的查看referer是否包含自己的域名，可以有一个简单的办法，比如在 uri 里加上它的值就好了，比如 history.pushState(‘’, ‘’, ‘/?www.baidu.com’)
**知识点：**history.pushState 允许你更改浏览器历史记录中的当前URL而不重新加载页面，简单的说就是可以在不刷新页面的情况下修改你在状态栏的url
以百度为例，正常状态下它的地址栏是 www.baidu.com
我们在控制台执行 history.pushState(“”,“”,“/?_”)，它的url就变成了 https://www.baidu.com/?_
这就意味着，我们可以虽然不能定义 referer 的域名，但是可以定义referer 的 uri 来绕过 (if “www.baidu.com” in referer…) 的校验，那么理论成立，实践开始
任务简报
本实验室在修改账号邮箱的地方存在 CSRF 漏洞，但是网站通过 referer 头进行 CSRF 防御，通过 exploit-server 修改账号的邮箱来通关本实验室
点击进入靶场
任务简报
- 老样子，直接看它的修改邮箱的请求包
\2. 没什么东西，看看referer是怎么校验的吧（删掉不好使，就不试了）
\3. 可以看到，上面的两种方法都能绕过，那就说明是校验 referer 中是否含有域名，那我们还是生成 POC，然后稍微修改一下 payload history.pushState(“”, “”, “/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net”)
4.这里可以看到，虽然我们加上了 history.pushState(“”, “”, “/?0afc003404932ab58ac96e4e005700a5.web-security-academy.net”) 但是它请求的时候 referer 并没有包含其中自定义的 uri。这是因为现在浏览器出于安全考虑会在请求的时候删除 referer 中的查询字段，但是这个也是可以解决的，不过就需要有点钞能力了，你可以租个服务器，设置响应头 Referrer-Policy: unsafe-url ，这样再次请求的时候就不会删掉你referer中的查询值了
\5. 这里我们使用靶场自带的利用服务器来演示
\6. 配置完成之后点击 store，然后访问上面的url
\7. 可以看到在访问 我们利用服务器上的页面之后，其正常响应了 referrer-policy，之后再次请求目标网站的时候，客户端就没有删除referer 头里的查询参数了，至此绕过也就完
学习网络安全技术的方法无非三种:
第一种是报网络安全专业，现在叫网络空间安全专业，主要专业课程:程序设计、计算机组成原理原理、数据结构、操作系统原理、数据库系统、 计算机网络、人工智能、自然语言处理、社会计算、网络安全法律法规、网络安全、内容安全、数字取证、机器学习，多媒体技术，信息检索、舆情分析等。
第二种是自学，就是在网上找资源、找教程，或者是想办法认识一-些大佬，抱紧大腿，不过这种方法很耗时间，而且学习没有规划，可能很长一段时间感觉自己没有进步，容易劝退。
如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！
第三种就是去找培训。
接下来，我会教你零基础入门快速入门上手网络安全。
网络安全入门到底是先学编程还是先学计算机基础？这是一个争议比较大的问题，有的人会建议先学编程，而有的人会建议先学计算机基础，其实这都是要学的。而且这些对学习网络安全来说非常重要。但是对于完全零基础的人来说又或者急于转行的人来说，学习编程或者计算机基础对他们来说都有一定的难度，并且花费时间太长。
第一阶段：基础准备 4周~6周
这个阶段是所有准备进入安全行业必学的部分，俗话说：基础不劳，地动山摇
第二阶段：web渗透
学习基础 时间：1周 ~ 2周：
① 了解基本概念：（SQL注入、XSS、上传、CSRF、一句话木马、等）为之后的WEB渗透测试打下基础。
② 查看一些论坛的一些Web渗透，学一学案例的思路，每一个站点都不一样，所以思路是主要的。
③ 学会提问的艺术，如果遇到不懂得要善于提问。
配置渗透环境 时间：3周 ~ 4周：
① 了解渗透测试常用的工具，例如（AWVS、SQLMAP、NMAP、BURP、中国菜刀等）。
② 下载这些工具无后门版本并且安装到计算机上。
③ 了解这些工具的使用场景，懂得基本的使用，推荐在Google上查找。
渗透实战操作 时间：约6周：
① 在网上搜索渗透实战案例，深入了解SQL注入、文件上传、解析漏洞等在实战中的使用。
② 自己搭建漏洞环境测试，推荐DWVA，SQLi-labs，Upload-labs，bWAPP。
③ 懂得渗透测试的阶段，每一个阶段需要做那些动作：例如PTES渗透测试执行标准。
④ 深入研究手工SQL注入，寻找绕过waf的方法，制作自己的脚本。
⑤ 研究文件上传的原理，如何进行截断、双重后缀欺骗(IIS、PHP)、解析漏洞利用（IIS、Nignix、Apache）等，参照：上传攻击框架。
⑥ 了解XSS形成原理和种类，在DWVA中进行实践，使用一个含有XSS漏洞的cms，安装安全狗等进行测试。
⑦ 了解一句话木马，并尝试编写过狗一句话。
⑧ 研究在Windows和Linux下的提升权限，Google关键词：提权
以上就是入门阶段
第三阶段：进阶
已经入门并且找到工作之后又该怎么进阶？详情看下图
给新手小白的入门建议：
新手入门学习最好还是从视频入手进行学习，视频的浅显易懂相比起晦涩的文字而言更容易吸收，这里我给大家准备了一套网络安全从入门到精通的视频学习资料包免费领取哦！
如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！
扫一扫
2838
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
