目录
一、基础知识
（二）CSRF 原理
二、CSRF 类型
（一）GET 类型
（二）POST 类型
三、CSRF 实例讲解
（一）真实案例
（二）进阶案例
四、CSRF 防御
（一）使用 POST，限制 GET
（二）加验证码（二次确认）
（三）Referer Check（请求来源检查）
（四）Anti CSRF Token
五、CSRF 攻击易出现的场景
金融交易类网站
社交网络平台
电子邮件服务
电商平台
一、基础知识
（一）cookie 和 session、同源策略
- 同源策略
- 定义：1995 年由 Netscape 公司引入浏览器，是指 A 网页设置的 Cookie，B 网页不能打开，除非这两个网页 “同源”，即协议相同、域名相同、端口相同。
- 目的：保证用户信息安全，防止恶意网站窃取数据。
- 示例
- 同源：
http://www.store.com与http://www.store.com/order/page2.html、http://www.store.com/order2/other.html。 - 不同源：
http://www.store.com:81/order/page.html（端口不同）、https://www.store.com/order/page.html（协议不同）、http://en.store.com/order/page.html（host 不同）。
- 同源：
- cookie 和 session
- cookie 是网站为了辨别用户身份而存储在用户本地终端上的数据。
- session 是在服务器端保存的用户会话信息，通常与 cookie 配合使用。
（二）CSRF 原理
- 定义
- CSRF（Cross - site request forgery）跨站请求伪造，也被称为 “One Click Attack” 或者 Session Riding，通常缩写为 CSRF，是一种对网站的恶意利用，通过伪装用户的请求来利用网站，利用网站漏洞从用户那里恶意盗取信息。
- 攻击过程
- 受害者登录信任网站 A，验证通过在本地生成 Cookie。
- 受害者在不登出 A 的情况下访问攻击网站 B，B 要求访问第三方站点 A 并发出一个请求。
- 浏览器带着受害者在 A 网站产生的 cookie 访问 A，A 根据用户权限处理请求，攻击者达到模拟用户操作的目的。
- 攻击原理
- 利用网站对用户网页浏览器的信任，挟持用户当前已登陆的 Web 应用程序，去执行并非用户本意的操作。
- 在 cookie 存在期间，通过构造 csrf 脚本或包含 csrf 脚本的链接发送给用户，得到信息后，再伪造成用户身份，执行相关操作。
- 构成部分
- 漏洞风险存在：目标站点或系统存在可进行数据修改或新增操作且未提供身份识别或校验参数的漏洞，如用户密码修改、购物地址修改、后台管理账户新增等场景。
- 伪装数据操作请求的恶意链接或者页面：对 “修改或新增” 数据操作请求进行伪装，通过社工等方式诱使被攻击者点击请求链接触发漏洞。
- 诱使用户主动访问或登录恶意链接，触发非法操作：用户在不知情情况下访问黑客构造的页面或链接，完成非法操作。
二、CSRF 类型
（一）GET 类型
- 特点
- 最常见、危害最大、最简单，通过 url 拼接参数，请求可被缓存，幂等（可随意多次执行）。
- 示例
- 如
http://xxx.xxx.xxx.xxx/dvwa/vulnerabilities/csrf/?password_new = 123&password_conf = 123&Change = Change#，可以通过构造一个简单的 html 文件，里面包含指向该 url 的链接，在 dvwa 未退出登录情况下，点击链接可修改密码。 - 虚拟银行转账操作，银行网站 A 以 GET 请求完成转账，危险网站 B 中有
<img src = http://www.mybank.com/Transfer.php?toBankId = 11&money = 1000>代码，用户登录 A 后访问 B，会在不知情情况下转账。
- 如
（二）POST 类型
- 特点
- 希望服务器做某项写操作，不幂等，不能被缓存，一般通过表单提交在 body 里面携带数据。
- 示例
- 银行网站 A 将前端转账 Web 表单改成
<form action = "Transfer.php" method = "POST">...</form>形式，后端通过$_POST获取数据，但如果恶意网页 B 也改成用 POST 发送数据的方式，仍可导致用户账户资金丢失。 - 在 pikachu 靶场，登录后点击修改个人信息抓包，可看到有 csrf poc 功能，通过该功能生成的表单，访问后个人信息会发生变化。
- 银行网站 A 将前端转账 Web 表单改成
三、CSRF 实例讲解
（一）真实案例
- 京东商城刷关注
- 正常情况下微博网站 B 的 “加关注” 功能，登录后点击按钮，浏览器将 URL 连同 B 网站产生的 Cookie 一起发送到服务器，服务器认证后写入记录。
- 恶意用户在自己网站 A 发文章，里面包含
<img src = "http://www.bdomain.com/addfriends?uid = 456"/>，用户登录 B 网站同时打开 A 网站，A 网站发起请求，服务器会误认为是用户主动关注，写入记录。
- 暴走漫画刷金币
- 存在
<form id = "post123" name = "post123" action = "http://baozoumanhua.com/articles/帖子ID/reward.json" method = "post">...</form>形式的代码，通过提交表单利用 CSRF 漏洞刷金币。
- 存在
- TP - Link 家用路由器 DNS 劫持
- 存在
<img srchttp:/192.168.1.1/userRpm/LanDhcpServerRpm.htmdhcperver = 1ip1 = 192.168.1.100ip = 192.168.1.1998Lease = 1208gateway = 0.0.0.08domain = 8dnsserver = 8.8.8.88dnsserver2 = 0.0.0.085ave = %B1%A3+%B4E6>/img>代码，可给路由添加攻击者指定的 dns，劫持用户网络请求。
- 存在
（二）进阶案例
- CSRF 蠕虫（百度 Hi）
- 百度用户中心发送短消息功能存在漏洞，
http://msg.baidu.com/?ct = 22&cm = MailSend&tn = bmSubmit&sn = 用户账号&co = 消息内容，可通过指定参数发送短消息。 - 百度空间好友 json 数据泄露问题，
http://frd.baid.com/=8n = 用户号cm = FriListtn = bmABCFriListcallback = gotfriends，可获取用户好友数据。 - 将两个漏洞结合，让一个百度用户查看恶意页面后给所有好友发短消息，消息中图片地址指向恶意页面，好友再发消息给他们的好友，蠕虫呈指数传播。
- 百度用户中心发送短消息功能存在漏洞，
- 跨域资源劫持
- JSONP 劫持
- JSONP 原理：是 JSON 的一种 “使用模式”，利用
<script>元素 src 属性无跨域限制特性实现跨域数据访问，基本原理是将请求的数据当作一个函数的参数，服务端在返回的数据外层包裹一个客户端已经定义好的函数。 - 示例：如在
http://169.254.200.238:8020/jsonp/index.html向http://169.254.200.238:8080/jsonp.do发起请求，通过<script type = "text/javascript" srchtp://169.254.200.238808/jsonp.do></script>可成功，挖掘 JSONP 劫持漏洞可校验 referer 等。
- JSONP 原理：是 JSON 的一种 “使用模式”，利用
- CORS 劫持
- CORS 原理：是 H5 提供的一种机制（Cross - origin resource sharing），允许 Server 放宽 SOP 获取跨域数据，比 JSONP 更灵活更安全。
- 相关响应头：浏览器判断跨域为简单请求时在 Request Header 中添加 Origin 字段，CORS 服务端根据 Origin 判断是否在允许源范围内，若验证通过在 Response Header 添加
Access-Control-Allow-Origin、Access-ControlAllow - Credentials等字段。 - 挖掘技巧：查看响应头，若
Access-Control-Allow-Origin为 * 或者 null，或对源限制判断有误，则可能存在 CORS 劫持漏洞。
- OAuth 劫持
- OAuth 原理：是一个开源授权协议，第三方应用可在不使用用户名密码情况下访问用户私密数据，如微博、淘宝等公司使用 OAuth 2.0。
- 攻击过程：攻击者可通过让 redirect_uri 跳转到指定地址窃取 code 参数，或利用跨域请求从 referer 中偷取 token，进而劫持用户账号，进行发微博、评论等操作。
- JSONP 劫持
💡小提示：
- JSON（JavaScript Object Notation）
- 是一种数据格式，用于存储和交换数据。
- 格式很简单，通常是键值对的集合。
- 数据传输时，内容就是单纯的数据，如
{"name": "John", "age": 30}。- JSONP（JSON with Padding）
- 是一种跨域数据获取的方式。
- 利用
<script>标签的跨域特性来实现。- 数据传输时，会在 JSON 数据外面包裹一个函数调用，比如
callback({"name": "John", "age": 30})，callback是提前定义好的函数。
- Access - Control - Allow - Origin
- 用于指定允许访问资源的源（origin）。
- 可以是一个具体的域名，如
https://example.com，也可以是通配符*（在某些限制场景下），来控制哪些网站可以跨域请求资源。- Access - Control - Allow - Credentials
- 主要涉及跨域请求中的凭证（如 cookies、HTTP 认证等）。
- 当设置为
true时，表示允许跨域请求携带凭证，否则浏览器会阻止跨域请求携带凭证。
四、CSRF 防御
（一）使用 POST，限制 GET
- 原因
- GET 接口太容易被拿来做 CSRF 攻击，如通过构造 img 标签就可发起攻击。
- 措施
- 接口最好限制为 POST 使用，GET 则无效，降低攻击风险。但 POST 也不是绝对安全，攻击者可构造 form 表单，但在第三方页面做增加了暴露可能性，可通过指定 form 表单的 target 解决页面不跳转问题。
（二）加验证码（二次确认）
- 作用
- 验证码强制用户必须与应用进行交互才能完成最终请求，能很好遏制 CSRF 攻击。
- 局限性
- 出于用户体验考虑，网站不能给所有操作都加上验证码，只能作为辅助手段。
（三）Referer Check（请求来源检查）
- 原理
- 检查 HTTP 请求头部的 Referer 字段，该字段标明请求来源 URL。
- 示例
- 直接在浏览器地址栏输入 URL 请求不会包含 Referer 字段，而从一个地方链接过去的请求会有该字段。
（四）Anti CSRF Token
- 原理
- CSRF 本质是重要操作的所有参数都可被攻击者猜测到，使用 Anti CSRF Token 可防止猜测。
- 注意事项
- Token 要真随机，直接在 URL 后面附带 Token 可能会造成 Token 泄露，XSS 攻击也可获取 Token 值。
五、CSRF 攻击易出现的场景
-
金融交易类网站
- 转账操作时，攻击者可构造恶意请求，若平台防御不足，可能导致用户资金被盗转。
- 账户余额查询与修改操作也易受攻击，攻击者能获取财务细节或修改相关设置，造成用户经济损失。
-
社交网络平台
- 修改个人信息，若防御欠缺，攻击者可篡改用户资料，如将联系方式改为自己的用于欺诈。
- 发布内容操作可能被利用，让用户发布恶意内容，影响用户声誉并误导他人。
-
电子邮件服务
- 攻击者可让用户不知情下发送含恶意链接等有害信息的邮件，收件人点击易受攻击。
- 还能设置自动转发规则，窃取用户私人通信内容。
-
电商平台
- 订单操作，如创建、取消、修改订单，可能被攻击导致用户账户扣款或购物损失。
- 收货地址修改功能若无有效防御，攻击者可修改地址窃取商品。
嘿，朋友们！咱今儿深入探讨了超重要的CSRF防御话题，现在来总结下哈。在网络世界里，CSRF攻击就像狡猾小怪兽，随时捣乱。咱得有办法应对，比如用POST限制GET，GET接口易被坏人用img标签破坏，咱就限制成POST，虽POST也非绝对安全，坏人能构造form表单，但可指定表单target避免跳转暴露问题，如同给家门上锁，虽不能完全挡住坏人，也能让其费些劲。
验证码也不错，能强制用户与应用互动，像小卫士确认身份，可遏制攻击，不过不能所有操作都用，只能当辅助。Referer Check通过检查请求头部Referer字段判断来源，很有意思，像侦探根据线索辨好坏。Anti CSRF Token很厉害，能防坏人猜测参数，但Token要真随机，且在URL后附带可能泄露，遇XSS攻击也可能被偷。
小伙伴们，对CSRF防御是不是更清楚啦？有独特见解或疑问，欢迎在评论区留言分享，一起讨论进步哦！😎
博主会持续更新好文章供大家参考。
祝大家心想事成，好事连双！
.°ʚ(*´꒳`*)ɞ°.
