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

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

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

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

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

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

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

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

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

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

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

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

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

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

----- xxx.html

    
    
    
    
    
    
    


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

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

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

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

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

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

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

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

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

普通的虛擬主機(jī)配置不能使用在 SSL 上。使用托管主機(jī)或在一個(gè)服務(wù)器上運(yùn)行多個(gè)站點(diǎn)都會(huì)存在問(wèn)題。這時(shí)需要更換為專(zhuān)用服務(wù)器。

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

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

子站點(diǎn)較多時(shí)，使用通配 SSL 證書(shū)。反之使用標(biāo)準(zhǔn)版即可。

首先需要生成私鑰：

openssl genrsa -out yourApp.key 1024

然后使用私鑰生成簽名：

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

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

最后就是根據(jù)服務(wù)器的類(lèi)型（Apache、Nginx 或其他）進(jìn)行對(duì)應(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é)議，如：

這時(shí)，當(dāng)訪問(wèn)的 URL 為 http://xxx.com 時(shí)，該引用也會(huì)是 HTTP 協(xié)議；當(dāng)訪問(wèn)的 URL 為 https://xxx.com 時(shí)，引用會(huì)變?yōu)?HTTPS 協(xié)議。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

采用這種方式，可以選擇一個(gè)時(shí)機(jī)，統(tǒng)一對(duì)用戶(hù)密碼字段進(jìn)行遍歷更新。看上去是一勞永逸的方法，但會(huì)使得密碼驗(yàn)證機(jī)制效率變低。而且，現(xiàn)有系統(tǒng)會(huì)一直被早先的機(jī)制所拖累。

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

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

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

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

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

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

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

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