SQL Injection | SQL 注入 —— 加解密注入

关注这个漏洞的其他相关笔记:SQL 注入漏洞 - 学习手册-CSDN博客

0x01:加解密注入 ------ 理论篇

当我们尝试寻找 SQL 注入漏洞时,有时会发现服务器会对某些数据字段进行编码或加密处理。这看起来像是服务器在有意保护这些数据,不让它们被轻易读懂或篡改。但是,如果我们有能力修改这些加密的数据,那么这些被加密的内容实际上就可能成为我们进行 SQL 注入的新入口。

而且,这里还有一个有趣的点:很多用来保护网站免受攻击的系统(我们称之为 WAF,也就是 Web应用防火墙)其实并不能识别服务器端业务中的加密信息。这是因为 WAF 通常是第三方开发的,它并不完全了解每个网站的业务逻辑和数据加密方式。所以,当我们传递加密后的信息给服务器时,WAF 可能只会看到一串乱码,而无法判断这是否是一个危险的攻击行为。

这就意味着,如果我们能够巧妙地利用加解密注入,就有可能绕过 WAF 的防御,让 SQL 注入攻击变得更加难以防范。

所以,当我们进行 SQL 注入漏洞挖掘时,不仅要关注那些直接可见的注入点,还要留意那些可能被加密的数据字段。因为只要我们能够修改这些数据,它们就可能成为我们进行 SQL 注入的新机会。

0x02:加解密注入 ------ 实战篇

本节重点在于熟悉加解密注入的注入流程,以及注入原理。练习靶场为 Sqli-labs Less-21 Cookie Injection - Base64 Encoded - Single Quotes And Parenthesis,靶场的配套资源如下(附安装教程):

实验工具准备

0x0201:第一阶段 --- 判断注入点

进入靶场,是一个登录框,本关的名称中包含 Cookie Injection 证明注入点是在 Cookie 中。所以这里我们先开个挂,先使用一个合法的用户进行登录,等获取了 Cookie 的命名规则后再进行进一步的测试

笔者这里使用的用户名和密码是 Dumb : Dumb ,登陆后的页面如下所示:

如此,我们成功获取了目标后端所需要的 Cookie 的样式:

复制代码
 uname = RHVtYg==

从 Cookie 的样式可以看出,uname 字段的值其实是被 Base64 编码过了的,我们可以直接利用工具对其进行解码:

拓展阅读:Base64 编码

Base64 编码是一种基于 64 个可打印字符来表示二进制数据的表示方法。它主要用于在需要处理文本数据的场合(如电子邮件、URL、网页等)中嵌入二进制数据。

Base 64 的基本原理如下:

  1. 字符集: Base64 使用一个包含 64 个字符的集合,这些字符由 A-Z,a-z,0-9,+,/,以及一个填充字符 = 号组成。

  2. 编码过程:

    • 将输入的二进制数据每 3 个字节分成一组(24 位)。

    • 将这 24 位数据分成 4 个 6 位段。

    • 将每个 6 位段转换为一个在 0 到 63 之间的整数。

    • 使用 Base64 字符集中的对应字符表示每个整数。

  3. 填充: 如果输入的二进制数据长度不是 3 的倍数,那么最后会剩下一或两个字节。为了保持 Base64 编码后的数据长度为 4 的倍数,会使用 = 字符进行填充。

解码后发现,uname 字段的值,其实就是 Base64 编码后的用户名,既然如此,接下来,我们就开始尝试对 Cookie 进行加解密注入(Base64 只能算是一种编码,并不算加密,不过流程一致)。

打开浏览器的 "开发者工具",然后输入下面的内容,修改我们的 Cookie 并刷新页面,看看页面变化:

javascript 复制代码
 document.cookie='uname=' + btoa('Blue17'); // btoa() 函数用于进行 base64 编码

可以看到,服务端成功接收了我们的 Cookie,并且回显出来了。虽然没能爆出数据库,但起码证明了,上述的方法可行。

接下来,开始我们针对 Cookie 进行注入点测试,Payload 如下(每次控制台执行后,都需要刷新页面,让浏览器重新携带我们修改后的 Cookie 向服务端进行请求):

javascript 复制代码
 测试 Payload 01: document.cookie='uname=' + btoa("1'");    结果: 报错

既然能报错,就已经证明其存在 SQL 注入漏洞了。根据报错返回的信息(它直接爆出了部分的后端源码),我们可以推测其后端的 SQL 模板如下:

sql 复制代码
 select * from users where cookie=('$_COOKIE["uname"]') LIMIT 0,1;

0x0202:第二阶段 --- 加解密注入漏洞利用

加解密注入漏洞的利用流程和普通的 SQL 注入利用流程一致,只不过多了一步,需要将我们构造的 Payload 按照服务端的加密规则进行加密后再传递,仅此而已。

针对上面的 SQL 语句模板,笔者给出一个漏洞利用的示例,即,爆出服务器后端当前正在使用的数据库的名称:

javascript 复制代码
 攻击 Payload : document.cookie='uname=' + btoa("1') and updatexml(1,concat(0x7e,database(),0x7e),1)#");

至此,SQL 注入的加解密注入已讲解完毕。笔者将其归纳到了 "常见注入点" 系列,这个系列的目的就是帮助大家开阔眼界,看到那些经常容易被忽略的注入点。

相关推荐
小光学长22 分钟前
基于vue框架的电信用户业务管理系统的设计与实现8ly70(程序+源码+数据库+调试部署+开发环境)带论文文档1万字以上,文末可获取,系统界面在最后面。
数据库
程序员不想YY啊37 分钟前
MySQL元数据库完全指南:探秘数据背后的数据
数据库·mysql·oracle
数据最前线41 分钟前
Doris表设计与分区策略:让海量数据管理更高效
数据库
时光追逐者1 小时前
MongoDB从入门到实战之MongoDB快速入门(附带学习路线图)
数据库·学习·mongodb
头顶秃成一缕光1 小时前
Redis的主从模式和哨兵模式
数据库·redis·缓存
AIGC大时代1 小时前
高效使用DeepSeek对“情境+ 对象 +问题“型课题进行开题!
数据库·人工智能·算法·aigc·智能写作·deepseek
博睿谷IT99_1 小时前
数据库证书可以选OCP认证吗?
数据库·oracle·开闭原则·ocp认证
乐维_lwops1 小时前
数据库监控 | MongoDB监控全解析
数据库·mongodb·数据库监控
观无1 小时前
Redis安装及入门应用
数据库·redis·缓存
我的golang之路果然有问题2 小时前
速成GO访问sql,个人笔记
经验分享·笔记·后端·sql·golang·go·database