A1 代码审计之 SQL 注入

Bertha 。 2022-04-23 23:00 240阅读 0赞

## **0x00：SQL 注入危害** ##

SQL 注入不像以前那么多了，但是依然存在，原因一句话总结就是没有对用户输入进行防护，造成 SQL 解析器不能区分代码和数据。而其危害如下：  
1，敏感信息泄露，例如拖库等操作。2，数据完整性问题，SQL 注入可以对数据库进行恶意的修改、增加和删除。3，权限提升，SQL 注入问题同样可以造成提权的问题。4，获取后台的访问权限，利用 SQLMAP 甚至可以上传文件 getshell。

## **0x01：SQL 注入防护** ##

对于 SQL 注入的防护，列出以下五点，建议全部都结合应用：

1，对用户的所有输入进行 HTML 编码处理。2，运用静态分析工具，也就是代码审计。3，利用 SQL 平台提供的 API 进行参数化处理，也就是我们常说的参数化查询。4，使用存储过程，当然这个需要根据情况来定，不是说所有 SQL 都要进行预存储。5，最后一条也是我认为最重要的一条，就是向开发人员提供安全编码的实践培训。

这里需要注意的是，并不是查询不进行结果返回就不存在 SQL 注入问题，利用返回对错提示来进行 SQL 盲注的也有很多。

## **0x02：参数化查询** ##

基本我们在写测试报告时，修复建议都会写上建议参数化查询，也就做语句预处理，其可以有效的防止 SQL 解析器分不清代码和数据。而其原理可能有些人没有关注过，以 mysql 为例，mysql 在 5.1 后提供了类似于 JDBC 的预处理参数化查询功能，它会先发送一个 SQL 模板，然后再发送查询的参数，类似于填空题，不管参数怎么注入，mysql 都知道这个是变量，便不会对其进行语义解析，从而起到了防注入的效果。java 示例如下。

String query = "SELECT id,firstname,lastname FROM authors WHERE forename = ? and surname = ?";
    PreparedStatement pstmt = connection.prepareStatement(query);
    pstmt.setString(1, firstname);
    pstmt.setString(2, lastname);

JDBC 编程中，常用 Statement、PreparedStatement 和 CallableStatement 三种方式来执行查询语句，其中 Statement 用于通用查询，PreparedStatement 用于执行参数化查询，而 CallableStatement 用于存储过程。

PreparedStatement 执行语句时，参数用？来代替具体的数据，然后执行时会调用 setxxxx 方法来获取具体的数据，setxxxx 需要与语句中的位置和类型相对应，例如 1 则代表第一个问号的参数，字符就需要使用 setString，数字就需要使用 setInt 等。

## **0x03：不安全的字符串拼接** ##

有时候使用了参数化查询，但在根据条件拼接 where 查询条件等这些操作时，拼接的 SQL 语句中也可能会造成一定的风险，很多程序都会这么写，例如以下 java 示例，通过 firstname 和 lastname 来搜索的示例。

String query = "SELECT id,firstname,lastname FROM authors";
    if (firstname != NULL && firstname.length != 0){
        query += "WHERE forename = ?;"
    }
    if (lastname != NULL && lastname.length != 0){
        query += "WHERE SURNAME = ?;"
    }
    PrepartedStatement pstmt = connection.PrepareStatement(query);

以上程序虽然使用了参数化查询，但在逻辑上存在一定的问题，如果用户输入 firstname 或者 lastname 则程序正常运行没有问题，但如果用户都没有输入，那么程序就不存在 where 语句，查询的结果将会是整个表的内容，虽然算不上是 SQL 注入，但效果确实一样的。这里需要注意的是，有些后台都会有多个查询提交搜索功能，如果都不指定，默认查询所有数据，这个一般在后台来说是没问题的，管理员查询所有内容。如果是个人查询只能查询自己信息时，或者是固定的查询程序默认获取用户信息来查，然后用户抓包删除了自己的信息导致查出了所有的数据，那么就存在问题。

所以在程序方面，建议在使用参数化查询的情况下，尽量避免用字符串来构建 sql 语句，尤其是当字符串拼接涉及到 WHERE 从句的某个元素时。

但有些功能也需要用到，例如用户需要搜索一个时间段的交易，或者是根据姓名手机号来搜索等，多个查询条件这种情况，拼接 WHERE 时需要使用 if 等条件语句来写一个完善的逻辑过程，例如以下 java 示例。

