本文主要和大家探討一下ThinkPHP的安全注意事項，可以作為ThinkPHP建議的安全規范實(shí)踐。（如果有新的內容我也會(huì )及時(shí)補充）

首先，沒(méi)有絕對的安全，只要你有足夠的安全意識才能盡可能的杜絕安全隱患。規范的使用框架，能讓你盡量避免一些看起來(lái)比較幼稚的安全問(wèn)題。本文描述的安全注意事項主要是指生產(chǎn)環(huán)境下面的安全策略，本地開(kāi)發(fā)的情況下有時(shí)候為了調試的需要安全并不是第一考慮。

ThinkPHP在考慮開(kāi)發(fā)體驗的同時(shí)，仍然十分重視框架的底層安全，雖然屢有安全漏洞被播報，但官方都是第一時(shí)間進(jìn)行修復處理，而且大部分漏洞只要開(kāi)發(fā)者有一定的安全意識都是可以避免的，今年也和國內的幾個(gè)安全團隊建立了合作關(guān)系，有助于提前發(fā)現和及時(shí)修正框架可能被利用的漏洞或者隱患。

規范部署

這一點(diǎn)很多開(kāi)發(fā)者不是特別重視，安全是一個(gè)整體性的問(wèn)題，任何一個(gè)環(huán)節出問(wèn)題，帶來(lái)的后果都是一樣的嚴重，部署的安全策略是一個(gè)基礎安全問(wèn)題。

很多開(kāi)發(fā)者往往不按照官方的部署規范進(jìn)行部署，請務(wù)必把你的WEB根目錄指向public目錄而不是應用根目錄，并且不要隨意更改入口文件的位置。public目錄下面不要放除了入口文件和資源文件以外的其它應用文件。

關(guān)閉調試模式

在部署到生產(chǎn)環(huán)境的時(shí)候，確保你已經(jīng)關(guān)閉了調試模式，可以通過(guò)修改環(huán)境變量的方式關(guān)閉調試模式。

APP_DEBUG=false 

無(wú)論是本地開(kāi)發(fā)還是生產(chǎn)環(huán)境部署，都不建議直接通過(guò)修改配置文件的方式開(kāi)啟/關(guān)閉調試模式，而應該使用環(huán)境變量（本地開(kāi)發(fā)可以通過(guò)定義.env文件）。

關(guān)閉調試模式后，系統的健康狀態(tài)和運行監控主要依靠日志或者你使用的監控服務(wù)。所以，要養成定時(shí)檢查日志和運行狀態(tài)的習慣。

請求變量過(guò)濾

永遠不要相信用戶(hù)的輸入，這是一句至理名言。盡可能的過(guò)濾請求變量能有效防范大部分的漏洞和隱患。

框架建議的獲取請求變量的方法是Request類(lèi)的param方法（如非必要不要再使用get或者post方法獲取，更不要使用原生的$_GET/$_POST等方法獲?。?。

