Author: rayh4c [80sec]
EMail: rayh4c#80sec.com
Site: http://www.80sec.com
Date: 2008-12-31
From: http://www.80sec.com/release/csrf-securit2.txt

0×00 说明提醒

由于CSRF攻击原理解析老版本文档中的部分内容不是很严谨，一定程度上误导了大家，这里我表示歉意。这个文档将重新从浏览器安全和cookie原理的角度对CSRF漏洞进行分析，理顺CSRF的攻击原理，修正老版本文档中的部分错误概念和思路，同时希望这次的修正可以帮助大家更深层次的研究Web安全问题。

0×01 本地cookie和内存cookie的误区

在老文档中我提出了本地COOIKIE和内存cookie两个概念，这两个概念是相对于系统和浏览器来说明的。本地cookie是浏览器保存在系统中的数据，在设置了cookie的expires参数的值也就是指定了cookie的失效时间的情况下，IE等浏览器会将cookie以文本格式保存在浏览器的临时目录里。内存cookie是当前浏览器进程保存的数据，在没有设置cookie的expires参数值的情况下，当浏览器进程结束时内存cookie也就消失了。具体参考如下cookie的标准格式：

Set-Cookie: ＜name＞=＜value＞[; ＜name＞=＜value＞] [; expires=＜date＞][; domain=＜domain_name＞] [; path=＜some_path＞][; secure][; HttpOnly]

在这里本地cookie和内存cookie的概念存在一个误区，误区存在于我们对于cookie与Web程序身份认证及会话的理解，首先我们必须明晰Session的概念，Session是由服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID为标识符来存取服务器端的Session存储空间。SessionID可以由cookie保存，用户访问网站时，SessionID将会随cookie提交到服务器端。服务器也可以通过URL重写的方式来传递SessionID的值，但是在URL中传递SessionID是存在很大的安全风险的，黑客可能获取HTTP请求的来源信息等手段直接就得到了客户端的SessionID。

其次我们应该认识到cookie和session的区别，因为这里的概念是混淆和模糊的。HTTP协议是无状态的，客户端与服务端无法长期的保存身份认证及会话状态，所以便需要cookie机制，在客户端以文件的形式保存会话状态。而session机制则是在服务器端保持状态，不需要长期保持会话状态，但是服务器端保持状态的同时在客户端也需要保存一个标识，前面我提到了使用URL传递SessionID的安全风险，所以session机制需要借助于cookie机制。原理上cookie只是做为SessionID的一个载体，我们只需要区分cookie机制和session机制即可。

最后我对老文档中关于本地cookie和内存cookie的概念做一次修正，参照上面的分析和Web标准，这两种cookie严谨的说，应该称为会话cookie和持久化cookie。下面的0×02、0×03部分我将对老文档中的浏览器的安全缺陷内容做第二次的修正。

0×02 浅析cookie的同源策略

同源策略是今年被提起比较多的一个安全概念，这个策略是浏览器的安全基础，cookie做为浏览器的一个功能，自然也考虑到了同源策略，cookie的同源策略分为两个方面，第一个方面涉及到cookie的domain和path两个值，浏览器根据这两个值判断什么样的域名和页面能够读取cookie。第二个方面是第一方cookie和第三方cookie两个概念，第一方cookie是指当前正在查看的网站的cookie,在这个情况下对同源的HTTP请求都读取cookie发送，自然没有任何限制。而第三方cookie来自当前正在查看的网站以外的网站的cookie，第三方cookie可以是会话cookie和持久化cookie，我们正在查看的网站可能包含了第三方的资源，在这种情况下浏览器会因为考虑到同源策略，而判断从当前浏览的网站对站外的请求是否允许读取第三方cookie发送。

cookie的同源策略可能比较晦涩，但是并不难理解，我们拿javascript的同源策略类比，比如AJAX不允许跨域的GET和POST请求，而正常的HTML代码中带有文件请求的标签实际上是属于GET请求，当网站嵌入了第三方的文件资源，也就产生了跨域的请求，同源策略是不可能干预这类正常的请求的，但是从安全的角度仍然有必要限制第三方cookie的存取。

0×03 浏览器的差异和安全缺陷

不同浏览器对于安全的考虑也是不同的，当前的主流浏览器就有很大的区别，Internet Explorer默认设置阻止第三方cookie的读取，而Firefox和Chrome默认是允许所有的cookie。这个是所有浏览器都有的功能，只是默认设置上存在差异，而这些差异才是真正导致CSRF攻击成功与否的关键。

