【网络安全渗透测试零基础入门必知必会】之CSRF攻击的危害&分类（非常详细）零基础入门到精通，收藏这一篇就够了2

最新推荐文章于 2024-08-30 19:21:33 发布

黑客大白

最新推荐文章于 2024-08-30 19:21:33 发布

阅读量477

点赞数 24

分类专栏：程序员计算机互联网文章标签： web安全 csrf 网络

本文链接：https://blog.csdn.net/Libra1313/article/details/140258473

版权

程序员同时被 3 个专栏收录

389 篇文章 15 订阅

订阅专栏

计算机

388 篇文章 3 订阅

订阅专栏

互联网

387 篇文章 3 订阅

订阅专栏

前言

这是大白给粉丝盆友们整理的网络安全渗透测试入门阶段文件CSRF漏洞概述和原理第2篇。

本文主要讲解csrf攻击分类

喜欢的朋友们，记得给大白点赞支持和收藏一下，关注我，学习黑客技术。

CSRF攻击的危害

数据泄露：攻击者可以利用CSRF攻击窃取用户的敏感信息，如账户密码、信用卡信息等，造成用户的隐私泄露和财产损失。

非法操作：攻击者可以通过CSRF攻击对受信任的网站进行非法操作，如篡改数据、发布虚假信息等，给企业或个人带来损失。

拒绝服务：攻击者可以利用大量的伪造请求对服务器进行攻击，导致服务器瘫痪，使合法用户无法正常访问。

传播CSRF蠕虫：例如某个社交网站爆出的漏洞，让某个用户查看恶意页面后，给他所有好友发送短信，短信中又包含了这个恶意页面；好友点击的话，又会给他的好友发送短信，这样就开始了传播，受感染的人也将越来越多。

三、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中，如果使用的是 $_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防护方法

只使用JSON API

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

0****2

验证HTTP Referer字段

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

必须先登录WabA

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

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

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

0****3

在请求地址中添加takon验证

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

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