WEB漏洞——CSRF

已于 2024-04-23 20:19:38 修改
阅读量785 收藏 11
点赞数 24
分类专栏： WEB漏洞说明 文章标签： 前端 csrf 网络
于 2024-04-11 13:45:00 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/qq_63594215/article/details/137228099
版权

文章目录

前言

这次我来讲讲web漏洞的CSRF笔记总结，主要通过原理、类型、示例以及防御的角度展开说明，希望读者受益。

一、cookie和session

同源策略

在这里插入图片描述

什么是同源策略?

1995年，同源政策有Netscape公司引入浏览器。目前，所有浏览器都实行这个策略。最初，它的含义是指，A网页设置的Cookie，B网页不能打开，除非这两个网页“同源”。所谓“同源”指的是“三个相同”。

1、协议相同
2、域名相同
3、端口相同

在这里插入图片描述

同源策略的目的

同源策略是浏览器最核心也是最基本的安全功能，现在所有支持JavaScript的浏览器都会使用这个策略。如果缺少了同源策略，浏览器很容易受到CSRF和XSS等攻击。

同源策略的目的wield保证用户信息的安全，防止恶意的网站窃取数据。

同源策略是非常重要的。否则网站站长、广告联盟、流量统计商、xss黑客，随便哪个人都将无障碍的获取私密信息，例如各个网站的Cookie、email的邮件内容、OA页面的内容、QQ空间里设置为隐私的照片等。

在这里插入图片描述

带www和不带www

申请的域名就是xyz.com,这里要划重点了，这是不带www的域名，是绝对的大boss，是一级域名；

而www.xyz.com、wap.xyz.com、moble.xyz.com等等其实都是二级域名，跟xyz.com还真不是一个级别的。但是这里www.xyz.com却即为特殊，在相当一段时间里，哪怕是现在，很多人仍然把带www的域名作为正统嫡传

大家都遵从了这个约定俗成的结果，把这两个域名都映射到同一个服务器的同一个网站上。于是乎，不管你输入哪一个格式的网站，都是访问同一个网站。

二、CSRF原理

什么是CSRF？

在这里插入图片描述

CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者Session Riding,通常缩写为CSRF，是一种对网站的恶意利用。CSRF是通过伪装用户的请求来利用网站，利用网站漏洞从用户那里盗取信息

说白了，就是攻击者盗用了你的身份，以你的名义发送恶意请求
在这里插入图片描述
CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型的BL0G网站），YouTube和百度Hi…而现在，互联网上的许多站点仍对此毫无防备，以至于安全业界称CSRF为“沉睡的巨人”。

CSRF能做什么?

你可以这么理解


以受害者名义发送邮件，发消息，盗取受害者的账号，甚至购买商品，虚拟获取转账，修改受害者的网络配置（比如修改路由器DNS、重置路由器密码）造成的问题包括个人隐私泄露、机密资料泄露、用户甚至企业的财产安全；

也可以这么理解


盗用受害者身份，受害者能做什么，攻击者就能以受害者的身份做什么。

攻击原理

在这里插入图片描述

CSRF攻击就是利用网站丢用户网页浏览器的信任，挟持用户当前已经登录的Web应用程序，去执行并非用户本意的操作。

在浏览器中cookie在一段时间内会不会过期（不关闭或者退出浏览器），再次访问都会默认登录，这个应该都有体验。如果在cookie存在期间，通过构造csrf脚本或包含csrf脚本的链接发送给用户，得到信息后，再伪造成用户身份，执行相关操作
在这里插入图片描述
要完成一次CSRF攻击，受害者必须依次完成两个步骤：

  1. 登录受信任网站A，并在本地生成Cookie
  2. 在不登出A的情况下，访问危险网站B。
    如果不满足以上两个条件中的一个，不会受到CSRF的攻击。

CSRF攻击是黑客借助受害者的Cookie骗取服务器的信任，但是攻击者并不能获取到Cookie，也看不到Cookie的内容

原理总结

一个CSRF漏洞攻击的实现，其需要由“三个部分”来构成

1、漏洞风险存在；
2、伪造数据操作请求的恶意链接或者页面；
3、诱使用户主动访问或登录恶意链接，触发非法操作；

在这里插入图片描述