public function index(Request $request) { $name = $request->param(\'name\'); // 在這里可以根據你的業(yè)務(wù)需求進(jìn)行更嚴謹的過(guò)濾 // 例如 $name = $request->param(\'name\',\'\',\'htmlentities,strtolower\'); // 或者使用驗證器進(jìn)行專(zhuān)門(mén)的驗證 } 

對于有明確類(lèi)型的請求變量，可以在使用param方法的時(shí)候使用類(lèi)型強制轉換，例如：

public function index(Request $request) { // 強制轉換字符串數據 $name = $request->param(\'name/s\'); // 強制轉換整型數據 $name = $request->param(\'id/d\'); // 強制轉換浮點(diǎn)型數據 $name = $request->param(\'score/f\'); } 

或者直接使用方法參數獲取請求變量

public function index(string $name) { // 在這里可以根據你的業(yè)務(wù)需求進(jìn)行更嚴謹的過(guò)濾 // 或者使用驗證器進(jìn)行專(zhuān)門(mén)的驗證 } 

如果你需要對所有數據進(jìn)行處理，可以設置全局的過(guò)濾方法。對不同的應用需求設置default_filter過(guò)濾規則（默認沒(méi)有任何過(guò)濾規則），常見(jiàn)的安全過(guò)濾函數包括stripslashes、htmlentities、htmlspecialchars和strip_tags等，請根據業(yè)務(wù)場(chǎng)景選擇最合適的過(guò)濾方法。

如果需要獲取多個(gè)數據，建議使用only方法指定需要獲取的變量名稱(chēng)，避免有些不懷好意的數據提交導致權限問(wèn)題。

public function index(Request $request) { // 指定表單數據名稱(chēng) $data = $request->only([\'name\',\'title\']); } 

當你使用數據庫或者模型操作寫(xiě)入數據的時(shí)候，也可以指定字段，避免非法和不希望的字段寫(xiě)入數據庫。

// 模型 User::allowField([\'name\',\'title\']) ->save($data); // 數據庫 Db::name(\'user\') ->field([\'name\',\'title\']) ->insert($data); 

模型還有一個(gè)只讀字段的功能能避免你的數據受到外部的修改。

上傳檢測

網(wǎng)站的上傳功能也是一個(gè)非常容易被攻擊的入口，所以對上傳功能的安全檢查是尤其必要的。

系統的think\\File類(lèi)提供了文件上傳的安全支持，包括對文件后綴、文件類(lèi)型、文件大小以及上傳圖片文件的合法性檢查，確保你已經(jīng)在上傳操作中啟用了這些合法性檢查，可以參考手冊的上傳章節。

SQL注入

ThinkPHP的查詢(xún)統一使用了PDO的prepare預查詢(xún)和參數綁定機制，能有效的避免SQL注入的發(fā)生。但不代表絕對安全，如果你缺乏良好的代碼規范，仍然有可能被利用。

一個(gè)最簡(jiǎn)單的原則就是不要讓用戶(hù)決定你的查詢(xún)條件（或者字段排序）和控制你的查詢(xún)數據。

對于一些字符串的查詢(xún)條件（包括原生查詢(xún)）或者特殊的查詢(xún)（包括ORDER部分），需要手動(dòng)進(jìn)行參數綁定。

// 錯誤的 Db::query("select * from think_user where id=$id AND status=$statis"); // 正確的 Db::query("select * from think_user where id=? AND status=?", [ $id, $status]); // 正確的 Db::execute("update think_user set name=:name where status=:status", [ \'name\' => \'thinkphp\', \'status\' => 1 ]); 

對于使用了whereExp和whereRaw方式的查詢(xún)，你也需要使用參數綁定。

Db::name(\'user\') ->whereRaw(\'id > ? AND status = ?\',[10, 1]) ->select(); 

使用驗證器

對于大量的表單需要驗證的情況，建議使用驗證器功能統一進(jìn)行數據的合規驗證。驗證器的驗證操作應該在控制器或者路由階段使用validate方法進(jìn)行處理，模型的數據驗證功能新版已經(jīng)取消不再建議使用，模型和數據庫操作的時(shí)候應該傳入經(jīng)過(guò)安全處理過(guò)的數據。

XSS攻擊

跨站腳本攻擊（cross-site ing，簡(jiǎn)稱(chēng) XSS），XSS是一種在web應用中的計算機安全漏洞，它允許惡意web用戶(hù)將代碼植入到提供給其它用戶(hù)使用的頁(yè)面中。

在渲染輸出的頁(yè)面中，要對一些數據進(jìn)行安全處理，防止被惡意利用造成XSS攻擊，如果是5.1版本的話(huà)，所有的輸出都已經(jīng)經(jīng)過(guò)了htmlentities 轉義輸出，確保安全。如果是5.0版本的話(huà)，你可以自定義一個(gè)xss過(guò)濾函數，在模板文件中對一些關(guān)鍵內容變量進(jìn)行函數處理。

CSRF_132" style="box-sizing:inherit;margin:-10px 0px 0px;padding:0px;color:#009A61;position:absolute;">CSRF

CSRF 跨站請求偽造是 Web 應用中最常見(jiàn)的安全威脅之一，攻擊者偽造目標用戶(hù)的HTTP請求，然后此請求發(fā)送到有CSRF漏洞的網(wǎng)站，網(wǎng)站執行此請求后，引發(fā)跨站請求偽造攻擊。攻擊者利用隱蔽的HTTP連接，讓目標用戶(hù)在不注意的情況下單擊這個(gè)鏈接，由于是用戶(hù)自己點(diǎn)擊的，而他又是合法用戶(hù)擁有合法權限，所以目標用戶(hù)能夠在網(wǎng)站內執行特定的HTTP鏈接，從而達到攻擊者的目的。

開(kāi)啟表單令牌驗證，盡量開(kāi)啟強制路由并嚴格規范每個(gè)URL請求，定義單獨的MISS路由規則。

遵循請求類(lèi)型的使用規范并做好權限驗證，刪除操作必須使用DELETE請求，數據更改操作必須使用POST、PUT 或者 PATCH 請求方法，GET請求不應該更改任何數據。

會(huì )話(huà)劫持

會(huì )話(huà)劫持是指攻擊者利用各種手段來(lái)獲取目標用戶(hù)的session id。一旦獲取到session id，那么攻擊者可以利用目標用戶(hù)的身份來(lái)登錄網(wǎng)站，獲取目標用戶(hù)的操作權限。

有效的防護策略包括：

在每次會(huì )話(huà)啟動(dòng)的時(shí)候，調用regenerate方法。

Session::start(); Session::regenerate(true); 

更改session配置參數，開(kāi)啟安全選項：

\'use_trans_sid\' => 0, \'httponly\' => true, \'secure\' => true, 

升級到安全版本

官方會(huì )對一些安全隱患和潛在漏洞進(jìn)行修復，并且發(fā)布一個(gè)更為安全的版本。請確認你升級到更安全的版本，確保底層的安全和健壯性。

目前各個(gè)版本的建議版本如下：

關(guān)注官方的公眾號和開(kāi)發(fā)者周刊，注意最新的安全更新。

業(yè)務(wù)邏輯安全

這個(gè)屬于應用層面的安全，很多漏洞源于某個(gè)業(yè)務(wù)邏輯自身的安全隱患，包括沒(méi)有做合理的數據驗證和權限檢查，尤其是涉及資金及財務(wù)層面的，一定要做更多的安全檢查，并且開(kāi)啟事務(wù)。一個(gè)好的建議是更多的對應用進(jìn)行分層設計，減少每層的復雜性，獨立的分層設計便于提高安全性。

服務(wù)器安全

最后一點(diǎn)是運維階段需要特別注意的，及時(shí)更新服務(wù)器的安全補丁，確保沒(méi)有可利用的公開(kāi)系統漏洞，包括你的數據庫系統安（尤其是數據備份工作）。