less-32

前期判断

我给id赋值然后啥都没了。
在源码看到一条代码，注释后就能显示，但是这玩意应该不能注释，后续实验需要使用.

虽然环境出了点大问题不过看到那行代码就想到宽字节注入。

宽字节注入

虽然不能做实验但是还是能虚幻实验一下，先来说说原理吧。
因为GBK需要两个字节编码，而ascii只需要一个字节，所以叫GBK这类叫宽字节。如果两个ascii字节连着一堆，就会被误认为是一个宽字节字符。

这个实验
因为代码mysql_query("SET NAMES gbk");，会导致MYSQL部分编码更改为gbk


再看看php编码是什么，是UTF-8（在UTF-8中汉字占3到4个字节）。

php会通过这个编码生成sql语句发给MYSQL，MYSQL收到请求时候会将请求内容从character_set_client转换为character_set_connection。

然后再把character_set_connection转化为内部操作字符集，使用character_set的值把内部操作字符集转化character_set_results，然后按character_set_results编码输出。

注入点在哪里呢，在character_set_client，因为MYSQL收到php的编码sql后使用了character_set_client又进行一次编码。

举个例子来理解理解，因为为了避免用户输入一些不必要的数据，对特俗的字符加上反斜杠“\“进行转义，比如当输入英文单引号" ’ "就会被转义为 " \ ’ "。
假设我们输入英文单引号，然后被过滤转义为反斜杠加英文单引号，就会导致注入失败。如果我们输入大于127的ascii字符加上一个字符,列如%df’.

• %df‘ %df‘ ’会被转义为\',\ ascii码是 %5c

• %df%5c’ 因为两个字节中第一个字节的ascii码大于127就会和后面一个字节一起看成汉字。
  -

• 運’ 经过MYSQL的GBK编码后就变成了这样
  转义的符号“\”被“%df”带着变成了“運”，就绕过了转义。

所以这次实验应该是-1%df%27union%20select%201,user(),3--+

less-33

我的less-33标题却是less-32,不出意外还是和less-32的一样，没有反馈。


看源码能找到addslashes

和less-32同理，用宽字节注入。

less-34

这几个都有相同问题，估计还是通过宽字节注入。

less-35

看了下源码发现是数字型，转义也就成摆设了。