第一部分
漏洞风险的存在
关键字：跨站请求漏洞（CSR：CrossSiteRequest）
如果需要CSRF攻击能够成功，首先就需要目标站点或系统存在一个可以进行数据修改或者新增操作，且此操作被提交到后台的过程中，其未提供任何身份识别或校验的参数。后台只要收到请求，就立即下发数据修改获取新增的操作；
以上漏洞情况的存在，出现比较多的场景有用户密码的修改、购物地址的修改或后台管理账号的新增等等操作过程中。

第二部分
漏洞利用的伪装
关键字： 伪装请求（F:forgery）
CSRF漏洞风险存在了，如果需要真正的被利用，还需要对“修改或新增”数据操作请求的伪装，此时恶意攻击者者，或者通过社工的方式诱使被攻击者在其cookie还生效的情况下点击了此请求连接，即可触发CSRF漏洞，成功修改或新增当前用户的数据信息。

第三部分
用户非本意的操作
关键字： 非本意操作
当前用户在不知情的情况下，访问了黑客恶意构造的页面或在链接，即在非本意的情况下完成黑客想完成的“非法操作”，实现了对当前用户个人信息的恶意操作。

CSRF常见场景

CSRF漏洞容易出现的地方：

  • 修改密码的地方
  • 添加用户的地方
  • 数据库备份的地方数据交易、支付等
  • 等其它一些对话框的钓鱼页面


    CSRF一般与XSS结合使用，这个时候也会称为XSRF攻击

三、CSRF类型

常见的CSRF攻击主要有两种类型，get类型和post类型。

什么是get?
向某个地方获取一些数据，这个获取的过程可以理解为一个简单的查询，专业名词叫做“幂等”。幂等也就是能够随意多次执行。


所以这种类型的请求可以被缓存，下次有同样的请求就直接从缓存，下次有同样的请求就直接从缓存读取，不用浏览器再次发送亲切感。
get请求一般是通过url，url里面拼接上参数

什么时post?
post是希望服务器做某项写操作，不幂等的。因为是设计成有影响的操作，所以它能被缓存。
POST请求一般都是表单提交，可以再body里面携带数据。

CSRF实例分析——get类型

get类型的CSRF是CSRF中最常见，危害最大，但也是最简单的一种类型了，只要一个http请求就可以了，这种类型的CSRF一般是由于程序员安全意识不强造成的。GET类型的CSRF利用非常简单，只需要一个HTTP请求，从地址栏我们可以明确看到修改密码时向服务器传递的参数列表：

http://xxx.xxx.xxx.xxx/dvwa/vulnerabilities/csrf/?password_new=123&password_co
nf=123&Change=Change#

所以，一般会这样利用：
在这里插入图片描述
然后，复制url，写个简单的html文件 test.htm

<html>
	<body>
		<a　href=http://xxx.xxx.xxx.xxx/dvwa/vulnerabilities/csrf/?password_new=123&password_conf=123&Change=Change# >0元充值</a>
	</body>
</html>

在打开DVWA的同一浏览器中打开刚才的test.html文件，点击链接后，在dvwa未退出登录的情况下，直接修改了密码，登录密码就被修改了
在这里插入图片描述
在这里插入图片描述

CSRF实例分享——实例讲解#1

用虚拟的银行转账的例子演示CSRF的攻击过程：

  • 某银行网站A，它以GET请求来完成银行转账的操作，如：http://www.mybank.com/Transfer.php？toBankld=118&money=1000（当然真实的银行网站不会这
    样做）；
  • 危险网站B，它里面有一段HTL的代码如下
    在这里插入图片描述

用户C先登录某银行网站A（A网站会在浏览器本地生成Cookie）;
用户C不关闭A，新开一个浏览器标签页紧接着再访问危险网站B（网站B中加载的图片会向网站A发送一个转账请求，这个给请求带着银行网站A的Cookie）;
用户C的1000元钱再C不知情的情况下别转到了黑客的账号中。

CSRF实例分享——实例讲解#2

为了防范这种问题的发生，银行绝对使用POST请求来完成转账操作

某银行网站A将前端的转账Web表单改成如下形式：
在这里插入图片描述
某银行网站A的后端PHP实现，如下：

在这里插入图片描述

而恶意网页B，仍然只是那一条HTML代码：
带恶意标签的HTML代码：
在这里插入图片描述

重复之前的过程：

  • 先登录银行网站A;
  • 不关闭网站A，打开新的标签页访问网页B；

