Web安全之SQL Inject
SQL Inject(SQL注入)概述
在owasp发布的top10排行榜里,注入漏洞一直是危害排名第一的漏洞,其中注入漏洞里面首当其冲的就是数据库注入漏洞。
数据库注入漏洞,主要是开发人员在构建代码时, 没有对输入边界进行安全考虑,导致攻击者可以通过合法的输入点提交一些精心构造的语句,从而欺骗后台数据库对其进行执行,导致数据库信息泄漏的一-种漏洞。
一个严重的SQL注入漏洞,可能会直接导致一家公司破产!
SQL注入漏洞主要形成的原因是在数据交互中,前端的数据传入到后台处理时,没有做严格的判断,导致其传入的“数据”拼接到SQL语句中后,被当作SQL语句的一部分执行。
从而导致数据库受损(被脱裤、被删除、甚至整个服务器权限沦陷)。
SQL inject漏洞攻击流程
第一步:注入点探测
自动方式:通过web漏洞扫描工具,自动进行注入点发现
手动方式:手工构造sql inject测试语句进行注入点发现
第二步:信息获取
通过注入点取期望得到的数据
- 环境信息: 数据库类型,数据库版本、操作系统版本、用户信息等
- 数据库信息: 数据库名称、数据库表、表字段,字段内容(加密内容破解)
第三步:获取权限
获取操作系统权限:通过数据库执行shell,上传木马
SQL inject漏洞-常见注入点类型
- 数字型 user_id=$id
- 字符型 user_id='$id'
- 搜索型 text LIKE '%{$_GET[''search]}%'
数字型注入(post)演示
打开pikachu的SQL-inject中的数字型注入 ,页面中的查询,在查询相应的用户之后会返回用户名和用户邮箱
点击查询之后可以发现是以post方式提交的,并没有在url中进行传参,接着我们打开burp找到刚提交的post请求发送到Repeater
然后把id修改为我们所猜想的数据库逻辑构造出的payload id=3 or 1=1 ,点击GO,然后直接查看Render页面上面返回的结果
可以看到页面把数据库内所有的用户数据都给显示出来了,意味着id查询处是存在数字型SQL注入漏洞
通过查看后端代码,可以发现漏洞形成的原因,后端从前端获取到id赋值给$id之后没有做任何处理就直接拼接到SQL里,这样就导致了$id可以被直接控制,并且可以通过拼接构造合法的SQL语句造成信息的泄漏。
字符型注入(get)演示
打开pikachu上SQL-inject的字符型注入,输入用户名,页面会返回相应的用户id和用户邮箱
随意输入一段字符,页面会返回用户不存在,而且参数是在url里面提交的,是一个get请求
然后我们根据页面的反馈来猜想后台的执行语句来构造合法的payload,我们输入的一段字符,后台的执行语句应该是一段数据库字符查询语句
我们可以先用一个单引号闭合掉前面的单引号,然后用#符号注释掉后面的单引号,中间是一个恒成立的条件,这样我们的payload就是 lucy' or 1=1# 将这段payload输入点击提交
接着来看后端代码,与数字型大同小异,唯一区别在于$name的单引号处理
搜索型注入演示
搜索型就是用的数据库中的搜索语句来进行的查找,它会搜索所有包含你所输入部分的结果
我们可以根据数据库的搜索语句 select * from member where username like '%l%'; 来构造合法的闭合 l%' or 1=1#
接着我们用这个payload来测试SQL注入漏洞,将payload提交后可以看到页面显示出了所有的用户信息
接着查看后台代码,和之前两种类型一样,都是没做任何处理就直接拼接到了SQL中,唯一的区别是变量拼接时用了单引号百分号处理
XX型注入演示
打开xx型注入,先输入一个单引号提交,页面报错
查看源码,发现XX型在参数拼接使用了一个(),我们可以根据这一点来构造合法的闭合
我们根据猜想构造payload xxx') or 1=1# ,将payload输入提交,可以看到用户信息都被遍历出来了