在对第三方cookie的读取上，浏览器实际上普遍存在着一个安全缺陷，那就是浏览网页时不会拦截内存cookie，内存cookie在WEB应用上是套用的session机制，浏览器开发时并没有从Web应用的角度去考虑安全，前面我提到了第三方cookie可以是会话cookie和持久化cookie，而多数浏览器并没有把内存cookie当成一个真正意义上的cookie处理。同时内存cookie有一个特性，这个特性就是内存cookie共享机制，比如从当前浏览器进程新访问的网页或新打开的浏览器窗口都会共享内存cookie，而现在的主流浏览器都流行多标签页浏览，所以给CSRF攻击又带来了便利。

0×04 P3P头的隐患

这一部分我将对Javascript劫持技术做部分的修正，WEB2.0程序员应该熟知JSON技术，简单的想一想，如果一个JSON数据接口是放在二级域名的上，按照cookie的同源策略，跨域请求的第三方cookie是会被拦截的，WEB2.0程序员想使用JSON技术来开发一个大型的WEB应用几乎是不可能实现的，而这个时候P3P头就起了大作用，P3P头是W3C制定的一项关于cookie的标准，现在大型网站的各种WEB2.0应用几乎都使用了P3P头，服务器端只要给HTTP请求返回内容加入如下的HTTP头就能实现跨域访问cookie：

P3P: CP=”CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV”

P3P头解决了Web应用上的难题，却又给Web应用带来了新的安全隐患。浏览器读取了P3P头，就等于打开了第三方cookie的读取的开关，整站的Web应用就被笼罩在CSRF攻击的阴影下，程序员在开发时往往要多考虑一方面的安全因素，那就是站外提交，防止站外提交通常是判断HTTP头Referer，从而分辨请求是来自站内的正常请求，还是黑客在站外构造的CSRF攻击。同时又得考虑HTTP请求没有来源的特殊情况，这类情况可能是网络设备或者浏览器限制了发送HTTP头Referer，一般程序员按常理也会对没有HTTP头Referer的请求放行，这里就存在了一个巨大的风险，程序员没有考虑到FLASH的请求是不会包含HTTP头Referer的，这就是为什么在考虑了CSRF攻击防护的情况下，某些CSRF攻击还能够成功的原因。

0×05 总结和后记

应用和安全是一个矛盾体，Web安全也并不是某些人想象的那样属于奇技淫巧，更深层次的研究会发现很多简单的问题并不简单，由于这篇文档写得比较仓促，不足之处大家可以发EMAIL和我沟通。这是80SEC在2008最后一篇文档，藉此感谢所有支持80SEC的朋友，感谢80SEC团队的其他成员给我的帮助，祝大家2009年更上一层楼。

参考：

http://www.80sec.com/session-hijackin.html

http://blog.csdn.net/lake2/archive/2008/04/02/2245754.aspx

http://www.80sec.com/csrf-with-flash.html

http://www.80sec.com/csrf-securit.html

By http://www.80sec.com/

We found that there is a interesting feature in mysql database,when you are using utf8,gbk or other charsets.This feature may make your application unsecure.

Stefen Esser shows some attack manners of mysql in his paper[1], in which he issues the SQL Column Truncation vulnerability.

The application is a forum where new users can register
The administrator’s name is known e.g. ‘admin’
MySQL is used in the default mode
There is no application restriction on the length of new user names
The database column username is limited to 16 characters

Although the application restrict the length of the username, we can bypass it in the following example:


<?php
$user=$_REQUEST['user'];
mysql_connect("localhost", "root", "") or
die("Could not connect: " . mysql_error());
mysql_select_db("test");
mysql_query("SET names utf8");
$result = mysql_query("SELECT * from test_user where user='$user'");
if(trim($user)=='' or strlen($user)>20 ){
die("Input user Invalid");
}
if(@mysql_fetch_array($result, MYSQL_NUM)) {
die("already exist");
}
else {
$sql="insert test_user values ('$user')";
mysql_query($sql);
echo "$user register OK!";
}
mysql_free_result($result);
?>


Read the code here:


$result = mysql_query("SELECT * from test_user where user='$user'");


If the attacker input a username ‘admin z’, and the sql will be like this:


SELECT * FROM user WHERE username='admin z'


And the application will check the length of username with the following code:


if(trim($user)=='' or strlen($user)>20 ){
die("Input user Invalid");
}


The attack will failed because the length of the username ‘admin z’ is greater then 20.

But it will not end here, attacker can input username ‘admin0xc1zzz’, and the sql will be like this:


SELECT * FROM user WHERE username='admin0xc1zzz'


This pass the application’s logic,when the insert commond executes:


insert test_user values ('admin0xc1zzz')


because the table is created in charset utf8,the 0xc1 is not a valid utf8 character,it will be striped,also all of the next characters will be striped too.Then the attacker got a user “admin”;

As you see,when mysql works at utf8,the invalid data will be striped ,but the webapplication doesn’t know this,it works at binaray.The difference between webapplication and database make a vulnerability.

Reference:

