一文搞懂什么是SQL注入---SQL注入详解

嘻嘻嘻嘻嘻x

已于 2024-01-11 18:44:50 修改

阅读量413

点赞数

文章标签：网络安全系统安全 sql 数据库运维 web安全

于 2023-09-08 17:58:11 首次发布

本文链接：https://blog.csdn.net/liuhyusb/article/details/132765230

版权

一：什么是sql注入

SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，而是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至篡改数据库。

二：SQL注入攻击的总体思路

寻找到SQL注入的位置
判断服务器类型和后台数据库类型
针对不同的服务器和数据库特点进行SQL注入攻击

三：SQL注入攻击实例

String

复制代码

' "+userName+" ' and password=' "+password+" '"; --当输入了上面的用户名和密码，上面的SQL语句变成： SELECT * FROM user_table WHERE username= '’or 1 = 1 -- and password='’ """ --分析SQL语句： --条件后面username=”or 1=1 用户名等于 ” 或1=1 那么这个条件一定会成功； --然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用，这样语句永远都--能正确执行，用户轻易骗过系统，获取合法身份。 --这还是比较温柔的，如果是执行 SELECT * FROM user_table WHERE username='' ;DROP DATABASE (DB Name) --' and password='' --其后果可想而知… """

四：如何防御SQL注入

注意：但凡有SQL注入漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」的原则，纵观Web安全领域的各种攻击方式，大多数都是因为开发者违反了这个原则而导致的，所以自然能想到的，就是从变量的检测、过滤、验证下手，确保变量是开发者所预想的。

1、检查变量数据类型和格式

如果你的SQL语句是类似where id={$id}这种形式，数据库里所有的id都是数字，那么就应该在SQL被执行前，检查确保变量id是int类型；如果是接受邮箱，那就应该检查并严格确保变量一定是邮箱的格式，其他的类型比如日期、时间等也是一个道理。总结起来：只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。　　比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。

2、过滤特殊符号

对于无法确定固定格式的变量，一定要进行特殊符号过滤或转义处理。

3、绑定变量，使用预编译语句

MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法

实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构

五：什么是sql预编译

1.1：预编译语句是什么

通常我们的一条sql在db接收到最终执行完毕返回可以分为下面三个过程：

词法和语义解析优化sql语句，制定执行计划执行并返回结果我们把这种普通语句称作Immediate Statements。

但是很多情况，我们的一条sql语句可能会反复执行，或者每次执行的时候只有个别的值不同（比如query的where子句值不同，update的set子句值不同,insert的values值不同）。　　如果每次都需要经过上面的词法语义解析、语句优化、制定执行计划等，则效率就明显不行了。

所谓预编译语句就是将这类语句中的值用占位符替代，可以视为将sql语句模板化或者说参数化，一般称这类语句叫Prepared Statements或者Parameterized Statements 　　预编译语句的优势在于归纳为：一次编译、多次运行，省去了解析优化等过程；此外预编译语句能防止sql注入。　　当然就优化来说，很多时候最优的执行计划不是光靠知道sql语句的模板就能决定了，往往就是需要通过具体值来预估出成本代价。

1.2：MySQL的预编译功能

注意MySQL的老版本（4.1之前）是不支持服务端预编译的，但基于目前业界生产环境普遍情况，基本可以认为MySQL支持服务端预编译。

下面我们来看一下MySQL中预编译语句的使用。

（1）建表

首先我们有一张测试表t，结构如下所示：

sql

复制代码

mysql> show create table t\G *************************** 1. row *************************** Table: t Create Table: CREATE TABLE `t` ( `a` int(11) DEFAULT NULL, `b` varchar(20) DEFAULT NULL, UNIQUE KEY `ab` (`a`,`b`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

（2）编译

我们接下来通过 PREPARE stmt_name FROM preparable_stm的语法来预编译一条sql语句

sql

复制代码

mysql> prepare ins from 'insert into t select ?,?'; Query OK, 0 rows affected (0.00 sec) Statement prepared

（3）执行

我们通过EXECUTE stmt_name [USING @var_name [, @var_name] …]的语法来执行预编译语句

sql

复制代码

mysql> set @a=999,@b='hello'; Query OK, 0 rows affected (0.00 sec) mysql> execute ins using @a,@b; Query OK, 1 row affected (0.01 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> select * from t; +------+-------+ | a | b | +------+-------+ | 999 | hello | +------+-------+ 1 row in set (0.00 sec)

可以看到，数据已经被成功插入表中。

MySQL中的预编译语句作用域是session级，但我们可以通过max_prepared_stmt_count变量来控制全局最大的存储的预编译语句。

vbnet

复制代码

mysql> set @@global.max_prepared_stmt_count=1; Query OK, 0 rows affected (0.00 sec) mysql> prepare sel from 'select * from t'; ERROR 1461 (42000): Can't create more than max_prepared_stmt_count statements (current value: 1)

当预编译条数已经达到阈值时可以看到MySQL会报如上所示的错误。

（4）释放

如果我们想要释放一条预编译语句，则可以使用{DEALLOCATE | DROP} PREPARE stmt_name的语法进行操作:

sql

复制代码

mysql> deallocate prepare ins; Query OK, 0 rows affected (0.00 sec)