?
本文檔使用 PHP中文網(wǎng)手冊 發(fā)布
最佳安全實踐
最佳安全實踐
下面，我們將會回顧常見的安全原則，并介紹在使用 Yii 開發(fā)應(yīng)用程序時，如何避免潛在安全威脅。
基本準則
無論是開發(fā)何種應(yīng)用程序，我們都有兩條基本的安全準則：
- 過濾輸入
- 轉(zhuǎn)義輸出
過濾輸入
過濾輸入的意思是，用戶輸入不應(yīng)該認為是安全的，你需要總是驗證你獲得的輸入值是在允許范圍內(nèi)。比如，我們假設(shè) sorting 只能指定為?title，?created_at?和?status?三個值，然后，這個值是由用戶輸入提供的，那么，最好在我們接收參數(shù)的時候，檢查一下這個值是否是指定的范圍。 對于基本的 PHP 而言，上述做法類似如下：
$sortBy = $_GET['sort'];
if (!in_array($sortBy, ['title', 'created_at', 'status'])) {
throw new Exception('Invalid sort value.');
}
在 Yii 中，很大可能性，你會使用?表單校驗器?來執(zhí)行類似的檢查。
轉(zhuǎn)義輸出
轉(zhuǎn)義輸出的意思是，根據(jù)我們使用數(shù)據(jù)的上下文環(huán)境，數(shù)據(jù)需要被轉(zhuǎn)義。比如：在 HTML 上下文，你需要轉(zhuǎn)義?<，>?之類的特殊字符。在 JavaScript 或者 SQL 中，也有其他的特殊含義的字符串需要被轉(zhuǎn)義。 由于手動的給所用的輸出轉(zhuǎn)義容易出錯，Yii 提供了大量的工具來在不同的上下文執(zhí)行轉(zhuǎn)義。
避免 SQL 注入
SQL 注入發(fā)生在查詢語句是由連接未轉(zhuǎn)義的字符串生成的場景，比如：
$username = $_GET['username'];
$sql = "SELECT * FROM user WHERE username = '$username'";
除了提供正確的用戶名外，攻擊者可以給你的應(yīng)用程序輸入類似 '; DROP TABLE user; --` 的語句。 這將會導(dǎo)致生成如下的 SQL ：
SELECT * FROM user WHERE username = ''; DROP TABLE user; --'這是一個合法的查詢語句，并將會執(zhí)行以空的用戶名搜索用戶操作，然后，刪除?user?表。這極有可能導(dǎo)致網(wǎng)站出差，數(shù)據(jù)丟失。（你是否進行了規(guī)律的數(shù)據(jù)備份？）
在 Yii 中，大部分的數(shù)據(jù)查詢是通過?Active Record?進行的，而其是完全使用 PDO 預(yù)處理語句執(zhí)行 SQL 查詢的。在預(yù)處理語句中，上述示例中，構(gòu)造 SQL 查詢的場景是不可能發(fā)生的。
有時，你仍需要使用?raw queries?或者?query builder。在這種情況下，你應(yīng)該使用安全的方式傳遞參數(shù)。如果數(shù)據(jù)是提供給表列的值，最好使用預(yù)處理語句：
// query builder$userIDs = (new Query())
->select('id')
->from('user')
->where('status=:status', [':status' => $status])
->all();
// DAO$userIDs = $connection
->createCommand('SELECT id FROM user where status=:status')
->bindValues([':status' => $status])
->queryColumn();
如果數(shù)據(jù)是用于指定列的名字，或者表的名字，最好的方式是只允許預(yù)定義的枚舉值。
function actionList($orderBy = null){
if (!in_array($orderBy, ['name', 'status'])) {
throw new BadRequestHttpException('Only name and status are allowed to order by.')
}
// ...
}
如果上述方法不行，表名或者列名應(yīng)該被轉(zhuǎn)義。 Yii 針對這種轉(zhuǎn)義提供了一個特殊的語法，這樣可以在所有支持的數(shù)據(jù)庫都使用一套方案。
$sql = "SELECT COUNT($column) FROM {{table}}";
$rowCount = $connection->createCommand($sql)->queryScalar();
你可以在?Quoting Table and Column Names?中獲取更多的語法細節(jié)。
防止 XSS 攻擊
XSS 或者跨站腳本發(fā)生在輸出 HTML 到瀏覽器時，輸出內(nèi)容沒有正確的轉(zhuǎn)義。例如，如果用戶可以輸入其名稱，那么他輸入<script>alert('Hello!');</script>?而非其名字?Alexander，所有輸出沒有轉(zhuǎn)義直接輸出用戶名的頁面都會執(zhí)行 JavaScript 代碼alert('Hello!');，這會導(dǎo)致瀏覽器頁面上出現(xiàn)一個警告彈出框。就具體的站點而言，除了這種無意義的警告輸出外，這樣的腳本可以以你的名義發(fā)送一些消息到后臺，甚至執(zhí)行一些銀行交易行為。
避免 XSS 攻擊在 Yii 中非常簡單，有如下兩種一般情況：
- 你希望數(shù)據(jù)以純文本輸出。
- 你希望數(shù)據(jù)以 HTML 形式輸出。
如果你需要的是純文本，你可以如下簡單的轉(zhuǎn)義：
<?= \yii\helpers\Html::encode($username) ?>如果是 HTML ，我們可以用 HtmlPurifier 幫助類來執(zhí)行：
<?= \yii\helpers\HtmlPurifier::process($description) ?>注意： HtmlPurifier 幫助類的處理過程較為費時，建議增加緩存：
防止 CSRF 攻擊
CSRF 是跨站請求偽造的縮寫。這個攻擊思想源自許多應(yīng)用程序假設(shè)來自用戶的瀏覽器請求是由用戶自己產(chǎn)生的，而事實并非如此。
比如說：an.example.com?站點有一個?/logout?URL，當以 GET 請求訪問時，登出用戶。如果它是由用戶自己操作的，那么一切都沒有問題。但是，有一天壞人在一個用戶經(jīng)常訪問的論壇發(fā)了一個?<img src="/docs/guide/2.0/http://an.example.com/logout">?內(nèi)容的帖子。瀏覽器無法辨別請求一個圖片還是一個頁面，所以，當用戶打開含有上述標簽的頁面時，他將會從?an.example.com?登出。
上面就是最原始的思想。有人可能會說，登出用戶也不是什么嚴重問題，然而，我們發(fā)送一些 POST 數(shù)據(jù)其實也不是很麻煩的事情。
為了避免 CSRF 攻擊，你總是需要：
- 遵循 HTTP 準則，比如 GET 不應(yīng)該改變應(yīng)用的狀態(tài)。
- 保證 Yii CSRF 保護開啟。
防止文件暴露
默認的服務(wù)器 webroot 目錄指向包含有?index.php?的?web?目錄。在共享托管環(huán)境下，這樣是不可能的，這樣導(dǎo)致了所有的代碼，配置，日志都在webroot目錄。
如果是這樣，別忘了拒絕除了?web?目錄以外的目錄的訪問權(quán)限。如果沒法這樣做，考慮將你的應(yīng)用程序托管在其他地方。
在生產(chǎn)環(huán)境關(guān)閉調(diào)試信息和工具
在調(diào)試模式下， Yii 展示了大量的錯誤信息，這樣是對開發(fā)有用的。同樣，這些調(diào)試信息對于攻擊者而言也是方便其用于破解數(shù)據(jù)結(jié)構(gòu)，配置值，以及你的部分代碼。永遠不要在生產(chǎn)模式下將你的?index.php?中的?YII_DEBUG?設(shè)置為?true。
你同樣也不應(yīng)該在生產(chǎn)模式下開啟 Gii。它可以被用于獲取數(shù)據(jù)結(jié)構(gòu)信息，代碼，以及簡單的用 Gii 生成的代碼覆蓋你的代碼。