欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

淺談php安全性需要注意的幾點(diǎn)事項(xiàng)

 更新時(shí)間:2014年07月17日 10:49:26   投稿:hebedich  
這段時(shí)間一直在寫一個(gè)整站,前幾天才基本完成了,所以抽個(gè)時(shí)間寫了一篇對于php安全的總結(jié)。技術(shù)含量不高,過不了也沒關(guān)系,希望能一些準(zhǔn)備寫網(wǎng)站的朋友一點(diǎn)引導(dǎo)。

在放假之初,我抽時(shí)間看了《白帽子講web安全》,吳翰清基本上把web安全中所有能夠遇到的問題、解決思路歸納總結(jié)得很清晰,也是我這一次整體代碼安全性的基石。

我希望能分如下幾個(gè)方面來分享自己的經(jīng)驗(yàn)

把握整站的結(jié)構(gòu),避免泄露站點(diǎn)敏感目錄

在寫代碼之初,我也是像很多老源碼一樣,在根目錄下放上index.php、register.php、login.php,用戶點(diǎn)擊注冊頁面,就跳轉(zhuǎn)到http://localhost/register.php。并沒有太多的結(jié)構(gòu)的思想,像這樣的代碼結(jié)構(gòu),最大的問題倒不是安全性問題,而是代碼擴(kuò)展與移植問題。

在寫代碼的過程中,我們常要對代碼進(jìn)行修改,這時(shí)候如果代碼沒有統(tǒng)一的一個(gè)入口點(diǎn),我們可能要改很多地方。后來我讀了一點(diǎn)emlog的代碼,發(fā)現(xiàn)網(wǎng)站真正的前端代碼都在模板目錄里,而根目錄下就只有入口點(diǎn)文件和配置文件。這才頓悟,對整個(gè)網(wǎng)站的結(jié)構(gòu)進(jìn)行了修改。

網(wǎng)站根目錄下放上一個(gè)入口點(diǎn)文件,讓它來對整個(gè)網(wǎng)站所有頁面進(jìn)行管理,這個(gè)時(shí)候注冊頁面變成了http://localhost/?act=register,任何頁面只是act的一個(gè)參數(shù),在得到這個(gè)參數(shù)后,再用一個(gè)switch來選擇要包含的文件內(nèi)容。在這個(gè)入口點(diǎn)文件中,還可以包含一些常量的定義,比如網(wǎng)站的絕對路徑、網(wǎng)站的地址、數(shù)據(jù)庫用戶密碼。以后我們在腳本的編寫中,盡量使用絕對路徑而不要使用相對路徑(否則腳本如果改變位置,代碼也要變),而這個(gè)絕對路徑就來自入口點(diǎn)文件中的定義。

當(dāng)然,在安全性上,一個(gè)入口點(diǎn)文件也能隱藏后臺(tái)地址。像這樣的地址http://localhost/?act=xxx不會(huì)暴露后臺(tái)絕對路徑,甚至可以經(jīng)常更改,不用改變太多代碼。一個(gè)入口點(diǎn)文件也可以驗(yàn)證訪問者的身份,比如一個(gè)網(wǎng)站后臺(tái),不是管理員就不允許查看任何頁面。在入口點(diǎn)文件中就可以驗(yàn)證身份,如果沒有登錄,就輸出404頁面。

有了入口點(diǎn)文件,我就把所有非入口點(diǎn)文件前面加上了這句話:

<?php 
if(!defined('WWW_ROOT'))
 {
header("HTTP/1.1 404 Not Found");
 exit;
 } 
?>

WWW_ROOT是我在入口點(diǎn)中定義的一個(gè)常量,如果用戶是通過這個(gè)頁面的絕對路徑訪問(http://localhost/register.php),我就輸出404錯(cuò)誤;只有通過入口點(diǎn)訪問(http://localhost/?act=register),才能執(zhí)行后面的代碼。

使用預(yù)編譯語句,避免sql注入

注入是早前很大的一個(gè)問題,不過近些年因?yàn)榇蠹冶容^重視這個(gè)問題,所以慢慢變得好了很多。

