SQL注入防御绕过——二次编码之干掉反斜杠

SQL注入防御绕过——二次编码

01 背景知识

一、为什么要进行URL编码

通常如果一样东西需要编码,说明这样东西并不适合传输。对于URL来说,编码主要是为了避免引发歧义与混乱。
例如,URL参数字符串中使用key=value键值对这样的形式来传参,键值对之间以&符号分隔,如/?name=abc&pwd=123如果你的value字符串中包含了=或者&,那么势必会造成接收Url的服务器解析错误,因此必须将引起歧义的&和= 符号进行转义,也就是对其进行编码。
对于URL编码的深入研究可以参看下面这些内容:
为什么要进行URL编码
深入分析 web 请求响应中的编码问题

二、URL传输过程中的编码问题

HTTP请求过程经历的几个环节:
浏览器【get/post】①========>服务器②========>浏览器显示③

  • ①:浏览器会把URL经过编码后发送给服务器,不同的浏览器对URL的编码规则不同。对于GET方式提交的数据,浏览器会自动进行URL编码;对于POST方式提交的数据,其编码方式可以由开发者进行指定。
  • ②:服务器根据其自身的配置文件对URL进行解码(解码成Unicode),然后将显示内容编码。
  • ③:浏览器按照指定的编码显示该网页。
    此外,在客户端也就是浏览器上运行的前端程序也会根据Web服务的需要对要传输的数据进行一些编码操作,而在服务端除了服务器中间件会自动对URL进行解码,后端的Web程序会对前端进行编码的数据进行解码操作。

02 二次编码注入

下面这幅图片很好地解释了二次编码注入的原理(图片来源为网易Web安全工程师课程,侵删):

二次编码注入

从中我们也可以得知,二次编码注入产生的原因是:
后端程序的编码函数,如urldecode()等,与PHP本身处理编码时,两者配合失误,使得攻击者可以构造数据消灭\

看一下实例代码:

//用GET方式获取id值,并对其中的特殊字符进行转义
$id = mysql_real_escap_string($_GET[‘id‘]);
//使用urldecode()函数进行解码
$id = urldecode($id);

$sql = "SELECT * FROM usres WHERE id = ‘$id‘ LIMIT 0,1;
$result = mysql_query($sql);
$row = mysql_fetch_array($result);

上面的代码就是一个二次注入的典型场景,这时如果我们提交:
http://127.0.0.1/sql.php?id=1%2527
就可以绕过对的转义,进行SQL注入攻击。

在测试时,如果发现了页面可能存在二次编码注入漏洞,也可以使用sqlmap进行自动化攻击

//只需在注入点后键入%2527即可
python sqlmap.py -u "http://127.0.0.1/sql.php?id=1%2527"

分享一个二次编码注入的漏洞实例

原文地址:https://www.cnblogs.com/fengshui/p/9266992.html

时间: 2024-09-29 23:22:13

SQL注入防御绕过——二次编码之干掉反斜杠的相关文章

SQL注入防御绕过

一.宽字节注入1.什么是宽字节GB2312.GBK.GB18030.BIG5等这些都是常说的宽字节,实际为两字节 2.宽字节注入原理防御:将 ' 转换为 \'绕过:将 \ 消灭 mysql在使用GBK编码的时候,会认为两个字符为一个汉字\ 编码为 %5c' 编码为%27%df%5c mysql会认为是一个汉字构造:%df' %df\' %df%5c%27 其中%df%5c将成为一个汉字专为 汉字' 从而绕过了/的转义注:前一个ascii码大于128才能到汉字的范围 注入方法:在注入点后键入%df

Bypass ngx_lua_waf SQL注入防御(多姿势)

0x00 前言 ? ngx_lua_waf是一款基于ngx_lua的web应用防火墙,使用简单,高性能.轻量级.默认防御规则在wafconf目录中,摘录几条核心的SQL注入防御规则: select.+(from|limit) (?:(union(.*?)select)) (?:from\W+information_schema\W) 这边主要分享三种另类思路,Bypass ngx_lua_waf SQL注入防御. 0x01 环境搭建 github源码:https://github.com/lov