为什么？

  • 银行后台使用了PHP的$_REQUEST去获取请求的数据；
  • 而$_REQUEST既可以获取GET请求的数据，也可以获取POST请求的数据；
  • 后台处理程序无法区分这到底是GET请求的数据还是POST请求的数据，所以用GET请求的数据发到银行网站A的后台，数据一样被视为正常的。

怎么办？

  • 在PHP中，可以使用$_GET和$_POST分别获取GET请求和POST请求的数据；
  • 经过前面的惨痛教训，某银行网站A决定把后端PHP获取数据的方式也强制改为$_POST，如下：

在这里插入图片描述

然而······
恶意网页B，也随着A的改动而改了成用POST发送数据的方式：

在这里插入图片描述

结果？
如果用户C还是按照前面的流程依次访问A和B，结果仍会是账户莫名其妙地少1000元！

CSRF实验——post类型

进入pikachu靶场post
登录信息，点击修改个人信息抓包
可以看到bp是有一个自带的csrf poc的功能的

在这里插入图片描述

点击csrf poc的功能，就会出现一个csrf的HTML 我们只需要在表单中把个人信息修改成我们想要的，然后点击右下角copy html。然后访问html页面

在这里插入图片描述

访问该表单后，个人信息就发生了变化
在这里插入图片描述

四、CSRF实例讲解

真实案例

曾经有京东商城一个csrf商家可以刷关注

在这里插入图片描述

假设假设微博网站B，B有一个“加关注”的功能，即一个用户可以关注另一个用户


在正常情况下，你登录B网站后，点击“加关注”按钮，浏览器会将上面的URL连同B网站产生的Cookie一起发送到B网站的服务器，B服务器首先通过Cookie进行用户认证，如果Cookie中的信息正确，就会进行向数据库中写入记录，http://www.bdomain.com/addfriends?uid=123 这样，你就成功关注了ID为123的用户。URL中的参数uid表示的是你要关注的用户的ID。
在这里插入图片描述

假如我是一个恶意用户，我想让更多的人关注我，而我又不想通过正常的渠道去实现，因
为毕竟正常渠道比较浪费时间，于是我便开始想歪主意，碰巧，B网站的“加关注”的实
现原理被我发现了。

首先我在我自己的网站A里发了篇文章，<img src=”http://www.bdomain.com/addfriends?uid=456″ />（456假设是我）

你打开浏览器登录了B网站，与此同时，你也打开了我的网站A，这个时候，我的网站A就发起了上面的那个到B服务器的请求，你已经登录了B网站，Cookie已经产生了，服务器就会误认为是你主动要关注我的，于是，便向数据库写入了一条记录，而你就在不知不觉中，默默无闻的关注我啦~~~

暴走漫画刷金币CSRF漏洞

在这里插入图片描述

TP-Link家用路由器CSRF导致DNS劫持

在这里插入图片描述
在这里插入图片描述

五、CSRF进阶

CSRF蠕虫

  • CSRF攻击方式的终极形式：自我复制、迅速传播；
  • 2008年百度Hi的CSRF蠕虫；
  • 漏洞出现再百度用户中心发生短消息功能中；

http://msg.baidu.com/？ct=22&cm=MailSend&tn=bmSubmit&sn=用户账号&co=消息内容

  • 只需要直到sn参数未发生消息的用户，co参数未消息内容，就可以成功发生短消息。

百度用户中心短消息功能和百度空间、百度贴吧等产品相互关联，用户可以给指定百度ID
用户发送短消息，在百度空间用互为好友的情况下，发送短消息将没有任何限制，同时由
于百度程序员在实现短消息功能时使用了$_REQUEST类变量传参，给黑客利用CSRF漏洞进行攻击提供了很大的方便。百度用户中心短消息功能的请求参数能够被完全预测

  • 如何成为蠕虫？
  • 此处配合了另外一个漏洞：（百度空间好友json数据泄露问题）
  • 百度空间的好友功能数据是实验json格式实现的，此接口没有做任何的安全限制，只需将un参数设定未任意用户账户，就可以获得指定用户的百度好友数据，如下：

在这里插入图片描述
该漏洞可以直接被Javascript劫持技术利用，获取用户的好友信息

