摘要：書名構(gòu)建安全的應(yīng)用作者美譯者張慶龍以下記錄這本安全小書的大致內(nèi)容，對書中的知識點進行備忘?？梢员ＷC內(nèi)容的安全性，使得只有最終傳遞到的具有有效證書的接收者才能得到這一內(nèi)容。缺省安全及跨站攻擊缺省安全我們應(yīng)該為驗

書名：構(gòu)建安全的 PHP 應(yīng)用  
作者：(美) Ben Edmunds  
譯者：張慶龍

以下記錄這本 PHP Web 安全小書的大致內(nèi)容，對書中的知識點進行備忘。

這是一個老生常談的話題：我們可以利用 SQL 語句本身的作用方式，使用簡單的字符串拼接，就能使其執(zhí)行結(jié)果偏離預(yù)期，甚至造成毀滅性后果。比如：

"UPDATE User SET name = "". $name ."" WHERE id = 123"

若此時 $name 的值為 "; DROP DATABASE User; -- ，則拼接之后，實際執(zhí)行的 SQL 語句為：

UPDATE User SET name = ""; DROP DATABASE User; -- " WHERE id = 123

此時，災(zāi)難就發(fā)生了。

注：-- 表示注釋后續(xù)的語句。注意 -- 后有一個空格。這里使用 # 也可以達到注釋的效果。

在執(zhí)行前進行敏感字符的過濾（不能只通過 JavaScript）；

為不同的業(yè)務(wù)模塊分配細顆粒度權(quán)限的數(shù)據(jù)庫連接；

使用預(yù)處理和占位符，如 $db->prepare() 以及 $db->execute()；

使用存儲過程。但這種做法將部分業(yè)務(wù)邏輯轉(zhuǎn)移到了數(shù)據(jù)庫層，增加了測試和版本控制的難度。

使用 $_POST 中的所有字段直接作為數(shù)據(jù)庫操作的數(shù)據(jù)，可能會使得攻擊者通過修改表單的提交項，從而實現(xiàn)意外數(shù)據(jù)的修改，如：

----- xxx.html

    
    
    
    
    
    
    


----- action.php
$user = User::create(Input::all());

如上，如果攻擊者在前端頁面中加入了一條新的表單項，在后臺不加區(qū)分的情況下，直接把全部數(shù)據(jù)用于數(shù)據(jù)庫修改或增加，可能會造成新數(shù)據(jù)的插入或原數(shù)據(jù)的修改不如預(yù)期。如上例中，本應(yīng)按照 role 的默認值創(chuàng)建的普通用戶，此時變?yōu)榱?admin 身份。

字段映射。數(shù)據(jù)庫字段、數(shù)據(jù)庫視圖字段、API 接口字段不完全相同，使得攻擊者難以知曉數(shù)據(jù)庫字段的真實名；

給可以被安全賦值的字段加上白名單、或給危險字段加黑名單。如 Laravel 中的 $fillable 和 $guard。

PHP 的弱類型在一定程度上提升了開發(fā)效率，但也留下了安全隱患。不同類型間（包括數(shù)據(jù)庫本身）的隱式轉(zhuǎn)換有可能會使得數(shù)據(jù)表中的數(shù)據(jù)與預(yù)期不符。

因而我們一定要關(guān)注輸入數(shù)據(jù)的類型，還包括那些在 JavaScript 處理階段被轉(zhuǎn)換的數(shù)據(jù)類型。

使用 htmlspecialchars() 或 htmlentities() 對如 <, >, & 等特殊字符進行轉(zhuǎn)移，使得存儲于數(shù)據(jù)庫中的功能性 HTML 標簽不會直接輸出到瀏覽器（實際上，這一過程在數(shù)據(jù)輸入的時候也需要進行）。

使用 escapeshellcmd() 和 escapeshellarg() 轉(zhuǎn)移命令和參數(shù)，以確保命令執(zhí)行的安全可控性。

HTTPS 指 HTTP Secure 或 HTTP on SSL。HTTPS 可以保證內(nèi)容的安全性，使得只有最終傳遞到的、具有有效證書的接收者才能得到這一內(nèi)容。采用 HTTPS 可以有效地預(yù)防中間人攻擊和會話劫持。關(guān)于 HTTPS 的原理科普可以參考 「也許，這樣理解HTTPS更容易」。

普通的虛擬主機配置不能使用在 SSL 上。使用托管主機或在一個服務(wù)器上運行多個站點都會存在問題。這時需要更換為專用服務(wù)器。

此外，HTTPS 在連接階段包含 SSL 握手用于建立連接，因此速度會變慢。但在連接建立完成之后，這個問題就不明顯了。

想要使用 HTTPS，你需要完成以下步驟：

