IT面试，考到这道题，看这篇文章就够了

每次刷新闻，你是不是总能看到这样的消息：“某某账户突然被盗，几万块钱一夜之间蒸发！”、“某知名账号被黑，粉丝掉了个精光。” 我们平时在网上购物、聊天、办公，可能觉得这些事情离我们很远，但其实，网络攻击潜伏在我们每一个人的日常生活中。
今天，咱们聊聊一个很典型的例子——CSRF攻击（跨站请求伪造）。这个话题我一直想讲，因为它就像我们身边的隐形风险，可能随时让你措手不及。

说到CSRF，它其实是Web攻击中的一种，很多网站因为它而频频“翻车”。它的危害性在于，即便你乖乖登录了正规网站，如果不小心中了招，就可能在不知情的情况下被利用——比如帮别人转了账、发了消息，甚至更改了账户信息。这样的“隐形窃贼”，对我们的财产和隐私带来巨大的威胁。
那么CSRF到底是怎么工作的？在我们深入探讨之前，先来聊聊Web攻击的整体情况，再逐步揭开CSRF的真面目。毕竟，了解它、认清它，才能找到防范的好方法。
什么是 Web 攻击？

Web攻击（Web Attack）听上去很“黑客”，但其实它就像网络世界里的小偷，专门针对我们上网的行为和网站服务器发起攻击。比如，它可能会在网站上植入恶意代码，偷偷修改网站权限，甚至盗取用户的隐私信息。Web应用程序的安全性是每个在线服务的“护身符”，不容忽视。哪怕是代码中的一个小漏洞，都可能让不法分子有机可乘，导致数据泄露。
常见的Web攻击方式包括：
XSS (Cross Site Scripting)：跨站脚本攻击，允许攻击者将恶意代码注入到网页中。
CSRF (Cross-site request forgery)：跨站请求伪造，冒充用户的身份发送恶意请求。
SQL注入：通过操纵数据库查询获取敏感数据。
这些攻击手段就像网络中的“暗箭”，随时可能带来损失。因此，保护Web应用的安全，是每个网站的头等大事。

CSRF 是什么鬼？

说到 Web 攻击，我们刚才聊到了一些常见的攻击手段，比如跨站脚本（XSS）和 SQL 注入。然而，今天的主角是 CSRF（跨站请求伪造），这个“隐形小偷”有点不同。

它不会像 XSS 那样直接在你的网页上放置恶意代码，也不会像 SQL 注入那样直接操纵你的数据库。相反，它更像是网络世界里的“冒名顶替者”。利用你在登录状态下的身份信息，偷偷伪造请求，在你完全不知情的情况下帮你“做决定”。

CSRF ， 全称：Cross Site Request Forgery , 跨站请求伪造的意思。
首先将这个词拆分开来看，有2个关键意思：跨站 ， 请求伪造
跨站简单理解起来即跨域请求，一个网页加载的时候，会有诸多跨域请求，比如资源：，js，css样式等跨域的请求，再比如XmlHttpRequest的跨域请求，凡是请求不同域的资源，都是一种跨域请求，举个例子：当你浏览百度的时候，你打开开发者模式，切换到network选项框 ,

这里会看到百度会去加载一个dss0.bdstatic.com这个域下的一个js资源，这就是一个典型的跨域加载资源的请求。

CSRF 的“请求伪造”原理类似，但更具恶意。它利用你的登录状态，发起未经你同意的操作请求，比如让你的浏览器“假装”你在其他网站上进行某种操作。这些请求是伪造的，但服务器会误认为是你本人发出的，导致意外的操作发生。

CSRF 绕过与 IDOR 实现账户接管

一、CSRF 绕过攻击

CSRF 的核心是利用用户已经登录的身份信息，发起伪造请求。一般情况下，网站会通过 CSRF 令牌（Token）来防御这些伪造请求，每次请求都会附带一个唯一的 Token，如果 Token 不正确，请求就会被拒绝。
那么，如何绕过 CSRF 令牌呢？
有时候，攻击者可以通过以下几种方式尝试绕过 CSRF 令牌的验证：
删除 CSRF 令牌参数：某些网站在验证时并没有严格要求 Token 的存在，这样就有可能直接删除 Token 参数，发起请求。
伪造 Token：通过捕获合法请求中的 CSRF 令牌，重复使用或者将该 Token 注入伪造请求中。
修改请求类型：有时，将 POST 请求改为 GET，或者调整 Content-Type，都有可能绕过验证。
但这些尝试往往需要对目标站点进行细致的分析，找出验证机制的薄弱环节。
二、IDOR（不安全的直接对象引用）

IDOR（Insecure Direct Object Reference）在这个过程中起到至关重要的作用。IDOR 是一种由于缺乏对用户权限检查而导致的漏洞。例如，用户可以通过直接修改请求中的参数访问、修改他人的数据。
IDOR 的核心在于对对象的引用未加以保护。假设一个用户的请求中包含了 user_id=123 这样的参数，如果没有额外的权限校验，攻击者就可以尝试修改为 user_id=456，从而操作其他用户的账户。
CSRF + IDOR 实现账户接管