CSRF蠕虫

  • 蠕虫思路：
  • 将上面两个漏洞结合起来：让一个百度用户查看恶意页面后，将会给他的所有好友发送一条短消息，消息中包含一张图片，图片地址再次指向CSRF漏洞利用的恶意页面，这些好友再次将同样的消息发送给他们的所有好友。
  • 蠕虫得以呈指数方式传播。

JSONP劫持

跨域资源劫持——读类型的CSRF

出现跨域的根本原因：浏览器的同源策略不允许非同源的URL直接进行资源的交互。

常见的跨域方式及劫持：

  1. HTML5的新特性postMessage()
  2. Flash
  3. Jsonp
  4. CORS

在这里插入图片描述

实现跨域数据请求，最主要的两种解决方案，分别是JSONP和CORS。

JSONP：出现的早，是前端程序员为了解决跨域问题，被迫想出来的一种临时解决方案。
CORS：出现的较晚，它是W3C标准，属于跨域Ajax请求的根本解决方案。

支持GET和POST请求，缺点是不兼容某些低版本的浏览器。

JSONP劫持介绍

1.什么是JSON?

一种轻量级的数据交换格式，完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得JSON成为理想的数据交换语言。易于人阅读和编写，同时也易于机器解析和生成，格式如下。

{"name": "John Doe", "age": 18, "address": {"country" : "china", "zip-code": "10000"}}

2.JSONP是什么？

JSONP(JSON with Padding)是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。


由于同源策略，一般来说位于http://server1.example.com的网页无法与不是http://serve1.example.com的服务器沟通，而HTML的<script>元素是一个例外。利用<script>元素的这个开放策略，网页可以得到从其它来源动态产生的JSON资料，而这种使用模式就是所谓的JSONP。用JSONP抓到的资料并不是JSON，而是任意的JavaScrtipt，用JavaScript解释器指向而不是用JSON解析器解析。

JSONP的基本原理是利用<script>标签的src属性没有跨域限制的特性来实现跨域数据访问。

假设我们在 http://169.254.200.238:8020/jsonp/index.html下向http://169.254.200.238:8080/jsonp.do发起请求，
在这里插入图片描述
此时浏览器抛出异常
在这里插入图片描述

因为两者的端口号分别未8080、8020并不同源
但是我们换一种方式请求：
在这里插入图片描述
此时同样的请求可以成功！由此，我们可以得出<scrpit>可以进行跨域请求，这是jsonp的基础

此时，浏览器会抛出语句不合法的异常
在这里插入图片描述
那是因为我们请求的数据会里面被浏览器当作javascript语句去执行（因为我们用<script>去请求数据），但是请求到数据格式并不符合其语法规范。那么如何解决这一问题呢？当然是让返回的内容符号javascript的语法规范。
所以，我们把请求的数据当作一个函数的参数，并且这个函数再客户端存在的话，那么这就行得通。
例如：请求返回的数据为在这里插入图片描述
其中{“result”:“success”} 是我们想要获取的数据，浏览器会立即执行callback这个函数，此时，我们已经定义好了函数名为callback这个函数：
在这里插入图片描述
这样就是可行的！
所以jsonp跨域请求的关键就在于：服务端要在返回的数据外层包裹一个客户端已经定义好的函数

客户端代码：
在这里插入图片描述
客户端代码中创建了一个script标签，将需要访问的资源URL传递给服务器，并指定了回调函数的名称为handleResponse。
服务器在接收到请求后，将数据装入一个函数调用中返回给客户端，函数名为handleResponse，实际上是在客户端预先定义好的回调函数。

服务端代码：
在这里插入图片描述

1、JSONP只支持GET请求，不支持POST等其它HTTP方法。
2、因为JSONP请求是通过动态创建script标签实现的，所以需要确保被请求的数据源返回的是JSONP格式的数据，而不是普通的JSON格式，否则在处理时会出现语法错误。
3、由于JSONP请求时通过script标签实现的，所以无法在请求时设置请求头（例如Content-Type），也无法获取响应头（例如Cookie）,这是JSONP与XHR等其它跨域请求方式的一个区别。
JSONP存在一定的安全风险，因为返回的数据可以被任意JavaScript代码调用和处理，可能会导致跨域脚本攻击（XSS）等安全问题。因此，在使用JSONP时需要确保请求的数据源是可信的，并且返回的数据不包含恶意代码。

挖掘及实例

JsonP劫持就是CSRF,只不过是读类型的. 同样的要点击攻击者的链接才能攻击。