吳翰清在web白帽子里說的很好,其實(shí)很多漏洞,像sql注入或xss,都是將“數(shù)據(jù)”和“代碼”沒有區(qū)分開?!按a”是程序員寫的內(nèi)容,“數(shù)據(jù)”是用戶可以改變的內(nèi)容。如果我們寫一個(gè)sql語句select * from admin where username='admin' password='xxxxx', admin和xxxxx就是數(shù)據(jù),是用戶輸入的用戶名和密碼,但如果沒有任何處理,用戶輸入的就可能是“代碼”,比如'or ''=',這樣就造成了漏洞。“代碼”是絕對不能讓用戶接觸的。

在php中,對于mysql數(shù)據(jù)庫有兩個(gè)模塊,mysql和mysqli,mysqli的意思就是mysql improve。mysql的改進(jìn)版,這個(gè)模塊中就含有“預(yù)編譯”這個(gè)概念。像上面那個(gè)sql語句,改一改:select * from admin where username='?' password='?',它就不是一個(gè)sql語句了,但是可以通過mysqli的預(yù)編譯功能先把他編譯成stmt對象,在后期用戶輸入賬號密碼后,用stmt->bind_param將用戶輸入的“數(shù)據(jù)”綁定到這兩個(gè)問號的位置。這樣,用戶輸入的內(nèi)容就只能是“數(shù)據(jù)”,而不可能變成“代碼”。

這兩個(gè)問號限定了“數(shù)據(jù)”的位置,以及sql語句的結(jié)構(gòu)。我們可以把我們所有的數(shù)據(jù)庫操作都封裝到一個(gè)類中,所有sql語句的執(zhí)行都進(jìn)行預(yù)編譯。這樣就完全避免了sql注入,這也是吳翰清最推薦的解決方案。

下面是使用mysqli的一些代碼部分(所有的判斷函數(shù)運(yùn)行成功或失敗的代碼我都省略了,但不代表不重要):

<?php
//用戶輸入的數(shù)據(jù)
$name = 'admin';
$pass = '123456';
//首先新建mysqli對象,構(gòu)造函數(shù)參數(shù)中包含了數(shù)據(jù)庫相關(guān)內(nèi)容。
$conn = new mysqli(DB_HOST, DB_USER, DB_PASS, DB_NAME, DB_PORT);
//設(shè)置sql語句默認(rèn)編碼
$this->mysqli->set_charset("utf8");
//創(chuàng)建一個(gè)使用通配符的sql語句
$sql = 'SELECT user_id FROM admin WHERE username=? AND password=?;';
//編譯該語句,得到一個(gè)stmt對象.
$stmt = $conn->prepare($sql);
/********************之后的內(nèi)容就能重復(fù)利用,不用再次編譯*************************/
//用bind_param方法綁定數(shù)據(jù)
//大家可以看出來,因?yàn)槲伊袅藘蓚€(gè)?,也就是要向其中綁定兩個(gè)數(shù)據(jù),所以第一個(gè)參數(shù)是綁定的數(shù)據(jù)的類型(s=string,i=integer),第二個(gè)以后的參數(shù)是要綁定的數(shù)據(jù)
$stmt->bind_param('ss', $name, $pass);
//調(diào)用bind_param方法綁定結(jié)果(如果只是檢查該用戶與密碼是否存在,或只是一個(gè)DML語句的時(shí)候,不用綁定結(jié)果)
//這個(gè)結(jié)果就是我select到的字段,有幾個(gè)就要綁定幾個(gè)
$stmt->bind_result($user_id);
//執(zhí)行該語句
$stmt->execute();
//得到結(jié)果
if($stmt->fetch()){
 echo '登陸成功';
 //一定要注意釋放結(jié)果資源,否則后面會(huì)出錯(cuò)
 $stmt->free_result();
 return $user_id; //返回剛才select到的內(nèi)容
}else{echo '登錄失敗';}
?>

預(yù)防XSS代碼,如果不需要使用cookie就不使用

在我的網(wǎng)站中并沒有使用cookie,更因?yàn)槲覍?quán)限限制的很死,所以對于xss來說危險(xiǎn)性比較小。

對于xss的防御,也是一個(gè)道理,處理好“代碼”和“數(shù)據(jù)”的關(guān)系。當(dāng)然,這里的代碼指的就是javascript代碼或html代碼。用戶能控制的內(nèi)容,我們一定要使用htmlspecialchars等函數(shù)來處理用戶輸入的數(shù)據(jù),并且在javascript中要謹(jǐn)慎把內(nèi)容輸出到頁面中。

