是否可以在 Damn Vulnerable Web App 上进行 SQL 注入(高级)?

信息安全 sql注入 mysql dvwa
2021-09-02 22:27:07

我搜索了整个谷歌,看看如何绕过以下内容(它来自DVWA的高级安全性):

<?php    

if (isset($_GET['Submit'])) {

// Retrieve data

$id = $_GET['id'];
$id = stripslashes($id);
$id = mysql_real_escape_string($id);

if (is_numeric($id)){

    $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";
    $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' );

    $num = mysql_numrows($result);

    $i=0;

    while ($i < $num) {

        $first = mysql_result($result,$i,"first_name");
        $last = mysql_result($result,$i,"last_name");

        echo '<pre>';
        echo 'ID: ' . $id . '<br>First name: ' . $first . '<br>Surname: ' . $last;
        echo '</pre>';

        $i++;
    }
  }
 }
?>

有可能破解吗?

另外,我的另一个担忧是中等水平。它确实有 mysql_real_escape_string() 工作,但是当您从低级别使用相同的 SQL 注入并删除引号时,它会绕过保护。这是为什么?绕过 mysql_real_escape 字符串怎么这么容易?

中级的代码(简洁版)是这样的:

   $id = $_GET['id']; 
   $id = mysql_real_escape_string($id); 
   $getid = "SELECT first_name, last_name FROM users WHERE user_id = $id";
4个回答

“高”示例不可利用。这不是一个方法(在现代代码中,您将使用参数化而不是调用mysql_real_escape_stringstripslashes这是一个神奇的引用时代的遗迹,谢天谢地),但它被设计为不会立即受到攻击。

(无论如何都要进行 SQL 注入。由于那些可怕的 s,它容易受到导致 XSS 问题的 HTML 注入的攻击echo,但那是另一回事了。)

绕过 mysql_real_escape 字符串怎么这么容易?[在中等示例中]

因为mysql_real_escape_string被设计为在包含在 SQL 字符串文字上下文中时转义字符以确保安全。在查询的注入点中没有任何周围的单引号,您就不是在字符串文字上下文中,而是在原始 SQL 上下文中。

在这种情况下,SQL 注入是不可能的。这段代码正确地阻止了 SQLi,即使平台是旧的或配置错误的,它仍然应该不受 SQLi 的影响。

...在稍微不同的配置中,它可能容易受到攻击。

如果is_numeric()被删除,mysql_real_escape_string()被替换addslashes(),并且服务器被配置为使用 GBK 语言集,那么就有可能使用 GBK 语言编码进行多字节攻击

这里有一些有趣的事情:DVWA 中的高层并不意味着可以被利用这是 DVWA 的作者当时认为合适的概念的“正确”和安全实施。因此,您无法在高级别执行 SQL 注入是很自然的。如果你真的这样做了,你会发现一些新的东西。也许是零日。

多年来我一直在使用 DVWA,我必须通过艰苦的方式学习这一点。

在 DVWA 1.9 之前,DVWA 使用“高”作为最高安全级别,而目前,他们使用“不可能”安全级别。因此,在“高”中,可以进行任何其他 SQL 注入,例如输入:' union select user, password from users; -- . 请注意,您应该在 -- 之后有空格,否则该命令在语法上是错误的。