挖掘方法:校验referer，如果抓取一个正常请求的数据包，如果没有Referer字段和token，那么极有可能存在CSRF漏洞。

如果有Referer字段，但是去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞

在这里插入图片描述
在这里插入图片描述
打开Dorabox靶场–构造poc–通过这个页面截获所有信息。
在这里插入图片描述
构造poc的html文件–通过这个页面截获所有信息。
在这里插入图片描述
在这里插入图片描述

CORS劫持

CORS（跨域资源共享——Cross-origin resource sharing）是H5提供的一种机制。出现CORS标准之前，我们还只能通过jsonp(jsonp跨域请求详解)的形式去向“跨源”服务器去发送XMLHttpRequest请求，这种方式吃力不讨好，在请求方与接收方都需要做处理，而且请求的方式仅仅局限于GET。所以，CORS标准必然是大势所趋，并且市场上绝大多数浏览器都已经支持CORS

在这里插入图片描述
CORS是一种浏览器机制，可以限制指定域外的资源访问。但是如果配置不当则可能遭受跨域的攻击。
并且该机制并不能用来抵御CSRF攻击。

相关的响应头

支持CORS请求的浏览器一旦发现ajax请求跨域，会对i请求做一些特殊处理，对于已经实现CORS接口的服务器，接受请求，并做出回应。

浏览器判断跨域为简单请求时候，会在Request Header中添加Origin （协议+域名+端口）字段，它表示我们的请求源，CORS服务端会将该字段作为跨源标志。

在这里插入图片描述
CORS接收到此次请求后，首先会判断Origin是否在允许源（由服务端决定）范围之内，如果验证通过，服务端在Response Header 添加 Access-Control-Allow-Origin、Access-Control-Allow-Creadentials等字段。

必须字段：
Access-Control-Allow-Origin：表示服务端允许的请求源，*标识任何外域，多个元，分隔

可选字段
Access-Control0Allow-Creadentials：表示是否允许发送Cookie。同时，ajax请求设置withCredentials = true，浏览器的cookie就能发送到服务端

浏览器收到Respnose后会判断自己的源是否存在Access-Control-Allow-Origin允许源中，如果不存在，会抛出“同源检测异常”
在这里插入图片描述

正常响应

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

挖掘技巧

对于一个CORS漏洞的挖掘，我们只需要确定两点即可确定是否存在CORS劫持漏洞

查看响应头
查看ACAO响应头是否为具体的值以及ACAC响应头是否为trur
Access-Control-Allow-Origin:http://www.xxxx.com
Access-Control-Allow-Creadentials:true

如果是则判断是否源进行限制
我们将origin修改为任意的站点，查看返回的ACAO头是否变成和我们修改成的站点一样，
如果是，则可能存在CORS劫持漏洞
它返回的头里面必须要Access-Control-Allow-Creadentials这个头，并且设置的值为true才有意义。
不然对于不需要cookie范围的CORS劫持也就没有什么意思了，不用cookie就访问的资源都是公开数据。

比如：
在这里插入图片描述
在这里插入图片描述

案例

在这里插入图片描述
在这里插入图片描述

常见错误配置

反射Origin头，直接使用请求者的origin作为ACAO的域名add_header “Access-Control-Allow-Origin” $http_origin;

Origin 校验错误

前缀匹配：例如想要允许example.com访问，但是只做了前缀匹配，导致同时信任了example.com.attact.com的访问。
后缀匹配：例如想要允许example.com访问，由于后缀匹配出错了，导致允许attackexample.com访问。
没有转义.:例如想要允许www.example.com访问，但正则匹配没有转义.，导致允许wwwaexample.com访问
包含匹配：例如想要允许example.com，但是Origin校验出错，出现与那些ample.com访问

ACAO 配置为 null，或者 *，且与 Credentials:true 共用

Dorabox靶场–构造poc的html文件
在这里插入图片描述

OAuth劫持

OAuth是一个开源授权协议，通过授权，第三方应用可以在使用用户名密码的情况下，访问用户在某个网站上的私密数据。目前微博、淘宝、微信、Twitter、Facebook等用户基数比较大的公司都在使用OAuth，从谷歌的搜索结构也可以看到OAuth的发展很快，使用的人非常多。

目前广泛使用的版本是OAuth 2.0.
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
用户在此选择是否给予客户端(微博)授权,如果授权,则客户端将会获得用户在服务端(QQ)的昵称,头像和性别资料.