限制用戶權(quán)限,預(yù)防CSRF

現(xiàn)在腳本漏洞比較火的就是越權(quán)行為,很多重要操作使用GET方式執(zhí)行,或使用POST方式執(zhí)行而沒有核實(shí)執(zhí)行者是否知情。

CSRF很多同學(xué)可能比較陌生,其實(shí)舉一個(gè)小例子就行了:

A、B都是某論壇用戶,該論壇允許用戶“贊”某篇文章,用戶點(diǎn)“贊”其實(shí)是訪問了這個(gè)頁面:http://localhost/?act=support&articleid=12。這個(gè)時(shí)候,B如果把這個(gè)URL發(fā)送給A,A在不知情的情況下打開了它,等于說給articleid=12的文章贊了一次。

所以該論壇換了種方式,通過POST方式來贊某篇文章。

<form action="http://localhost/?act=support" method="POST">
 <input type="hidden" value="12" name="articleid">
 <input type="submit" value="贊">
</form>

可以看到一個(gè)隱藏的input框里含有該文章的ID,這樣就不能通過一個(gè)URL讓A點(diǎn)擊了。但是B可以做一個(gè)“極具誘惑力”的頁面,其中某個(gè)按鈕就寫成這樣一個(gè)表單,來誘惑A點(diǎn)擊。A一點(diǎn)擊,依舊還是贊了這篇文章。

最后,該論壇只好把表單中增加了一個(gè)驗(yàn)證碼。只有A輸入驗(yàn)證碼才能點(diǎn)贊。這樣,徹底死了B的心。

但是,你見過哪個(gè)論壇點(diǎn)“贊”也要輸入驗(yàn)證碼?

所以吳翰清在白帽子里也推薦了最好的方式,就是在表單中加入一個(gè)隨機(jī)字符串token(由php生成,并保存在SESSION中),如果用戶提交的這個(gè)隨機(jī)字符串和SESSION中保存的字符串一致,才能贊。

在B不知道A的隨機(jī)字符串時(shí),就不能越權(quán)操作了。

我在網(wǎng)站中也多次使用了TOKEN,不管是GET方式還是POST方式,通常就能抵御99%的CSRF估計(jì)了。

嚴(yán)格控制上傳文件類型

上傳漏洞是很致命的漏洞,只要存在任意文件上傳漏洞,就能執(zhí)行任意代碼,拿到webshell。

我在上傳這部分,寫了一個(gè)php類,通過白名單驗(yàn)證,來控制用戶上傳惡意文件。在客戶端,我通過javascript先驗(yàn)證了用戶選擇的文件的類型,但這只是善意地提醒用戶,最終驗(yàn)證部分,還是在服務(wù)端。

白名單是必要的,你如果只允許上傳圖片,就設(shè)置成array('jpg','gif','png','bmp'),當(dāng)用戶上傳來文件后,取它的文件名的后綴,用in_array驗(yàn)證是否在白名單中。

在上傳文件數(shù)組中,會(huì)有一個(gè)MIME類型,告訴服務(wù)端上傳的文件類型是什么,但是它是不可靠的,是可以被修改的。在很多存在上傳漏洞的網(wǎng)站中,都是只驗(yàn)證了MIME類型,而沒有取文件名的后綴驗(yàn)證,導(dǎo)致上傳任意文件。

所以我們在類中完全可以忽略這個(gè)MIME類型,而只取文件名的后綴,如果在白名單中,才允許上傳。

當(dāng)然,服務(wù)器的解析漏洞也是很多上傳漏洞的突破點(diǎn),所以我們盡量把上傳的文件重命名,以“日期時(shí)間+隨機(jī)數(shù)+白名單中后綴”的方式對上傳的文件進(jìn)行重命名,避免因?yàn)榻馕雎┒炊斐扇我獯a執(zhí)行。

加密混淆javascript代碼,提高攻擊門檻

很多xss漏洞,都是黑客通過閱讀javascript代碼發(fā)現(xiàn)的,如果我們能把所有javascript代碼混淆以及加密,讓代碼就算解密后也是混亂的(比如把所有變量名替換成其MD5 hash值),提高閱讀的難度。

使用更高級的hash算法保存數(shù)據(jù)庫中重要信息