String query；
    PreparedStatement pstmt；
    if( (firstname != NULL && firstname.length != 0) && lastname != NULL && lastname.length != 0){
        query = "SELECT id,firstname,lastname FROM authors WHERE forename = ? and surname = ?";
        pstmt = connection.prepareStatement(query);
        pstmt.setString(1, firstname);
        pstmt.setString(2, lastname);
    }else if(firstname != NULL && firstname.length != 0){
        query = "SELECT id,firstname,lastname FROM authors WHERE forename = ?";
        pstmt = connection.prepareStatement(query);
        pstmt.setString(1, firstname);
    }else if(lastname != NULL && lastname.length != 0){
        query = "SELECT id,firstname,lastname FROM authors WHERE surname = ?";
        pstmt = connection.prepareStatement(query);
        pstmt.setString(1, lastname);
    }else{
        throw NameNotSpecifiedException();
    }

以上程序虽然是根据多个条件来进行查询，但并没有涉及到查询条件的拼接，在审计的过程中，需要仔细考虑各种情况，避免遗漏从而造成查询出本不该查出的结果。

## **0x04：PHP SQL 注入** ##

对于 PHP 程序我们先来看一个 SQL 注入最简单的示例，代码如下：

<?php
        $username = $_GET["username"];
        $con = mysql_connect('localhost','root','root');
        mysql_select_db("test", $con);
        $sql = "SELECT * FROM users WHERE username = '".$username."'";
        $result = mysql_query($sql);
    ?>

对于现在都用框架的程序，这种写法不多见了，但底层处理还是要涉及到拼接和参数化查询的问题。PHP 也提供了防止 SQL 注入的方法，例如 addslashes() 函数、mysql\_real\_escape\_string() 函数等，需要注意的是这些函数在某些情况下也能导致 SQL 注入问题。它们会在一些符号前加上反斜杠，但仅仅只用在被引号括起来的字符串中，例如以下示例依然存在注入攻击。

$id = addslashes( $_GET['id'] );
    $query = 'SELECT * FROM users WHERE id =' . $id;

而我们在 php 中也有提供参数化查询，就是 pdo，php 的 pdo 和 java 的 prepareStatement 作用是一样的，下面是使用 php pdo 的示例。

<?php
        dbh = new PDO("mysql:host=localhost; dbname=demo", "user", "pass");
        $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false)；
        $dbh->exec("set names 'utf8'");
        $sql="select * from test where name = ? and password = ?";
        $stmt = $dbh->prepare($sql);
        $exeres = $stmt->execute(array($name, $pass));

上面的 ATTR\_EMULATE\_PREPARES 设置为 false 是关闭本地模拟，其作用在于告诉数据库我传的编码类型，以及数据库传给我时的编码类型，这里 utf8，避免使用 gbk 造成宽字节注入问题。

## **0x05：JAVA SQL 注入** ##

对于 JAVA 的 SQL 注入，这里就不举例了，上面的 1，2，3 小节就是说的 JAVA 代码，其参数化查询使用 prepareStatement，PHP 中是 PDO，.NET 是 SqlParameter，它们三个的作用是一样的，都是用来进行参数化查询，我们下面来看下. NET 的简单示例。

## **0x06：.NET SQL 注入** ##

我们先来看以下代码示例。

SqlDataAdapter thisCommand = new SqlDataAdapter(
        "SELECT * FROM users WHERE userid='" + id.Text + "'", thisConnection
    );

上面就是最简单的示例，接受参数直接拼接。而在. net 中可以使用 SqlParameter 来进行参数化查询，其示例如下。

string strSQL="SELECT * FROM [user] WHERE user_id=@id";
    SqlCommand cmd = new SqlCommand();
    cmd.CommandText = strSQL;
    cmd.Parameters.Add("@id",SqlDbType.VarChar,20).Value=Request["id"].ToString();

.net 中通过 @符来指定参数。

## **0x07：总结** ##

总的来说，造成注入原因我们很熟悉是因为直接拼接造成的。对于其修复首先建议的就是使用参数化查询，但在实际过程中，可能因为程序也可能因为开发人员本身，总会多多少少涉及到直接拼接的情况，同时也建议要严格验证输入内容的类型和大小，例如 id 查询，则建议收到参数时将其再转换为 int 型，毕竟用户的输入永远不可信。

现在开发大多用框架，审计时可能不会向我们上面的例子那样一目了然，但并不代表注入漏洞不用测试，之前碰到过很多系统，总有几个查询会使用拼接的方式，同时框架并不是就一定的安全，框架我们也可以查看版本然后搜索是否有公开的漏洞和问题，造成命令执行以及注入等，也可以自己审框架，查找 0day，总之，注入依然不可忽视。

--------------------

**                                                                          公众号推荐：aFa攻防实验室**

**分享关于信息搜集、Web安全、内网安全、代码审计、红蓝对抗、Java、Python等方面的东西。**

![20191220230427373.jpg][]

[20191220230427373.jpg]: /images/20220222/9b62de08bfb2497f8f7ae0150cb6d55e.png