不点蓝字，我们哪来故事？

什么是SQL注入？

Web应用程序在向后台数据库传递SQL语句查询时，如果攻击者可以影响该查询的能力，就会引发SQL注入！

(缺乏对用户输入数据的合法性检查，传递的参数是可控的，则可以构造不同的SQL语言，来实现对数据库的操控！)

SQL注入的产生过程

1. 开发人员在运行程序过程中，动态构造SQL语句(字符串)！

转义字符处理不当

SQL数据库会将单引号(')解析为代码与数据的分界线：

输入框输入：tony

user_id = 'tony' // 数据(参数)外面会自动加上单引号，单引号外面是运行的代码！
因此输入框只要输入(')，就能判断是不是存在SQL注入！
user_id ='''  // 会提供SQL语法错误！因为它把(')解析为字符串分隔符，相当于多出来一个('),所以报错！

构造自己的查询语句：

1' and 1='1 
相当于：user_id ='1' and 1 = '1' // SQL语句可以正常执行！(没有语法错误！)

在Oracle数据库中，还有"空格"，"||"，"，"，"."，"*/"，"""(双引号)等等具有特殊含义的转义字符，我们可以利用其特殊含义，去拼接要执行的SQL语句！

类型处理不当

加入查询的数据(参数)为数字类型，开发人员不会在数字类型外面添加单引号！

比如：

user_id = 1

攻击者在构造SQL语句的时候，没有必要使用单引号来转义查询：

user_id = 1 and 1=1

所以，攻击者常常使用1' and 1='1和1 and 1=1来判断查询的字段是数字类型还是字符类型！(具体判断，下文会提及！)

查询语句组装不当

开发人员在构造动态SQL语言中，以表名或字段名作为查询参数，这样的组装容易导致攻击者使用自己的表名和字段名来替换查询，比如GET请求查询，替换URL中的表名和字段名！

http://www.tony.com?table=users&column1=user&column2=password

导致了users表中的字段user和password的信息泄漏：

错误处理不当

开发人员将详细的错误消息显示在页面上！

攻击者可以根据错误消息来提取有用信息：

利用：

根据报错信息，不断变化order by后面的数字，来获取表中的字段数！

2. 不安全的数据库配置

保证应用程序的代码的安全是首要任务，但也不能忽略数据库本身的安全！

MySQL：使用root和anonymous用户账户！

Oracle：默认创建的数据库 - SYS，SYSYTEM，DBSNMP，OUTLN等，并且密码也默认！

SQL Server：用sa作为数据库系统管理员账户！

安装数据库服务时，允许以root，sa，SYSTEM等特权用户来执行操作，一旦数据库遭到攻击，破坏力太大！

没有对元数据的访问设置权限！(元数据指数据库系统内部包含的数据，比如数据库名，表名，列名，访问权限等信息)

寻找SQL注入点

(操纵用户数据输入并分析服务器的响应来寻找SQL注入漏洞！)

1. 源代码

2. 借助推理进行测试(可以利用BurpSuite中的重放功能，向服务器发送不同请求，根据服务器的响应来推断！)

注意：借助推理进行测试，最好发送一些意外请求，来触发服务器异常：

• 识别Web应用上的所有数据输入(如POST、GET、Cookie等！)

• 哪种类型的输入会触发异常

• 检测服务器响应中的异常

举例：

http://www.tony.com?name=tony // Get请求

确定name=tony，是select，insert，update，delete中的哪一种？

构造：('或变化不同的参数，通过不同的响应结果来判断！)

name=或name=tony'  // 不同响应，select！
name=tony或name=to' 'ny // 相同响应，很可能存在SQL注入！(两个单引号中间是空格！)

根据不用的响应异常，可以大概率推断是select，并存在注入点，这时可以拼接SQL语句来进行攻击！

3. 数据库错误

用户请求，触发数据库错误时，开发人员会根据应用编码方式的不同，作如下处理：

• SQL错误显示在页面中，对浏览器用户可见！

• SQL错误隐藏在页面源代码中，便于调试！

• 检测到错误时，跳转到另一个页面！

• 返回HTTP错误码，如500，或HTTP重定向码302

• 适当地处理错误但不显示结果，或者可能显示一个统一的错误处理页面！

4. 应用程序的响应

寻找SQL注入漏洞的过程包括识别用户数据输入、操纵发送给应用的数据以及识别服务器返回结果中的变化，但操纵参数产生的错误可能与SQL注入无关！

如：统一错误处理页面，根本觉察不了什么异样！

所以，要弄清楚该错误到底是不是由SQL注入引发的！

方法：

插入不触发应用错误的SQL代码测试！(反复训练和不断尝试的过程！)

or '1' ='1'

or '1' ='2'

HTTP代码错误

200：成功接收

500：内部服务器错误

302：当发现错误时，重定向到首页或自定义错误页面！

(意味着，我们已经以某种方式干预了应用的正常行为！)

不同大小的响应(通过BP很容易捕获到！)

注意：SQL盲注常利用这个错误！

5. SQL盲注

Web应用访问数据库，会把结果呈现给用户！

攻击者修改SQL语句，通过响应来获取数据库中的任意信息！

(需要发送多次请求，建议在BP中操作，修改参数，重放请求！）

修改参数需要注意：

id=1+1

+：在URI中时保留字，不能直接使用，需要进行URL编码！

%2B=+号的URL编码！

id=1%2B1 // 对id=1+1进行了URL编码！

确认SQL注入

构造一条有效SQL语句来确认SQL注入漏洞！

(执行的这条SQL语句，不会引发任何错误！)

区分数字还是字符串

数据库有不同的数据类型，用于不同的表示方式：

1. 数字型(不要使用单引号)

2. 字符型(需要使用单引号)

如何判断？

数字型：

1. 输入单引号(')，返回不正常！

2. 输入 and 1=1，正常返回！

3. 输入 and 1=2，不正常返回！

（具体有没有数字型注入，是否能够通过数字型注入获取有效的信息，还需要大量的测试来验证！）

字符型：

1. 输入单引号(')，返回不正常！

2. 输入 ' and '1'='1，正常返回！

3. 输入 ' and '1'='2，不正常返回！

（具体有没有字符型注入，是否能够通过数字型注入获取有效的信息，还需要大量的测试来验证！）

SQL注入方式

这里以MySQL数据库为例，至于其他数据库如Oracle，SQL Server，Access，PostgreSQL等，到时候再整理吧！

---

MySQL前置知识：

MySQL 5.0之后，MySQL默认在数据库中存放一个“information_schema”的数据库，该库中存放着这三张表：

1. SCHEMATA：存储该用户创建的所有数据库的库名，记录库名的字段为SCHEMATA_NAME。

2. TABLES：存储该用户创建的所有数据库的库名和表名，记录库名的字段为TABLE_SCHEMA，记录表名的字段为TABLE_NAME。

3. COLUMNS：存储该用户创建的所有数据库的库名、表名、字段名。记录库名的字段为TABLE_SCHEMA，记录表名的字段为TABLE_NAME，记录字段名的字段为COLUMN_NAME。

limit：
limit m,n
m：记录开始的位置，0代表第一条记录
n：取n条记录
limit 0,2：第一条记录开始，取两条记录！

常用的函数和属性：

version()：查询MySQL的版本

database()：查询数据库名

user()：查询使用MySQL的用户

@@datadir：查询数据库物理路径

@@version：查询MySQL的版本

MySQL的4种注释：

1. # 我是注释

2. -- 我是注释 (--和我是注释之间有空格)

3. /*我是注释*/

以上注释都可以放在SQL语句的任意位置中！！！

4. /*!code*/ (内联注释)

内联注释可以用于整个SQL语句中，用来执行SQL语句！

例如：userid=1/*! UNION*//*! SELELCT*/1,2,3,4

---

基本注入

1. 联合查询注入(union)

利用union可以同时执行多条SQL语句的特点，在参数中插入恶意的SQL注入语句，同时SQL语句，来获取额外敏感信息等操作！

分析：

select 1,2,3会生成一张临时表，表中的字段为查询的字段，内容也是查询的字段

select 1,2,3 union select 3,2,1，同样生成一张临时表，表中的字段为un

END

 往期推荐 

🔗