Web安全之SQLInject[数据库教程]

database

SQL Inject(SQL注入)概述

     在owasp发布的top10排行榜里,注入漏洞一直是危害排名第一的漏洞,其中注入漏洞里面首当其冲的就是数据库注入漏洞。

数据库注入漏洞,主要是开发人员在构建代码时, 没有对输入边界进行安全考虑,导致攻击者可以通过合法的输入点提交一些精心构造的语句,从而欺骗后台数据库对其进行执行,导致数据库信息泄漏的一-种漏洞。

一个严重的SQL注入漏洞,可能会直接导致一家公司破产!

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

从而导致数据库受损(被脱裤、被删除、甚至整个服务器权限沦陷)。

SQL inject漏洞攻击流程

第一步:注入点探测

自动方式:通过web漏洞扫描工具,自动进行注入点发现

手动方式:手工构造sql inject测试语句进行注入点发现

第二步:信息获取

通过注入点取期望得到的数据

  1. 环境信息:    数据库类型,数据库版本、操作系统版本、用户信息等
  2. 数据库信息:   数据库名称、数据库表、表字段,字段内容(加密内容破解)

第三步:获取权限

获取操作系统权限:通过数据库执行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输入提交,可以看到用户信息都被遍历出来了

 

Web安全之SQL Inject

原文:https://www.cnblogs.com/DxyG/p/13466598.html

以上是 Web安全之SQLInject[数据库教程] 的全部内容, 来源链接: utcz.com/z/535144.html

回到顶部