点击授权之后,抓包,会获得一个URL,我们来分析一下这个URL

https://graph.qq.com/oauth2.0/show?which=Login &display=pc &client_id=101019034&response_type=code&scope=get_info,get_user_info &redirect_uri=https://passport.xxx.com/othersitebind/bind?site=qq &state=CODE-gz-1F2ukL-448SQs-VFeXcvwk6Y0I4DO43f41e &bentry=miniblog&wl=&display= client_id


客户端标识，这个参数是和客户端一一对应的,这样服务端才知道认证请求来自哪个客户端.例如”101019034”代表的就是xxx.com这个客户端


response_type
授权类型，OAuth由多种授权裂隙。此处“code”使用的是Authorization Code（授权码模式）


scope
申请的权限范围


redirect_url
重定向URL，用户给予授权后，将会携带授权码跳转到此地址


state
这个参数是用来防御CSRF的，你可以将其理解为我们常用的“token”。这里它的使用和“token”也是一样的。
每次授权请求，客户端都会生成一个state，并将其保存到cookie或session中。授权成功后，服务端原样返回state，客户端将其与cookie或session中的值进行比对。

回到授权过程，如果用户点击了QQ头像确认授权，
在这里插入图片描述
认证服务器确认用户身份后，会生成一个授权码（code）,然后将用户导向之前redirect_url指定的地址，并附带上授权码（code）和state。

state的作用已经说过是防御CSRF的，最重要的解释这个code了。

客户端收到授权码（code）后，将其发送到服务端比对（这一步在客户端后台服务器完成，对用户不可见）。
在这里插入图片描述
如果比对结构一致，那么游戏结束。
在这个请求中，比对结束后，然后跳转到了xxx.com的域。
在这里插入图片描述
从这个登录案例来看，只要攻击者拿到了code参数，那么就能劫持用户的账号。

因此，有经验的攻击者一定发现了，既然code参数会发送到redirect_url参数指定的地址，那么只要让redirect_url跳转到我们指定得到地址，那么就能窃取code。
在这里插入图片描述
看起来，redirect_url并不能任意指定，但是我们仍有办法窃取到code，请看下面的案例。

redirect_url限制不严格，可跳转到任意子域。
对回调地址验证了主域为app.com，但其子域evil.app.com可被任意用户注册使用
不能绕过redirect_url的判断规则时，我们可以使利用跨域请求从referer中偷取token。

redirect_url限制为app.com，然而app.com/article/1.html中允许用户发表文章，在文章汇中嵌入来自evil.com的外部图片。这时我们可以让redirect_url指向该文章app.com/article/1.html，当该文章被访问时，会自动获取evil.com/test.jpg。这时攻击者即可从请求头的referer拿到token。

我在*.xxx.com下面的子域插入了在线图片,图片地址填了dnslog地址. 然后修改redirect_uri为该帖子的地址

https://graph.qq.com/oauth2.0/show?which=Login&display=pc&client_id=101019034&response_ type=code&scope=get_info%2Cget_user_info&redirect_uri=http%3A%2F%2Faaa.xxx.com%2Fx xx%2Fxxx%3fothersitebind%2Fbind%3Fsite%3Dqq%26state%3DCODE-gz-1EDEl3-2aubzXfMrFwdihkKMytGcd5eddc%26bentry%3Dminiblog%26wl%3D&display=

然后把这个链接发给受害者，一旦他点击头像确认登录，携带code的请求就会被导向到攻击者引入了外部图片的页面
在这里插入图片描述
在这里插入图片描述
登录成功-页面加载了img标签后,code就会通过referer头泄露出去
黑客利用OAuth中的URL跳转漏洞，XSS漏洞后拿到access_token。通过access——token,黑客可以劫持大v用户发微博，劫持大量用户发评论、删除指定微博、刷粉、强制关注等。

六、CSRF防御

如何防御CSRF攻击，主要从服务器端和客户端的角度考虑

防御CSRF攻击：

1. 尽量使用POST，限制GET

GET接口太容易被拿来作CSRF攻击，看第一个示例就知道，只要构造一个img标签，而img标签又是不能过滤的数据。接口最好限制为POST使用，GET则无效，降低攻击风险。

当然POST并不是万无一失，攻击者只要构造了一个form表单就可以，但需要在第三方页面做，这一就增加暴露的可能性。

