A1 代码审计之 SQL 注入

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 用于执行参数