在這個(gè)硬盤容量大增的時(shí)期,很多人擁有很大的彩虹表,再加上類似于cmd5這樣的網(wǎng)站的大行其道,單純的md5已經(jīng)等同于無物,所以我們迫切的需要更高級的hash算法,來保存我們數(shù)據(jù)庫中的密碼。

所以后來出現(xiàn)了加salt的md5,比如discuz的密碼就是加了salt。其實(shí)salt就是一個(gè)密碼的“附加值”,比如A的密碼是123456,而我們設(shè)置的salt是abc,這樣保存到數(shù)據(jù)庫的可能就是md5('123456abc'),增加了破解的難度。

但是黑客只要得知了該用戶的salt也能跑md5跑出來。因?yàn)楝F(xiàn)在的計(jì)算機(jī)的計(jì)算速度已經(jīng)非??炝?,一秒可以計(jì)算10億次md5值,弱一點(diǎn)的密碼分把鐘就能跑出來。

所以后來密碼學(xué)上改進(jìn)了hash,引進(jìn)了一個(gè)概念:密鑰延伸。說簡單點(diǎn)就是增加計(jì)算hash的難度(比如把密碼用md5()函數(shù)循環(huán)計(jì)算1000次),故意減慢計(jì)算hash所用的時(shí)間,以前一秒可以計(jì)算10億次,改進(jìn)后1秒只能計(jì)算100萬次,速度慢了1000倍,這樣,所需的時(shí)間也就增加了1000倍。

那么對于我們,怎么使用一個(gè)安全的hash計(jì)算方法?大家可以翻閱emlog的源碼,可以在include目錄里面找到一個(gè)HashPaaword.php的文件,其實(shí)這就是個(gè)類,emlog用它來計(jì)算密碼的hash。

這個(gè)類有一個(gè)特點(diǎn),每次計(jì)算出的hash值都不一樣,所以黑客不能通過彩虹表等方式破解密碼,只能用這個(gè)類中一個(gè)checkpassword方法來返回用戶輸入密碼的正確性。而該函數(shù)又特意增加了計(jì)算hash的時(shí)間,所以黑客很難破解他們拿到的hash值。

在最新的php5.5中,這種hash算法成為了一個(gè)正式的函數(shù),以后就能使用該函數(shù)來hash我們的密碼了。

驗(yàn)證碼安全性

這是我剛想到的一點(diǎn),來補(bǔ)充一下。

驗(yàn)證碼通常是由php腳本生成的隨機(jī)字符串,通過GD庫的處理,制作成圖片。真正的驗(yàn)證碼字符串保存在SESSION中,然后把生成的圖片展示給用戶。用戶填寫了驗(yàn)證碼提交后,在服務(wù)端上SESSION中的驗(yàn)證碼進(jìn)行比對。

由此想到了我之前犯過的一個(gè)錯(cuò)誤。驗(yàn)證碼比對完成之后,不管是正確還是錯(cuò)誤,我都沒有清理SESSION。這樣產(chǎn)生了一個(gè)問題,一旦一個(gè)用戶第一次提交驗(yàn)證碼成功,第二次以后不再訪問生成驗(yàn)證碼的腳本,這時(shí)候SESSION中的驗(yàn)證碼并沒有更新,也沒有刪除,導(dǎo)致驗(yàn)證碼重復(fù)使用,起不到驗(yàn)證的作用。

再就說到了驗(yàn)證碼被識(shí)別的問題,wordpress包括emlog的程序我經(jīng)常會(huì)借鑒,但他們所使用的驗(yàn)證碼我卻不敢恭維。很多垃圾評論都是驗(yàn)證碼被機(jī)器識(shí)別后產(chǎn)生的,所以我后來也使用了一個(gè)復(fù)雜一點(diǎn)的驗(yàn)證碼,據(jù)說是w3c推薦使用的。

如果大家需要,可以到這里下載 http://www.dbjr.com.cn/codes/191862.html

好了,我能想到的,也是在實(shí)際運(yùn)用中用到的東西也就這么多了。這也僅僅是我自己寫代碼中積累的一些對代碼安全性的一個(gè)見解,如果大家還有更好的想法,可以和我交流。希望大家也能寫出更安全的代碼。

相關(guān)文章

最新評論