如果在某些情况下需要做的是“静悄悄”地提交数据，不希望页面跳转，那么就可以使用也可通过以指定form表单的target解决这个问题。

对CSRF来说，POST、GET请求是没有任何区别的，只不过POST请求方式多了些代码。

2. 加验证码（二次确认）

验证码，强制用户必须域应用进行交互，才能完成最终请求。在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
验证码被认为是对抗CSRF攻击【最简洁有效】的防御方法；

在这里插入图片描述
在调用某些功能时进行二次验证，如删除用户时，产生一个提示对话框，提示“确定删除用户吗？”。转账操作时，要求用户输入二次密码。

3.Referer Check（请求来源检查）

检查HTTP请求头部的Referer字段，该字段标明请求来源URL。直接在浏览器的地址栏中输入一个资源的URL地址，那么这种请求是不会包含Referer字段的，因为这是一个“凭空产生”的http请求，并不是从一个地方链接过去的。

在这里插入图片描述

4.Anti CSRF Token

CSRF的本质是：重要操作的所有参数都可以被攻击者猜测到。
最容易想到的，【防猜测】的措施？

加密！
host/path/zhuanzhangto=blank_id&count=1000
http://host/path/zhuanzhang?to=md5(salt+blank_id)&count=1000

注意事项

  • 真随机
  • Token泄露：直接在URL后面附带Token，可能会造成Token泄露
  • XSS攻击也可以获取到Token的值

总结

通过本篇文章，想必能知道什么是CSRF，但这理论要通过实践来操作，可以去找靶场练练手，后续也会上传相关靶场的通关步骤，请点赞关注加收藏哦~亲。

