這段時間一直在寫一個整站，前幾天才基本完成了，所以抽個時間寫了一篇對于php安全的總結。技術含量不高，過不了也沒關系，希望能一些準備寫網站的朋友一點引導。 在放假之初，我抽時間看了《白帽子講web安全》，吳翰清基本上把web安全中所有能夠遇到的問題、解決思路歸納總結得很清晰，也是我這一次整體代碼安全性的基石。 我希望能分如下幾個方面來分享自己的經驗 把握整站的結構，避免泄露站點敏感目錄 在寫代碼之初，我也是像很多老源碼一樣，在根目錄下放上index.php、register.php、login.php，用戶點擊注冊頁面，就跳轉到http://localhost/register.php。并沒有太多的結構的思想，像這樣的代碼結構，最大的問題倒不是安全性問題，而是代碼擴展與移植問題。 在寫代碼的過程中，我們常要對代碼進行修改，這時候如果代碼沒有統一的一個入口點，我們可能要改很多地方。后來我讀了一點emlog的代碼，發現網站真正的前端代碼都在模板目錄里，而根目錄下就只有入口點文件和配置文件。這才頓悟，對整個網站的結構進行了修改。 網站根目錄下放上一個入口點文件，讓它來對整個網站所有頁面進行管理，這個時候注冊頁面變成了http://localhost/?act=register，任何頁面只是act的一個參數，在得到這個參數后，再用一個switch來選擇要包含的文件內容。在這個入口點文件中，還可以包含一些常量的定義，比如網站的絕對路徑、網站的地址、數據庫用戶密碼。以后我們在腳本的編寫中，盡量使用絕對路徑而不要使用相對路徑（否則腳本如果改變位置，代碼也要變），而這個絕對路徑就來自入口點文件中的定義。 當然，在安全性上，一個入口點文件也能隱藏后臺地址。像這樣的地址http://localhost/?act=xxx不會暴露后臺絕對路徑，甚至可以經常更改，不用改變太多代碼。一個入口點文件也可以驗證訪問者的身份，比如一個網站后臺，不是管理員就不允許查看任何頁面。在入口點文件中就可以驗證身份，如果沒有登錄，就輸出404頁面。 有了入口點文件，我就把所有非入口點文件前面加上了這句話： php?if(!defined('WWW\_ROOT'))?{header("HTTP/1.1?404?Not?Found");?exit;}??> WWW\_ROOT是我在入口點中定義的一個常量，如果用戶是通過這個頁面的絕對路徑訪問（http://localhost/register.php），我就輸出404錯誤；只有通過入口點訪問（http://localhost/?act=register），才能執行后面的代碼。 使用預編譯語句，避免sql注入 注入是早前很大的一個問題，不過近些年因為大家比較重視這個問題，所以慢慢變得好了很多。 吳翰清在web白帽子里說的很好，其實很多漏洞，像sql注入或xss，都是將“數據”和“代碼”沒有區分開。“代碼”是程序員寫的內容，“數據”是用戶可以改變的內容。如果我們寫一個sql語句select \* from admin where username='admin' password='xxxxx', admin和xxxxx就是數據，是用戶輸入的用戶名和密碼，但如果沒有任何處理，用戶輸入的就可能是“代碼”，比如'or ''='，這樣就造成了漏洞。“代碼”是絕對不能讓用戶接觸的。 在php中，對于mysql數據庫有兩個模塊，mysql和mysqli，mysqli的意思就是mysql improve。mysql的改進版，這個模塊中就含有“預編譯”這個概念。像上面那個sql語句，改一改：select \* from admin where username='?' password='?'，它就不是一個sql語句了，但是可以通過mysqli的預編譯功能先把他編譯成stmt對象，在后期用戶輸入賬號密碼后，用stmt->bind\_param將用戶輸入的“數據”綁定到這兩個問號的位置。這樣，用戶輸入的內容就只能是“數據”，而不可能變成“代碼”。 這兩個問號限定了“數據”的位置，以及sql語句的結構。我們可以把我們所有的數據庫操作都封裝到一個類中，所有sql語句的執行都進行預編譯。這樣就完全避免了sql注入，這也是吳翰清最推薦的解決方案。 下面是使用mysqli的一些代碼部分(所有的判斷函數運行成功或失敗的代碼我都省略了，但不代表不重要)： php //用戶輸入的數據 $name?=?'admin'; $pass?=?'123456'; //首先新建mysqli對象,構造函數參數中包含了數據庫相關內容。 $conn?=?new?mysqli(DB\_HOST,?DB\_USER,?DB\_PASS,?DB\_NAME,?DB\_PORT); //設置sql語句默認編碼 $this->mysqli->set\_charset("utf8"); //創建一個使用通配符的sql語句 $sql?=?'SELECT?user\_id?FROM?admin?WHERE?username=??AND?password=?;'; //編譯該語句，得到一個stmt對象. $stmt?=?$conn->prepare($sql); /\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*之后的內容就能重復利用，不用再次編譯\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/ //用bind\_param方法綁定數據 //大家可以看出來，因為我留了兩個?，也就是要向其中綁定兩個數據，所以第一個參數是綁定的數據的類型(s=string,i=integer)，第二個以后的參數是要綁定的數據 $stmt->bind\_param('ss',?$name,?$pass); //調用bind\_param方法綁定結果（如果只是檢查該用戶與密碼是否存在，或只是一個DML語句的時候，不用綁定結果） //這個結果就是我select到的字段，有幾個就要綁定幾個 $stmt->bind\_result($user\_id); //執行該語句 $stmt->execute(); //得到結果 if($stmt->fetch()){ echo?'登陸成功'; //一定要注意釋放結果資源，否則后面會出錯 $stmt->free\_result(); return?$user\_id;?//返回剛才select到的內容 }else{echo?'登錄失敗';} ?> 預防XSS代碼，如果不需要使用cookie就不使用 在我的網站中并沒有使用cookie，更因為我對權限限制的很死，所以對于xss來說危險性比較小。 對于xss的防御，也是一個道理，處理好“代碼”和“數據”的關系。當然，這里的代碼指的就是javascript代碼或html代碼。用戶能控制的內容，我們一定要使用htmlspecialchars等函數來處理用戶輸入的數據，并且在javascript中要謹慎把內容輸出到頁面中。 限制用戶權限，預防CSRF 現在腳本漏洞比較火的就是越權行為，很多重要操作使用GET方式執行，或使用POST方式執行而沒有核實執行者是否知情。 CSRF很多同學可能比較陌生，其實舉一個小例子就行了： A、B都是某論壇用戶，該論壇允許用戶“贊”某篇文章，用戶點“贊”其實是訪問了這個頁面：http://localhost/?act=support&articleid=12。這個時候，B如果把這個URL發送給A，A在不知情的情況下打開了它，等于說給articleid=12的文章贊了一次。 所以該論壇換了種方式，通過POST方式來贊某篇文章。 ?action="http://localhost/?act=support"?method="POST"> ?type="hidden"?value="12"?name="articleid"> ?type="submit"?value="贊"> 可以看到一個隱藏的input框里含有該文章的ID，這樣就不能通過一個URL讓A點擊了。但是B可以做一個“極具誘惑力”的頁面，其中某個按鈕就寫成這樣一個表單，來誘惑A點擊。A一點擊，依舊還是贊了這篇文章。 最后，該論壇只好把表單中增加了一個驗證碼。只有A輸入驗證碼才能點贊。這樣，徹底死了B的心。 但是，你見過哪個論壇點“贊”也要輸入驗證碼？ 所以吳翰清在白帽子里也推薦了最好的方式，就是在表單中加入一個隨機字符串token（由php生成，并保存在SESSION中），如果用戶提交的這個隨機字符串和SESSION中保存的字符串一致，才能贊。 在B不知道A的隨機字符串時，就不能越權操作了。 我在網站中也多次使用了TOKEN，不管是GET方式還是POST方式，通常就能抵御99%的CSRF估計了。 嚴格控制上傳文件類型 上傳漏洞是很致命的漏洞，只要存在任意文件上傳漏洞，就能執行任意代碼，拿到webshell。 我在上傳這部分，寫了一個php類，通過白名單驗證，來控制用戶上傳惡意文件。在客戶端，我通過javascript先驗證了用戶選擇的文件的類型，但這只是善意地提醒用戶，最終驗證部分，還是在服務端。 白名單是必要的，你如果只允許上傳圖片，就設置成array('jpg','gif','png','bmp')，當用戶上傳來文件后，取它的文件名的后綴，用in\_array驗證是否在白名單中。 在上傳文件數組中，會有一個MIME類型，告訴服務端上傳的文件類型是什么，但是它是不可靠的，是可以被修改的。在很多存在上傳漏洞的網站中，都是只驗證了MIME類型，而沒有取文件名的后綴驗證，導致上傳任意文件。 所以我們在類中完全可以忽略這個MIME類型，而只取文件名的后綴，如果在白名單中，才允許上傳。 當然，服務器的解析漏洞也是很多上傳漏洞的突破點，所以我們盡量把上傳的文件重命名，以“日期時間+隨機數+白名單中后綴”的方式對上傳的文件進行重命名，避免因為解析漏洞而造成任意代碼執行。 加密混淆javascript代碼，提高攻擊門檻 很多xss漏洞，都是黑客通過閱讀javascript代碼發現的，如果我們能把所有javascript代碼混淆以及加密，讓代碼就算解密后也是混亂的（比如把所有變量名替換成其MD5 hash值），提高閱讀的難度。 使用更高級的hash算法保存數據庫中重要信息 在這個硬盤容量大增的時期，很多人擁有很大的彩虹表，再加上類似于cmd5這樣的網站的大行其道，單純的md5已經等同于無物，所以我們迫切的需要更高級的hash算法，來保存我們數據庫中的密碼。 所以后來出現了加salt的md5，比如discuz的密碼就是加了salt。其實salt就是一個密碼的“附加值”，比如A的密碼是123456，而我們設置的salt是abc,這樣保存到數據庫的可能就是md5('123456abc')，增加了破解的難度。 但是黑客只要得知了該用戶的salt也能跑md5跑出來。因為現在的計算機的計算速度已經非常快了，一秒可以計算10億次md5值，弱一點的密碼分把鐘就能跑出來。 所以后來密碼學上改進了hash，引進了一個概念：密鑰延伸。說簡單點就是增加計算hash的難度（比如把密碼用md5()函數循環計算1000次），故意減慢計算hash所用的時間，以前一秒可以計算10億次，改進后1秒只能計算100萬次，速度慢了1000倍，這樣，所需的時間也就增加了1000倍。 那么對于我們，怎么使用一個安全的hash計算方法？大家可以翻閱emlog的源碼，可以在include目錄里面找到一個HashPaaword.php的文件，其實這就是個類，emlog用它來計算密碼的hash。 這個類有一個特點，每次計算出的hash值都不一樣，所以黑客不能通過彩虹表等方式破解密碼，只能用這個類中一個checkpassword方法來返回用戶輸入密碼的正確性。而該函數又特意增加了計算hash的時間，所以黑客很難破解他們拿到的hash值。 在最新的php5.5中，這種hash算法成為了一個正式的函數，以后就能使用該函數來hash我們的密碼了。 驗證碼安全性 這是我剛想到的一點，來補充一下。 驗證碼通常是由php腳本生成的隨機字符串，通過GD庫的處理，制作成圖片。真正的驗證碼字符串保存在SESSION中，然后把生成的圖片展示給用戶。用戶填寫了驗證碼提交后，在服務端上SESSION中的驗證碼進行比對。 由此想到了我之前犯過的一個錯誤。驗證碼比對完成之后，不管是正確還是錯誤，我都沒有清理SESSION。這樣產生了一個問題，一旦一個用戶第一次提交驗證碼成功，第二次以后不再訪問生成驗證碼的腳本，這時候SESSION中的驗證碼并沒有更新，也沒有刪除，導致驗證碼重復使用，起不到驗證的作用。 再就說到了驗證碼被識別的問題，wordpress包括emlog的程序我經常會借鑒，但他們所使用的驗證碼我卻不敢恭維。很多垃圾評論都是驗證碼被機器識別后產生的，所以我后來也使用了一個復雜一點的驗證碼，據說是w3c推薦使用的。 如果大家需要，可以到這里下載[http://pan.baidu.com/s/1bnb8Zmf](http://pan.baidu.com/s/1bnb8Zmf) 好了，我能想到的，也是在實際運用中用到的東西也就這么多了。這也僅僅是我自己寫代碼中積累的一些對代碼安全性的一個見解，如果大家還有更好的想法，可以和我交流。希望大家也能寫出更安全的代碼。