将 CSRF 和 IDOR 结合起来，就可以实现更复杂的攻击，比如账户接管。接下来，我们通过一个案例逐步讲解：
案例：通过 CSRF 绕过和 IDOR 实现账户接管

1. 分析目标网站
   假设我们发现某个网站有修改用户邮箱的功能，且这个请求包含 user_id 参数用于识别用户，并需要一个 csrf_token。

POST /update_email
Host: example.com
Content-Type: application/x-www-form-urlencoded

user_id=123&new_email=hacker@example.com&csrf_token=abc123

2. 绕过 CSRF 令牌
   攻击者首先捕获这个合法的请求，并获取其中的 csrf_token 值，然后尝试将这个 Token 植入到自己的脚本中：

Submit

3. 利用 IDOR 绕过身份验证
   在上面的表单中，攻击者将 user_id 修改为受害者的 ID（456）。由于网站缺乏对 user_id 的严格权限验证，这次伪造的请求可以通过验证，从而成功更改受害者的邮箱地址。
4. 重置密码，接管账户
   接下来，攻击者可以使用新的邮箱地址，通过网站的密码重置功能，将密码重置链接发送到自己的邮箱，从而实现对受害者账户的完全接管。
   伪代码展示
   这里我们提供一个简单的 JavaScript 代码，用于生成 CSRF 请求：
   function exploitCSRF() {
   const form = document.createElement(‘form’);
   form.action = ‘http://example.com/update_email’;
   form.method = ‘POST’; form.innerHTML = <input type="hidden" name="user_id" value="456"> <input type="hidden" name="new_email" value="hacker@example.com"> <input type="hidden" name="csrf_token" value="abc123"> ; document.body.appendChild(form);
   form.submit();
   }

只要受害者在已登录的情况下访问了攻击者控制的页面，这段脚本就会自动提交，并利用 CSRF 和 IDOR 的漏洞完成账户接管。
如何防御 CSRF？

CSRF 是一个让人防不胜防的攻击手段，但也不是无懈可击的。下面，我们来看看几种常见的防御方法，通过配合使用这些手段，可以大大降低 CSRF 风险。

1. CSRF Token 验证
   CSRF Token 是最常见的防御方式之一。服务器在生成页面时创建一个随机的 Token，并把它放入用户的表单或请求中。每次请求时，服务器会检查请求中的 Token 是否匹配。伪造请求即使带上了用户的 Cookie，也无法生成正确的 Token。
   实现方式：

Transfer

2. SameSite Cookie
   SameSite Cookie 是浏览器提供的一种防护方式。通过在设置 Cookie 时添加 SameSite 属性，可以限制 Cookie 仅在同一站点发送。这样，即使有跨站请求，Cookie 也不会被带上。
   设置方式：
   Strict：最严格，仅允许同站点请求携带 Cookie。
   Lax：允许部分跨站请求（如 GET），适合一般应用场景。
   None：允许所有跨站请求，但需要使用 HTTPS。
   Set-Cookie: session_id=abc123; SameSite=Strict
3. 不使用 GET 请求进行关键操作
   CSRF 攻击中，GET 请求特别容易被利用。恶意网站可以在标签中嵌入请求，比如：
   

只要用户访问这个页面，就会在不知不觉中发送请求。因此，关键操作如转账、修改密码等，建议使用 POST 请求。POST 请求需要用户主动提交表单，减少了攻击的机会。

4. 检查 Referrer
   Referrer 字段可以验证请求来源，如果请求的来源不是信任的网站，则可以拒绝处理。虽然这种方法依赖浏览器提供的 Referrer 信息，但可以作为其他防护手段的补充。
   代码示例：
   if ($_SERVER[‘HTTP_REFERER’] !== ‘https://trustedwebsite.com’) {
   die(‘Invalid request source’);
   }
5. 双重验证
   对于高敏感操作（如转账、密码更改），可以增加额外的验证步骤，如图形验证码、短信验证等。即使攻击者绕过了 CSRF 保护，他也无法完成这些验证。
   优点：安全性高，适合高价值操作。
   缺点：会增加用户的操作步骤。
   总结

说了这么多，你会发现，CSRF 这个小“鬼”虽然看似简单，却隐藏着不少风险。虽然我们有很多防御方法，比如 CSRF Token、SameSite Cookie 等，但别忘了，网络安全从来不是一劳永逸的。今天的防御手段可能在明天就会被攻破，这场“攻防战”一直在进行。
所以说，防护措施再多，也得保持警惕。希望大家在网络世界中少踩几个坑，能在忙碌的工作中，多一份安心。毕竟，互联网时代，安全感比什么都重要。

我是你们的阿灏，一个爱折腾、爱搞副业的程序员。下次继续给大家带来更多有趣的工具和干货！我们下次见，别忘了点赞收藏哦~ 🌟