KID1412号
关注
  • 24
    点赞
  • 踩
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
web安全——CSRF攻击
Novice-XiaoSong的博客
10-22 271
CSRF CSRF(Cross—Site Request Forgery)跨站点请求伪造，主要是利用浏览器端未过期的cookie信息伪造身份通过服务器的身份验证。 防御 （1）验证 HTTP Referer 字段 （2）在请求地址中添加 token 并验证 （3）在 HTTP 头中自定义属性并验证 CSRF攻击与防御 ...
常见的Web漏洞——CSRF
江左盟的博客
01-03 1208
目录 CSRF简介 CSRF原理 CSRF攻击实例 防御措施 总结 CSRF简介 CSRF是跨站请求伪造（Cross-site request forgery）的缩写，和《三十六计》中的“借刀杀人”一样，只不过是攻击者借了受害者的“刀”将受害者“杀”了，简单来讲就是攻击者盗用受害者的身份，以受害者的身份去做自己想要的操作，如发邮件，修改密码，非法转账，获取隐私数据等。 CSRF原理...
web漏洞——CSRF攻击原理及防御
weixin_43806577的博客
08-29 720
CSRF漏洞介绍 CSRF(Cross-site request forgery，跨站请求伪造)，通常缩写为CSRF或XSRF是一种对网站的恶意利用。它利用受害者尚未失效的身份认证信息（cookie，会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向（身份认证信息所对应的）服务器发送请求，从而完成非法操作（如转账、改密等）。 CSRF属于...
Web安全漏洞——CSRF
fly_enum的博客
08-22 69
在了解 CSRF 之前我们需要科普两个前提。首先是登录权限验证的方式有很多种，目前绝大多数网站采用的还是 session 会话任务的方式。session 机制简单的来说就是服务端使用一个键值对记录登录信息，同时在 cookie 中将 session id（即刚才说的键）存储到 cookie 中。另外我们又知道浏览器中 HTTP(s) 请求是会自动帮我们把 cookie 带上传给服务端的。这样在每次请求的时候通过 cookie 获取 session id，然后通过它在服务端获取登录信息即可完成用户权限的校验。
常见web漏洞整理——csrf
wecanning的博客
06-11 104
csrf漏洞 思维导图，漏洞整理，
Web安全——CSRF
qq_44607514的博客
03-16 129
Web安全——CSRF
Web安全——CSRF跨站请求伪造漏洞
2402_83242246的博客
04-29 748
CSRF，全称Cross-site request forgery，即跨站请求伪造，也被称为one-click attack或者XSRF，是一种攻击者利用受害者尚未失效的身份认证信息（如cookie、会话等），诱骗其点击恶意链接或者访问包含攻击代码的页面，在受害人不知情的情况下以受害者的身份向服务器发送请求，从而完成非法操作（如转账、改密等）的攻击方法。
Web安全漏洞——csrf攻击
weixin_42095265的博客
11-20 589
1.原理 CSRF（Cross Site Request Forgery），即跨站点请求伪造。CSRF是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。 跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发...
web攻防——csrf,ssrf
2303_79592445的博客
03-19 493
当我们在访问自己的管理员系统的时候，打开别人发的钓鱼连接就会自动增加管理员（前提，后台在登录状态）当我们打开别人发的网站，就会触发增加管理员的数据包假设我们要测试这个网站看到这个，就得下载一个相同的源码，在自己的服务器上搭建然后我们在自己写上信息用这个工具来抓取我们所写的数据包然后找到这个数据包然后生产html，然后放到自己的服务器，让别人在登录的状态下，访问这个网站就成功了。
WEB渗透——新手入门之初级工具利用
01-16
总之，"WEB渗透——新手入门之初级工具利用"这一主题涵盖了网络安全基础、Web应用漏洞识别和利用的一系列知识。初学者应从掌握基础工具开始，逐步深入到更复杂的渗透测试技巧，始终保持对安全的最佳实践的理解和应用...
web安全超实用超文档
01-06
下面，我们将详细探讨标签中提及的两种主要安全威胁——跨站脚本攻击（XSS）和跨站请求伪造（CSRF），以及相关的防范措施。 首先，让我们来了解一下XSS（Cross-Site Scripting）。这是一种常见的Web应用安全漏洞，...
WEB安全渗透课程ppt
01-04
【WEB安全渗透课程】是针对网络安全领域中的一个重要分支——Web应用程序的安全性进行深入探讨的教程。这门课程基于"CISP-PT"（Certified Information Security Professional - Penetration Testing）认证教材，旨在...
Web安全实验环境——WebGoat
08-22
WebGoat是一个专门为网络安全教育设计的实验环境，它是一个开源的Web应用，旨在帮助学习者理解和防御各种Web应用程序安全漏洞。这个项目由OWASP（开放网络应用安全项目）发起，是一个广泛使用的教学平台，用于教授...
Web应用安全：Cookie参数越权.pptx
06-18
在本文中，我们将深入探讨一个特定的安全威胁——Cookie参数越权，这是一种允许攻击者非法访问与他们拥有相同权限的用户资源的攻击方式。 1. **水平越权** 水平越权发生在系统没有对不同用户的数据进行细分或校验...
Node多版本管理器NVM安装使用
最新发布
GongWeiBuQi的博客
07-11 181
安装node很方便，只需要一条命令可以轻松切换node版本可以多版本node并存。
Javafx利用fxml变换场景的小细节
2301_80311013的博客
07-09 870
在这个代码中，在JavaFX中，FXMLLoader是用来加载FXML文件并将其转换为Java对象（例如控制器类）的工具。当您使用FXMLLoaderFXMLLoader在整个过程中，FXMLLoader是使用JavaFX的后台线程（也称为JavaFX线程）来执行这些操作的，这是为了保持UI线程的响应性。这意味着在用户界面（UI）线程中，您不会看到任何阻塞，即使FXMLLoader正在执行耗时的操作。当FXMLLoader完成加载并调用load()方法时，它会返回一个Parent。
vue实现预览编辑ppt、word、pdf、excel、等功能的解决方案（内网-前端）
m0_68271787的博客
07-10 760
在Vue中实现预览和编辑PPT、Word、PDF、Excel等文件的功能，尤其是在内网环境下且主要侧重于前端，我们需要明确的是，直接在前端编辑这些格式的文件（特别是PPT和Word）是非常复杂且通常不推荐的，因为这些格式涉及复杂的布局和格式设置。然而，我们可以实现预览功能，并可能通过一些间接方式支持简单的编辑（如表格数据的修改）。下面我将分别给出预览PPT、Word、PDF、Excel文件的Vue组件示例代码，并简要说明如何可能实现简单的编辑功能。
一个使用Go语言和现代Web技术构建跨平台桌面应用程序开源项目
yunmoon的博客
07-10 1028
Wails作为一个桥梁，连接强大的Go后端逻辑与丰富的Web前端界面，允许开发者利用两者的最佳特性来开发应用。
web安全常见漏洞浅析
01-08
web安全常见漏洞浅析

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值