概述

SQL注入漏洞主要形成的原因是在数据交互中，前端的数据传入到后台处理时，没有做严格的判断，导致其传入的“数据”拼接到SQL语句中后，被当作SQL语句的一部分执行。

漏洞具体成因

这个具体是怎样形成的呢，我们来看一下sqli-labs靶场less-1的后端代码以及对应的前端页面


我们可以看到从url后以GET方式传入的参数被拼接到了后端的mysql查询语句当中


如果我们从浏览器传入的“参数”中带有一个单引号和--+将后面的内容注释掉，会发生什么呢-

可以看到，查询语句被正常的执行
通过以上信息我们我可以发现，这个页面关联的数据库表有id，username，password三个字段，并且前端页面右后两个字段的回显
我们可以在id处传入一个数据库中不存在的数据，并且使用union进行联合查询，这样前半段查询语句没有输出结果，union后的语句被执行就可以让我们获取到想要的信息

我们看到，这张表有三个字段，所以联合查询的语句也要有三个字段(1,database（）,3)进行一一对应
而实际应用中我们看不到后端代码，也看到不到数据库的具体信息，可以通过ordby进行判断字段数


我们可以看到，当ordby 4时，页面出现报错，说明这个数据库表有3个字段

SQL注入类型

数字型：参数两边没有单引号

而最直观的判断方式就是，参数可以进行运算

字符型：参数两边有单引号

而字符型的参数因为被视为字符串，因此无法进行运算

注入点的判断

以GET传参为例，有时我们点击网页的通常是以“?字符=参数”的形式出现，我们可以尝试更改参数的值来判断页面是否与数据库进行了交互
有时我们点击页面就会遇到这种传参方式



尝试输入一个较大的、数据库中不存在的参数，如果页面输出数据库信息的部分显示空白，基本可以确定页面与数据库进行了交互
或者尝试让页面报错，如果报错信息和数据库相关，可以确定存在SQL注入

SQL注入常用的手法

联合查询

联合查询要注意查询语句和数据库表字段数相同，可以通过ordby来判断，前面已经提到过了，这里不再赘述
然后很重要的一点就是联合查询可以跨库，跨表查询，在mysql数据库5.0.1版本开始添加了information_schema数据库，在这个数据库中存储了所有其他数据库的信息，就像目录一样

利用information_schema这个数据库，我们可以获取到许多信息,比如数据库的表名，字段名，
这条查询语句的含义是：在information_schema这个数据库的tables表中查询table_name字段，限定条件是table_schema字段内容是当前数据库名——security

information_schema数据库中的tables这张这表记录了整个数据库软件中的所有表名以及对应的数据库，也就是说在security这个数据库下有email，users，uagents，refers这四张表

查询字段名

union select 1,group_concat(column_name),3 from information_schema.columns where table_name='users' and table_schema=database()

类似查询表名的方式，information_schema数据库中的columns这张这表记录了整个数据库软件中的所有字段以及对应的数据库和表，在security这个数据库下的users表中有id，username，password三个字段

布尔盲注

&（与）运算只有当两边同时为真是，结果才为真，也就是说，只有等号右边的数字等于数据库长度，页面也会有回显，我们通过这种方式来判断数据库名的字符长度

通过ascii和subctr来判断数据库名的一个个字母，最终得到当前数据库名称

延时注入

?id=1%27%20and%20If(ascii(substr(database(),1,1))=115,sleep(5),1)--+
延时注入也叫延时盲注，判断部分和布尔盲注是一致的，对于页面没有回显信息的情况下，我们可以通过sleep函数使页面加载产生延迟来判断语句是否生效

报错注入

我们可以看到，从URL传入mysql数据库的"database()"函数并没有得到执行

而extractvalue函数会返回满足XPath表达式的第一个节点的字符串值，简单来讲就是让“database()”进入数据库后被执行并且输出到报错信息当中