[1] http://www.suspekt.org/2008/08/18/mysql-and-sql-column-truncation-vulnerabilities/

DeDecms官方网站：http://www.dedecms.com

有什么问题和建议欢迎与root#80sec.com联系：）

原理介绍：这种filter通过对输入的文档进行html解析，去掉不合法的标签和字符，如去掉html标签里的\0，得到一个标准的文档Dom，通过对该Dom的遍历，结合自己的策略就可以抛弃如script，link，style,Xml这种危险的标签，然后再针对标签的属性进行过滤，抛弃如On*这种属性，然后加入对src这种属性的检测，只允许特定的协议，对style属性进行检测，抛弃非法的style属性，最后补齐需要闭合的html标签，实现对整个文档的过滤。

程序优点：可以对整个文档进行非常安全的过滤，完全开源，也可以根据自己的需要进行适当的调整，来实现自己的安全需求。

程序缺点：非常严格的限制了一些标签的使用，对于整个程序的白名单和黑名单可能需要根据自己的需要进行调整，而一些调整可能带来安全问题，而且在过滤的时候并没有完全考虑字符集的因素，可能在GBK，Gb2312等字符集下绕过。

程序下载：80sec提供配置好的样例程序包（包括HTMLSax3类），Planet Chinese Security Community即使用该过滤包。

程序演示：程序测试，如果你有发现程序的问题，也请与root#80sec.com联系：）

漏洞成因：QQ Mail的Filter在解析Html标签时存在错误，构造畸形的Html标签将绕过过滤，从而在邮件正文里执行任意javascript。QQ Mail对这种类型的标签不做任何过滤，认为是无效html标识符而不做过滤，但是IE却可以正常解析该Html，所以构造如下的畸形Html邮件。

将触发Xss漏洞。

漏洞测试：发送如下Html：

漏洞状态：

80sec于 2008.8.14发现此漏洞
80sec于 2008.8.14通知官方
官方于 2008.8.26日修复[同时修复几个其他类型的XSS]

漏洞厂商：http://www.dedecms.com

漏洞来源：http://www.80sec.com/release/dedecms-sql-injection.txt

漏洞解析：在joblist.php和guestbook_admin.php等文件中对orderby参数未做过滤即带入数据库查询，造成多个注射漏洞。漏洞部分代码如下


-------------------------------------------------------
if(empty($orderby)) $orderby = 'pubdate';

$dsql->SetQuery("Select * From #@__jobs where memberID='".$cfg_ml->M_ID."' order by $orderby desc limit $start,$pagesize ");
$dsql->Execute();//orderby 带入数据库查询
……
----------------------------------------------------------


漏洞利用：80sec提供攻击测试代码如下（如果发现代码无法测试，请访问80sec官方的txt文档）：


