DVWA CSRF：不同安全等级下的防护差异

文章状态：待复验
本文由 Lee 的 CSDN 原创学习记录迁移并重新整理。以下操作仅限自建环境、CTF 与明确授权靶场，请勿用于未授权目标。

学习目标

理解浏览器自动携带身份凭据造成的 CSRF 风险
比较无防护、来源校验和随机令牌的差异
掌握 SameSite Cookie 等纵深防御措施

实验说明

难度：入门
范围：本地或公开授权靶场
复验状态：正文已完成格式迁移，关键结论将在后续使用固定环境重新验证

原始实验记录

LOW：

先尝试change一组密码：123456

修改成功，我们观察上面的url代码

1	http://localhost/DVWA/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#

将password_new部分与password_conf部分改成我们想要的密码：4321

1	http://localhost/DVWA/vulnerabilities/csrf/?password_new=4321&password_conf=4321&Change=Change#

新建一个页面打开，发现密码修改成功

MEDIUM：

尝试同样的方法发现请求失败

并且上方跳出来这个，第一行说请求头缺失，请求头记录着

查看这一关的源码并与low的做对比，多出来的这个if判断条件应该是判断当前的访问请求是否更换页面了，如果不是，就不执行请求

用bp抓包原来的请求，可以注意到这里有一个referer

Referer:

是http请求头中的一个字段，作用是指示当前请求的网页的来源，也就是说， referer后面的内容会告诉服务器这个请求来自于哪个页面或者url

在url里面像low一样修改成我们想要的密码，新起一个页面，bp抓包，抓到这些

send to repeater，添加如下代码

1	Referer:localhost

render！修改成功！！！

HIGH：

我们刚才改的密码是1111，这一级我们要把它改成0000

先提交一个新密码hhhh，并且bp抓包，抓到这些，发现这一关有了token验证

send to intreuder，和第一关一样，先clear，再把三个参数add进去，攻击方式选择Pithchfork

然后去Payloads，在payloas setting里add进我们要修改的密码，防止token失效，我们多加几组

然后和第一关一样，递归找token，先在资源池resoource pool里设置单线程

settings里（有的版本的dp是options）

回payloads，加上

Start attack！！！！！！！！！！

关闭bp，去第一关，输入用户名和密码

登陆成功！！！！！！！！！

IMPOSSIBLE：

我们观察一下源码

CSRF Source
vulnerabilities/csrf/source/impossible.php

<?php

if( isset( $_GET[ 'Change' ] ) ) {
    // Check Anti-CSRF token
    checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

    // Get input
    $pass_curr = $_GET[ 'password_current' ];
    $pass_new  = $_GET[ 'password_new' ];
    $pass_conf = $_GET[ 'password_conf' ];

    // Sanitise current password input
    $pass_curr = stripslashes( $pass_curr );
    $pass_curr = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_curr ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
    $pass_curr = md5( $pass_curr );

    // Check that the current password is correct
    $data = $db->prepare( 'SELECT password FROM users WHERE user = (:user) AND password = (:password) LIMIT 1;' );
    $data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
    $data->bindParam( ':password', $pass_curr, PDO::PARAM_STR );
    $data->execute();

    // Do both new passwords match and does the current password match the user?
    if( ( $pass_new == $pass_conf ) && ( $data->rowCount() == 1 ) ) {
        // It does!
        $pass_new = stripslashes( $pass_new );
        $pass_new = ((isset($GLOBALS["___mysqli_ston"]) && is_object($GLOBALS["___mysqli_ston"])) ? mysqli_real_escape_string($GLOBALS["___mysqli_ston"],  $pass_new ) : ((trigger_error("[MySQLConverterToo] Fix the mysql_escape_string() call! This code does not work.", E_USER_ERROR)) ? "" : ""));
        $pass_new = md5( $pass_new );

        // Update database with new password
        $data = $db->prepare( 'UPDATE users SET password = (:password) WHERE user = (:user);' );
        $data->bindParam( ':password', $pass_new, PDO::PARAM_STR );
        $data->bindParam( ':user', dvwaCurrentUser(), PDO::PARAM_STR );
        $data->execute();

        // Feedback for the user
        echo "<pre>Password Changed.</pre>";
    }
    else {
        // Issue with passwords matching
        echo "<pre>Passwords did not match or current password incorrect.</pre>";
    }
}

// Generate Anti-CSRF token
generateSessionToken();

?>

优化地方：

使用了pdo预处理：我的理解是提前规划好了传递数据的模板，只从用户的输入中提取数据，而其输入不能当成代码处理，比如 ‘or ‘1’=1，只能被当初密码

2. checktoken

3. mysqli_real_escape_string 转义

4. 原密码验证，攻击者很难知道

5. MD5加密，好像需要彩虹表解密，还不了解

综上，无法突破

防御与复盘

对状态变更请求使用不可预测并与会话绑定的 CSRF Token。
合理设置 SameSite Cookie，并校验 Origin 或 Referer 作为辅助措施。
敏感操作增加重新认证或二次确认，且不要使用 GET 执行状态变更。

原文出处

CSDN 原创记录