23. Bypass ngx_lua_waf SQL注入防御(多姿势)

0x00 前言 ngx_lua_waf是一款基于ngx_lua的web应用防火墙,使用简单,高性能.轻量级.默认防御规则在wafconf目录中,摘录几条核心的SQL注入防御规则: select.+(from|limit) (?:(union(.*?)select)) (?:from\W+information_schema\W) 这边主要分享三种另类思路,Bypass ngx_lua_waf SQL注入防御. 0x01 环境搭建 github源码:https://github.com/loves

看好你的门-保护数据存储区(1)-SQL注入防御

首先需要声明,本文纯属一个毫无远见和真才实学的小小开发人员的愚昧见解,仅供用于web系统安全方面的参考. 1.常用的SQL注入防御的方法 一个能连接数据库的应用. 1.对用户端输入的数据进行严格防范: 2.使用PreparedStatement执行Sql语句: 3.不仅仅要在页面层面进行验证,在服务端层面还要同步进行这些验证: 2.使用正则表达式屏蔽特殊字符 使用SQL注入攻击多在特殊字符上下手脚,如"'","*","/" ,"–&qu

SQL注入之绕过WAF和Filter

知己知彼,百战不殆 --孙子兵法 [目录] 0x0 前言 0x1 WAF的常见特征 0x2 绕过WAF的方法 0x3 SQLi Filter的实现及Evasion 0x4 延伸及测试向量示例 0x5 本文小结 0x6 参考资料 0x0 前言 网上关于绕过WAF有诸多文章,但是观察之后会发现大体上绕过WAF的方法就那八.九种,而且这些技术出来也有些日子了,继续使用这些方法是否有效有待于我们在实际中去验证.看过数篇绕过WAF的文章后,前人对技术的总结已经比较全面,但是完整的内容可能分布在各处,查阅起

SQL 注入防御方法总结

SQL 注入是一类危害极大的攻击形式.虽然危害很大,但是防御却远远没有XSS那么困难. SQL 注入可以参见:https://en.wikipedia.org/wiki/SQL_injection SQL 注入漏洞存在的原因,就是拼接 SQL 参数.也就是将用于输入的查询参数,直接拼接在 SQL 语句中,导致了SQL 注入漏洞. 1. 演示下经典的SQL注入 我们看到:select id,no from user where id=2; 如果该语句是通过sql字符串拼接得到的,比如: Strin

SQL注入学习(二)

SQL注入点判断 ?id=35 +1/-1  查看页面是否发生变化 select * from tbName where id=$id 1.?id=35'数字后面加上[' or '' or )]来判断是字符型,还是数字型,如果有报错.有回显的话,用报错注入 select * from tbName where id=35' near ''' at line 1 数字型 near ''2'' LIMIT 0,1' at line 1 字符型 2.?id=35 and 1=1 // ?id=35 a

登陆页面Sql注入(绕过)

如图,看到这道题的时候发觉之前做过一个类似的手工注入: 不过这次手注会失败,后台过滤了sql语句里的一些东西,但我们并不知道过滤了什么 到这里我就基本上没辙了,不过查询了资料以后发现sqlmap可以对登录页面进行注入(一直以为sqlmap只能对url里的对象进行注入) 参考资料:https://x.hacking8.com/post-307.html “sqlmap的爬虫会爬取自定义的深度以及寻找form表单并自动填充缺失的数据加入扫描”,换句话说sqlmap可以对登陆页面进行注入,并且它会自动

通用的关于sql注入的绕过技巧(利用mysql的特性)

1 直接上语法   2 select * from users where id=8E0union select 1,2,3,4,5,6,7,8,9,0  3 select * from users where id=8.0union select 1,2,3,4,5,6,7,8,9,0  4 select * from users where id=\Nunion select 1,2,3,4,5,6,7,8,9,0  5 因为一般waf在防御的时候会识别union等关键词的单词边界,但是这个