<?
print_r('
--------------------------------------------------------------------------------
DedeCms >=5 "orderby" blind SQL injection/admin credentials disclosure exploit
BY Flyh4t
www.wolvez.org
Thx for all the members of W.S.T and my friend Oldjun
--------------------------------------------------------------------------------
');

print_r('
--------------------------------------------------------------------------------
[+]userid -> '.$admin.'
[+]pwd(md5 24位) -> '.$password.'
--------------------------------------------------------------------------------
');
function is_hash($hash)
{
if (ereg("^[a-f0-9]{24}",trim($hash))) {return true;}
else {return false;}
}
if (is_hash($password)) {echo "Exploit succeeded...";}
else {echo "Exploit failed...";}
?>


漏洞厂商：http://www.phpwind.net

漏洞来源：http://www.80sec.com/release/phpwind-admin-pass-change-vul.txt

漏洞解析：在phpwind的wap模块中的字符转码程序存在问题，细节在http://www.80sec.com/php-coder-class-security-alert.html，但是80sec发现，在phpwind的wap模块中，该编码转换类存在更为严重的问题，甚至没有任何的条件，即使安装了iconv等编码模块一样受到该漏洞的影响，几乎没有条件限制。在phpwind中，wap是默认关闭的，但是我们发现在phpwind<=5.3版本中，变量存在全局没有初始化的问题，导致远程用户可以开启该模块，从而导致一个注射安全漏洞产生。
在phpwind中的注射漏洞中，phpwind过分相信从数据库中取出的变量，从而可能可以更改一些数据处理流程，导致任意修改其他用户的密码，包括管理员，问题代码在wap_mod.php中如下：


function wap_login($username,$password){
global $db,$timestamp,$onlineip,$db_ckpath,$db_ckdomain,$db_bbsurl;

$men=$db->get_one(“SELECT m.uid,m.password,m.groupid,m.yz,md.onlineip FROM pw_members m LEFT JOIN pw_memberdata md ON md.uid=m.uid WHERE username=’$username’”);
if($men){
$e_login=explode(“|”,$men['onlineip']);
if($e_login[0]!=$onlineip.’ *’ || ($timestamp-$e_login[1])>600 || $e_login[2]>1 ){
$men_uid=$men['uid'];
$men_pwd=$men['password'];
$check_pwd=$password;
if($men['yz'] > 2){
wap_msg(‘c’);
}
if(strlen($men_pwd)==16){
$check_pwd=substr($password,8,16);/*支持 16 位 md5截取密码*/
}
if($men_pwd==$check_pwd){
if(strlen($men_pwd)==16){
$db->update(“UPDATE pw_members SET password=’$password’ WHERE uid=’$men_uid’”);
}
$L_groupid=(int)$men['groupid'];
Cookie(“ck_info”,$db_ckpath.”\t”.$db_ckdomain);
}else{
global $L_T;
$L_T=$e_login[2];
$L_T ? $L_T–:$L_T=5;
$F_login=”$onlineip *|$timestamp|$L_T”;
$db->update(“UPDATE pw_memberdata SET onlineip=’$F_login’ WHERE uid=’$men_uid’”);
wap_msg(‘login_pwd_error’);
}
}else{
global $L_T;
$L_T=600-($timestamp-$e_login[1]);
wap_msg(‘login_forbid’);
}
} else {
global $errorname;
$errorname=$username;
wap_msg(‘user_not_exists’);
}
Cookie(“winduser”,StrCode($men_uid.”\t”.PwdCode($password)));
Cookie(‘lastvisit’,”,0);
wap_msg(‘wap_login’,'index.php’);
}


甚至不用注册账户，只要精心构造username即可利用此漏洞。

漏洞利用：80sec提供exploit如下：


import urllib2,httplib,sys
httplib.HTTPConnection.debuglevel = 1
cookies = urllib2.HTTPCookieProcessor()
opener = urllib2.build_opener(cookies)
argvs=sys.argv

漏洞修复：请及时打上官方最新补丁 http://www.phpwind.net/read-htm-tid-643202.html

漏洞厂商：http://www.sablog.net

漏洞来源：http://www.80sec.com/release/sablog-sql-injection.txt

漏洞解析：在sablog的trackback.php中的转码函数


function iconv2utf($chs) {
global $encode;
if ($encode != 'utf-8') {
if (function_exists('mb_convert_encoding')) {
$chs = mb_convert_encoding($chs, 'UTF-8', $encode);
} elseif (function_exists('iconv')) {
$chs = iconv($encode, 'UTF-8', $chs);
}
}
return $chs;
}


存在问题，当$encode为GBK字符集的时候，用户提交%bf’将会被转化为一个正常的utf-8字符和一个单引号，如果数据未加处理进入数据库将导致SQL注射。

漏洞利用：80sec提供漏洞测试程序如下：


#!/usr/bin/php
<?php

漏洞状态：请等待官方补丁。

漏洞厂商：众多第三方编码转换类

漏洞解析：

编码转换类在系统存在iconv等函数的时候会选择iconv函数，但是如果系统不存在iconv或者不支持多字节编码转换的情况下，编码转换类会自己实现对编码的转换。在这里由于系统iconv在进行utf8编码转换时会严格遵守约定，对于不合法的数据将进行抛弃处理，而某些第三方编码类则会进行强行的转换，如一个非法的utf8字节如0xc15c27将被转换为0×808027或其他类似处理，这将导致其绕过程序的addslashes等安全保护，譬如恶意用户提交0xc127，经过php安全处理后将变成0xc15c27，然后经过转码后将成为0×808027，导致安全防护失败，导致安全漏洞。

漏洞证明及修复：

Phpwind官方补丁：http://www.phpwind.net/read-htm-tid-643202.html
Discuz！官方补丁：http://www.discuz.net/thread-1008182-1-1.html

80sec提醒使用编码转换类的厂商和程序及时检查自己的安全设置，可以通过对进行转码后的数据再次安全处理来修复这个问题，如果有iconv的支持则尽量使用iconv模块而不要自己实现编码。

漏洞厂商：http://www.rainbowsoft.org/

漏洞解析：在FUNCTION/c_function.asp中，程序处理UBB标签的时候存在漏洞，导致任何用户可以在目标页面内执行任意js代码，利用该代码恶意用户可以获取目标站点的所有权限。漏洞代码如下：


Function UBBCode(ByVal strContent,strType)

End If


可以看到其中的正则表达式过滤并不严格，这种循环匹配也很容易出现逻辑问题，精心构造代码即可触发跨站脚本漏洞,可以发表评论如下

上面代码将循环执行alert()，当然，你也可以引入自己的恶意js执行：）

漏洞状态：该漏洞非常危险，完全不需要任何交互行为即可完成攻击，已经通知官方，请等候官方反应.