子站點較多時，使用通配 SSL 證書。反之使用標準版即可。

首先需要生成私鑰：

openssl genrsa -out yourApp.key 1024

然后使用私鑰生成簽名：

openssl req -new -key yourApp.key -out yourApp.csr

之后需要在證書頒發(fā)機構(gòu)中獲取證書，通常需要使用 yourApp.csr 文件，這一步獲取的證書為 yourAppSigned.crt。

最后就是根據(jù)服務(wù)器的類型（Apache、Nginx 或其他）進行對應(yīng)的配置。在 Apache 中為：

    # ...
    SSLEngine on
    SSLCertificateFile /your/path/to/yourAppSigned.crt
    SSLCertificateKeyFile /your/path/to/yourApp.key
    # ...

在 Nginx 中為：

server {
    listen 443;
    # ...
    ssl  on;
    ssl_certificate /your/path/to/yourAppSigned.crt
    ssl_certificate_key /your/path/to/yourApp.key
    # ...
}

你可以使用以下方式用以正確的適配協(xié)議，如：

這時，當訪問的 URL 為 http://xxx.com 時，該引用也會是 HTTP 協(xié)議；當訪問的 URL 為 https://xxx.com 時，引用會變?yōu)?HTTPS 協(xié)議。

不要存儲密碼或可逆加密結(jié)果，要存儲不可逆的哈希串。

雖然哈希方式使得密碼存儲變?yōu)槊艽a值的不可逆串，消除了反向破解的可能。但仍有很多安全隱患。

雖然從哈希后的字符串反向解析是不可能的，但通過枚舉的方式一個個試探仍然可以得到出正確的密碼。當然，枚舉是不現(xiàn)實的，通常的做法是存儲一個查找表，表項為 密碼 - 哈希串。然后通過查找的方式暴力試探和破解。

這一方式可以通過對哈希過程加「鹽」進行預(yù)防，如在密碼進行哈希前，于密碼中插入一些字符，混合后一起哈希。

彩虹表在技術(shù)上與查找表類似，但其使用了數(shù)學(xué)方法用較小的內(nèi)存實現(xiàn)了查找表。關(guān)于彩虹表可以參考 維基百科。

碰撞攻擊，即不同的字符串的哈希值相同。在離散數(shù)學(xué)中，此攻擊又可以稱為「生日攻擊」，以下引用 維基百科：

生日問題是指，如果一個房間里有 23 個或 23 個以上的人，那么至少有兩個人的生日相同的概率要大于 50% 。這就意味著在一個典型的標準小學(xué)班級（30 人）中，存在兩人生日相同的可能性更高。對于 60 或者更多的人，這種概率要大于 99% 。從引起邏輯矛盾的角度來說生日悖論并不是一種悖論，從這個數(shù)學(xué)事實與一般直覺相抵觸的意義上，它才稱得上是一個悖論。大多數(shù)人會認為，23 人中有 2 人生日相同的概率應(yīng)該遠遠小于 50% 。計算與此相關(guān)的概率被稱為生日問題，在這個問題之后的數(shù)學(xué)理論已被用于設(shè)計著名的密碼攻擊方法：生日攻擊。

鹽是為了使哈希唯一而附加在其上的東西。這意味著即使有了哈希密碼表，攻擊者也不能正確地匹配上密碼。由此可知，鹽的隨機性是密碼安全的一部分。

雖然 PHP 的內(nèi)置函數(shù) rand() 和 mt_rand() 可以生成隨機數(shù)，但這是使用算法生成的數(shù)字，因而沒有足夠的外部數(shù)據(jù)使其真正唯一。這意味著采用這兩種函數(shù)生成的隨機數(shù)可以被攻擊者猜測。事實上，只需要知道 rand() 函數(shù)的 624 個值就可以預(yù)判之后的所有值了。

使用 /dev/random 在大多數(shù)系統(tǒng)中是真正隨機的好方法。它會收集系統(tǒng)熵和環(huán)境數(shù)據(jù)，如鍵盤輸入、硬件數(shù)據(jù)等。但這一過程會導(dǎo)致阻塞，使得效率極低。在這一情況下，我們可以使用 /dev/urandom，該方法在真正隨機上并不夠強壯，但它作為鹽卻足夠安全。

為了使用隨機而又不存儲鹽的具體值，對應(yīng)的哈希方法中，如 crypt() ，返回的結(jié)果會包括我們采用的算法、密碼的哈希值，以及鹽。

MD5 早已被數(shù)學(xué)方法證明其并不安全。它很容易在現(xiàn)代硬件上產(chǎn)生沖突。但 MD5 也不是一無是處，配合合適的鹽也可以保證哈希結(jié)果的安全。

同 MD5 一樣，SHA-1 算法也被證明可以通過不到 2^69 次哈希產(chǎn)生沖突，因而是不安全的。

二者采用的核心算法幾乎是一樣的，但 SHA-256 使用 32 位字符，而 SHA-512 采用 64 位，二者的循環(huán)次數(shù)也不相同。

BCrypt 是 Blowfish 密碼的衍生方法。該算法是迭代的，由于開銷的關(guān)系，使其可以防止暴力破解。BCrypt 在加密純文本密碼時有 72 字符的限制，但這一算法長期以來仍沒有漏洞公布，因而被認為是密碼安全的。

SCrypt 是一個在內(nèi)存方面加強的衍生算法。理論上來說，該算法在高內(nèi)存消耗之下是一個更為安全的算法。

在 PHP 5.5 版本之后引入了新的密碼哈希函數(shù) password_hash() 和 password_verify()，極大程度簡化了密碼操作流程，該函數(shù)會自動獲取隨機鹽并進行哈希。

只要時間足夠，暴力破解和嘗試總會得到一個正確的結(jié)果。對于此，我們可以限制嘗試的頻率和次數(shù)，或者封鎖敏感 IP。

對于那些使用明文或采用不安全的哈希方法存儲密碼的遺留系統(tǒng)，升級它們的方式大致分為以下兩種。

如果用戶該次登錄的密碼匹配于數(shù)據(jù)庫的密碼，則可以用當前密碼值重新哈希，并替換掉數(shù)據(jù)庫的密碼。但這種被動的替換方式可能會持續(xù)很長時間（需要用戶自行觸發(fā)），所以數(shù)據(jù)庫需要有一個標識字段，用以表示該密碼是否已經(jīng)置換成功。但給數(shù)據(jù)表添加字段并不容易，尤其是對于運行中的大型應(yīng)用。

采用這種方式，可以選擇一個時機，統(tǒng)一對用戶密碼字段進行遍歷更新?？瓷先ナ且粍谟酪莸姆椒?，但會使得密碼驗證機制效率變低。而且，現(xiàn)有系統(tǒng)會一直被早先的機制所拖累。

確保訪問的頁面、參與的業(yè)務(wù)請求都必須被身份驗證和權(quán)限控制模塊所覆蓋。警惕重定向?qū)е碌臋?quán)限穿透。

很多數(shù)據(jù)表中使用自增主鍵作為記錄的唯一標識。并且在 Cookie 和 API 中使用這些整形值。這會造成一些隱患，建議的做法是將這些值混淆到一些字符串中，使得它們被模糊處理。

一些框架中會使用某個路徑作為公開文件夾，比如 /public，這也就意味著我們可以通過對該文件夾的相對路徑直接訪問到其中的文件，而無視權(quán)限和身份的限制。建議的做法是將敏感的、需要安全防護的文件放置在其他路徑中，使得通過 URL 無法直接訪問。

我們應(yīng)該為驗證邏輯提供缺省值，以保證在沒有考慮全面之時不會引發(fā)大型漏洞。

此外，不要相信動態(tài)類型，尤其是在判斷語句中，整形返回值和布爾值的隱式轉(zhuǎn)換可能會造成嚴重的后果。

XSS（跨站腳本攻擊）和 CSRF（跨站請求偽造）分別是用戶過分信任網(wǎng)站與網(wǎng)站過分信任瀏覽器所產(chǎn)生的安全隱患。前者的解決方案通常是在輸入和輸出時進行檢測和過濾，而后者通常是在提交表單中添加 token 令牌。關(guān)于這兩種攻擊的細節(jié)可以參見 參考鏈接。

這里涉及到 API 中的冪等性問題，指的是一次和多次對某一個資源的請求應(yīng)該具有同樣的副作用?；诖耍瑒?chuàng)建數(shù)據(jù)的請求是不符合冪等性的。比如由于網(wǎng)絡(luò)延遲問題，用戶多次點擊創(chuàng)建按鈕，發(fā)送的合法創(chuàng)建請求先后抵達服務(wù)器，從而導(dǎo)致創(chuàng)建行為產(chǎn)生多次。這一問題在轉(zhuǎn)賬等業(yè)務(wù)上也比較普遍。具體可以參考 「理解HTTP冪等性」。使用之前提到的一次性的 token 令牌可以預(yù)防這一問題的出現(xiàn)。

應(yīng)對并發(fā)情況，需要考慮對文件、數(shù)據(jù)庫等資源的并發(fā)處理策略。必要時需要對操作的文件加鎖，以及對數(shù)據(jù)庫使用 ... for update 以添加悲觀鎖或通過版本字段實現(xiàn)樂觀鎖?？梢詤⒁?參考鏈接。