安全開發(fā)筆記做到第22天話題輪到了一個既基礎(chǔ)又容易翻車的東西PHP留言板。也許有人覺得留言板太小兒科了路由、接口、緩存、消息隊(duì)列才是生產(chǎn)級但真實(shí)情況恰好相反。留言板幾乎是Web安全攻防的濃縮樣本一個表單進(jìn)來經(jīng)過超全局變量接收落到數(shù)據(jù)庫再原路吐回頁面中間還夾著會話狀態(tài)和第三方組件。這一圈走下來如果每一層都沒有邊界處理普通的一句話都能把站打穿。這次筆記我想把留言板當(dāng)載體重新梳理PHP安全開發(fā)的幾個核心命題超全局變量的使用邊界、數(shù)據(jù)庫操作里的參數(shù)化查詢、第三方插件引入的風(fēng)險(xiǎn)控制以及一個完整的留言板功能從設(shè)計(jì)到上線的安全加固流程。適合正在學(xué)Web安全開發(fā)的人也適合寫過PHP但沒系統(tǒng)性想過“數(shù)據(jù)從哪來到哪去、該在哪設(shè)防”的開發(fā)者。不要急著寫功能先把數(shù)據(jù)流和安全邊界想清楚。下面是我整理出來的完整筆記。1. 為什么留言板項(xiàng)目在安全開發(fā)里地位這么高很多初學(xué)者問我的第一句話是安全開發(fā)為什么不講一個更復(fù)雜的系統(tǒng)比如電商、CMS非要拿留言板說事我的回答是留言板是唯一一個能用較短時間講完“輸入到處理、存儲到輸出”完整閉環(huán)的項(xiàng)目而且每個環(huán)節(jié)都有現(xiàn)實(shí)攻擊案例。電商系統(tǒng)的大頭在業(yè)務(wù)邏輯權(quán)限留言板的大頭在通用安全基線后者才是安全開發(fā)的地基。留言板這個形態(tài)幾乎覆蓋了一個Web應(yīng)用最常見的攻擊面用戶提交的數(shù)據(jù)會進(jìn)數(shù)據(jù)庫有注入面會展示給其他人有XSS面會觸發(fā)管理操作有CSRF和越權(quán)面還會拉動周邊資源比如富文本編輯器、驗(yàn)證碼庫、Markdown解析器引入第三方插件后就有了供應(yīng)鏈面。一個看似簡單的“寫一條留言、展示一條留言”如果只做功能不修安全整體脆弱性比一個結(jié)構(gòu)復(fù)雜的后臺系統(tǒng)還高。更關(guān)鍵的是留言板的數(shù)據(jù)流非常清晰適合建立安全開發(fā)思維模型。不管以后做API、小程序后端還是管理平臺你都要回答這幾個問題用戶輸入到了哪個超全局變量經(jīng)過哪些過濾函數(shù)以什么方式進(jìn)入SQL以什么方式渲染到前端第三方依賴是否可信這套思維模型一旦建立換什么框架、換什么語言都能復(fù)用。所以寫留言板寫的不是留言板本身而是把每個開發(fā)者腦子里那根數(shù)據(jù)邊界的弦接上。1.1 留言板牽出的六層風(fēng)險(xiǎn)清單我習(xí)慣在動手前把風(fēng)險(xiǎn)點(diǎn)列一遍相當(dāng)于給項(xiàng)目畫風(fēng)險(xiǎn)地圖。留言板對應(yīng)的風(fēng)險(xiǎn)層大概是六層入口層超全局變量的使用不規(guī)范導(dǎo)致參數(shù)來源混淆或變量覆蓋。校驗(yàn)層對數(shù)據(jù)類型、長度、字符集缺少約束臟數(shù)據(jù)直接進(jìn)入業(yè)務(wù)邏輯。存儲層SQL語句拼接用戶輸入形成注入點(diǎn)。輸出層用戶內(nèi)容未經(jīng)編碼直接輸出形成存儲型XSS。會話層身份認(rèn)證和CSRF防護(hù)缺失管理操作可被偽造。供應(yīng)鏈層第三方插件帶版本漏洞或惡意代碼拖垮整個應(yīng)用。后面的所有工作本質(zhì)上是讓這六層風(fēng)險(xiǎn)降到可控范圍。帶著這張清單去看后面的章節(jié)思路會順很多。1.2 一句話概括今天的目標(biāo)今天的目標(biāo)不是做一個演示用的Hello留言板而是做一個有基礎(chǔ)抗攻擊能力的留言板能防SQL注入、能防存儲型XSS、能防CSRF、能控制第三方插件的引入風(fēng)險(xiǎn)。這個標(biāo)準(zhǔn)看著不高但很多存量項(xiàng)目其實(shí)一條都沒做到。2. PHP超全局變量每一個入口都可能被投毒PHP開發(fā)里最常用的就是超全局變量但大多數(shù)人只把它們當(dāng)成拿參數(shù)的盒子沒人想過這些盒子里的數(shù)據(jù)是帶著敵意的。這一節(jié)把每個超全局變量的角色和風(fēng)險(xiǎn)邊界過一遍。2.1 超全局變量全家桶與數(shù)據(jù)來源PHP常用的超全局變量有8個留言板場景里至少會碰到6個。我直接用表格梳理一下變量名數(shù)據(jù)來源在留言板里的角色$_GETURL查詢字符串分頁參數(shù)、搜索關(guān)鍵字$_POSTHTTP請求體表單字段留言內(nèi)容、用戶名、郵箱、CSRF Token$_REQUESTGET與POST合并不推薦使用見下文$_COOKIECookie頭登錄令牌通常是會話ID$_SESSION服務(wù)端會話存儲登錄狀態(tài)、CSRF Token、限流計(jì)數(shù)器$_SERVER服務(wù)端環(huán)境客戶端IP、User-Agent、請求方法$_FILES文件上傳字段留言板頭像如果做上傳功能$_ENV環(huán)境變量應(yīng)用配置這里單說 $_REQUEST。很多老代碼喜歡用它一把梭既能接GET又能接POST省事。但問題就出在省事上它把數(shù)據(jù)來源搞混了當(dāng)GET和POST同時出現(xiàn)同名參數(shù)時$_REQUEST 的優(yōu)先級在不同的PHP配置下還不一樣出了問題排查難度直接拉高。安全開發(fā)的第一原則是來源清晰誰敢把多個入口混成一個誰就在給后續(xù)維護(hù)埋雷。所以我自己的代碼里只用 $_GET 和 $_POST不用 $_REQUEST。2.2 超全局變量里常見的三個坑第一個坑是 $_SERVER[PHP_SELF]。它本身是服務(wù)器生成的腳本路徑看起來應(yīng)該安全但實(shí)際上可以被URL污染。如果在地址欄構(gòu)造一個包含XSS payload的路徑部分場景下直接輸出 PHP_SELF 就會觸發(fā)反射型XSS。處理辦法有兩種要么用 $_SERVER[SCRIPT_NAME] 替代要么在輸出時做 htmlspecialchars 編碼。第二個坑是變量覆蓋。有些老框架和遺留代碼喜歡用 extract($_POST) 把用戶提交的參數(shù)直接變成同名PHP變量或者用 $$id 這種動態(tài)變量拼接。這看起來是省了代碼實(shí)際上用戶可以通過構(gòu)造參數(shù)名來覆蓋程序里原有的變量。早期PHP圈出過一批這類漏洞基本都跟超全局變量被暴力展開有關(guān)?，F(xiàn)在寫代碼我是一律不建議用這種寫法顯式從超全局變量取值再校驗(yàn)是最笨但最穩(wěn)的做法。第三個坑是默認(rèn)信任。很多人拿到 $_POST[content] 就認(rèn)為它是字符串實(shí)際上對方提交的可能是數(shù)組比如構(gòu)造 content[]xxx賦值行為就會異常甚至在某些參數(shù)化過程不嚴(yán)格的代碼里繞過過濾。判斷類型比判斷值更優(yōu)先取值后先用 is_string、is_numeric 這類函數(shù)做類型確認(rèn)再談長度和格式校驗(yàn)。2.3 超全局變量的安全使用規(guī)范我給自己定了三條規(guī)矩基本能覆蓋90%的入口風(fēng)險(xiǎn)第一只從明確的超全局變量取值不同時混用GET和POST語義。GET只承載獲取類參數(shù)POST只承載變更類參數(shù)。第二所有超全局變量里的值一律視為不可信輸入先做類型校驗(yàn)再做白名單校驗(yàn)最后做長度限制。第三不要在業(yè)務(wù)代碼里直接輸出超全局變量要么編碼后輸出要么轉(zhuǎn)存到經(jīng)過處理的局部變量里。配合這三條規(guī)范超全局變量從任意數(shù)據(jù)入口變成了嚴(yán)格受控的數(shù)據(jù)渡口攻擊面瞬間就小了一半。3. 數(shù)據(jù)庫操作留言數(shù)據(jù)的安全存儲通道留言板數(shù)據(jù)量不大但如果處理不好一條SQL注入就能讓整個數(shù)據(jù)庫裸奔。這個章節(jié)重點(diǎn)講PDO的使用方式和參數(shù)化查詢的底層邏輯。3.1 為什么用PDO而不是MySQLiPHP連MySQL的主流方案是兩個MySQLi和PDO。我的選擇是PDO原因有三第一PDO提供統(tǒng)一的抽象層以后要換數(shù)據(jù)庫引擎改動成本低。第二PDO支持服務(wù)端的預(yù)處理語句開啟方式明確。第三PDO的錯誤處理模式可以通過 PDO::ATTR_ERRMODE 統(tǒng)一設(shè)置成異常模式代碼里更好控錯。MySQLi不是不能用只是它的預(yù)處理和結(jié)果集處理相對啰嗦在安全設(shè)置上需要手工關(guān)注的點(diǎn)更多。團(tuán)隊(duì)里新人多的時候PDO的規(guī)范約束力更強(qiáng)。3.2 連接層配置里的三個安全點(diǎn)數(shù)據(jù)庫連接的DSN和PDO選項(xiàng)是最容易被忽略的安全位置。很多人隨手把連接參數(shù)寫出來就完事結(jié)果在三個點(diǎn)上埋了雷。第一個點(diǎn)是字符集。連接字符串里必須帶 charsetutf8mb4而且要放在DSN里不能只靠SQL里的 SET NAMES。如果數(shù)據(jù)庫連接字符集是latin1目標(biāo)表又是UTF-8一旦遇到特定編碼的注入payload就可能出現(xiàn)寬字節(jié)注入問題。把字符集固定下來是防御這一類注入的第一道閘門。第二個點(diǎn)是關(guān)閉本地模擬預(yù)處理。PDO默認(rèn)會嘗試用本地模擬預(yù)處理這會導(dǎo)致即便寫了占位符最終還是可能走字符串拼接再發(fā)到服務(wù)端當(dāng)PHP版本或驅(qū)動有差異時仍然存在注入風(fēng)險(xiǎn)。連接參數(shù)里寫 PDO::ATTR_EMULATE_PREPARES false強(qiáng)制走M(jìn)ySQL服務(wù)端的原生預(yù)處理這是關(guān)鍵安全開關(guān)。第三個點(diǎn)是錯誤信息不落地。開啟 PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION然后在整個調(diào)用鏈最外層統(tǒng)一捕獲異常記錄到日志絕不把PDOException的message直接展示給用戶。很多注入探測就是從數(shù)據(jù)庫報(bào)錯開始的把報(bào)錯隱藏掉等于把偵察路徑堵了一半。3.3 參數(shù)化查詢?yōu)槭裁茨軗踝QL注入很多人會背“參數(shù)化查詢防SQL注入”但說不出原理。我用一句話解釋預(yù)處理語句在發(fā)送到數(shù)據(jù)庫時SQL語句的結(jié)構(gòu)和參數(shù)是分開的兩個通道。數(shù)據(jù)庫先解析了SQL結(jié)構(gòu)把它當(dāng)成模板之后參數(shù)只是按類型填入的數(shù)據(jù)值。也就是說即使用戶輸入的內(nèi)容是 OR 11它也不會被當(dāng)成SQL語法去解析而只是一個字符串字面量。結(jié)構(gòu)是結(jié)構(gòu)數(shù)據(jù)是數(shù)據(jù)兩條通道隔離注入自然失效。寫法的差別也很直觀。拼接式寫法是$sql SELECT * FROM messages WHERE id . $_GET[id];參數(shù)化寫法是$stmt $pdo-prepare(SELECT * FROM messages WHERE id ?); $stmt-execute([$_GET[id]]);兩種寫法在功能上好像差不多但本質(zhì)差了一個維度前者把用戶數(shù)據(jù)融進(jìn)了SQL語法樹后者把用戶數(shù)據(jù)限制在了參數(shù)位。在留言板的所有SQL操作里我都用參數(shù)化寫法一條拼接都不用。3.4 bindParam 的經(jīng)典坑PDO的預(yù)處理支持 bindParam 和 bindValue 兩種綁定方式實(shí)測中有一個坑特別經(jīng)典。bindParam 綁定的是變量引用它不是在上一次bind那一刻取值的而是在 execute 的時候才取值。如果在循環(huán)里一直復(fù)用同一個變量并且反復(fù) execute最后一次循環(huán)的變量值會被所有 execute 使用。比如下面這種寫法就翻過車foreach ($dataList as $item) { $stmt-bindParam(:id, $item[id]); $stmt-execute(); }因?yàn)?$item[id] 是引用綁定每次 execute 前變量值已經(jīng)被下一次循環(huán)覆蓋最后所有行都更新成同一批ID。安全上可能不直接翻車但業(yè)務(wù)正確性就毀了。我的建議是不折騰 bindParam直接在 execute 括號里傳參數(shù)數(shù)組。$stmt-execute([:id $item[id]])又清晰又穩(wěn)。安全代碼最怕花活越直白的寫法越不容易出錯。4. 第三方插件引入拿來主義的代價都在暗處留言板做到一定階段就會出現(xiàn)一個誘惑富文本編輯器丑裝一個吧驗(yàn)證碼不想自己寫引個庫吧Markdown想讓格式更漂亮再拉個解析器吧。沒有問題插件本身是提升效率的好東西但你必須知道引入一個第三方插件等于把一段別人的代碼放進(jìn)了你的信任邊界。4.1 留言板里最容易引入的三類插件第一類是富文本編輯器。它功能強(qiáng)但歷史包袱也重。不少富文本編輯器都出過文件上傳漏洞攻擊者可以利用上傳接口在服務(wù)器上放一個可執(zhí)行的腳本文件。第二類是驗(yàn)證碼庫。長期停止維護(hù)的驗(yàn)證碼組件會有幾個問題圖形驗(yàn)證碼的強(qiáng)度弱、缺少音頻干擾、甚至存在被繞過的手段。第三類是Markdown解析器。如果解析器沒有做HTML過濾被注入的Markdown代碼在轉(zhuǎn)換后會把XSS帶進(jìn)頁面。這三類插件有一個共同特點(diǎn)看似只是前端工具實(shí)際都會觸及后端處理邏輯這就是風(fēng)險(xiǎn)放大的根源。4.2 插件選型的檢查清單我現(xiàn)在引入第三方插件前會強(qiáng)制自己過一遍清單共七項(xiàng)從官方渠道獲取優(yōu)先使用包管理工具安裝便于鎖定版本。固定版本號并把鎖定文件提交到版本庫防止依賴漂移。對下載包做校驗(yàn)和核對包管理工具自帶的hash驗(yàn)證要開啟。到公開漏洞庫查詢這個插件是否有已知高危漏洞?？错?xiàng)目維護(hù)狀態(tài)最近一次提交是什么時間是否還有安全公告渠道。裁剪功能用不到的上傳、模板、演示文件全部刪掉。跑一次最小化測試只保留實(shí)際業(yè)務(wù)要用的路徑。清單看著繁瑣但真正發(fā)生供應(yīng)鏈問題的時候你會發(fā)現(xiàn)這七步每一條都是在救命的。4.3 插件權(quán)限最小化與部署隔離插件引入之后還要注意給它關(guān)權(quán)限。很多編輯器自帶上傳功能默認(rèn)上傳目錄放在Web根目錄里上傳文件直接可訪問。不做限制的話攻擊者一旦繞過文件類型檢查就能直接執(zhí)行腳本。我的做法是上傳目錄獨(dú)立出來只存儲文件禁止執(zhí)行腳本上傳目錄的PHP執(zhí)行權(quán)限在Web服務(wù)器層面直接關(guān)掉編輯器用不到的那些接口文件在部署時刪除插件依賴的數(shù)據(jù)庫賬號用獨(dú)立最小權(quán)限賬號不給DROP、GRANT這類高危權(quán)限。插件可以幫你干活但不給它鑰匙庫的鑰匙。這個原則推廣到整個留言板也一樣數(shù)據(jù)庫賬號不要用root要單獨(dú)建一個只對留言數(shù)據(jù)庫有增刪查改權(quán)限的賬號。權(quán)限最小化永遠(yuǎn)是安全開發(fā)的核心思維。5. 從零開始實(shí)現(xiàn)一個帶安全基線的留言板理論說多了都是空的進(jìn)入實(shí)操。我把留言板分成四個模塊實(shí)現(xiàn)每個模塊都會給出帶注釋的PHP代碼并解釋為什么這么寫。5.1 表結(jié)構(gòu)設(shè)計(jì)先建表。留言板業(yè)務(wù)只要一張 messages 表就夠但字段要夠用管理功能后面都要靠它。CREATE TABLE messages ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, username VARCHAR(30) NOT NULL, email VARCHAR(100) NOT NULL, content TEXT NOT NULL, ip VARCHAR(45) NOT NULL, user_agent VARCHAR(255) NOT NULL, status TINYINT NOT NULL DEFAULT 1, created_at DATETIME NOT NULL, PRIMARY KEY (id), KEY idx_status_created (status, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;幾個設(shè)計(jì)點(diǎn)說明一下。status 字段用來標(biāo)記留言審核狀態(tài)未過審的留言不對外展示這是內(nèi)容安全的兜底。ip 字段用 VARCHAR(45) 存雙棧地址IPv6 的地址長度也能放下。user_agent 字段不是必須的但留一個可以用于異常分析比如短時間內(nèi)同一UA加同一IP高頻發(fā)言就可以快速識別刷屏行為。5.2 發(fā)表留言模塊發(fā)表留言是數(shù)據(jù)入口攻擊者最關(guān)注這里。整個流程是校驗(yàn)CSRF Token然后校驗(yàn)輸入格式再做頻率限制最后寫入數(shù)據(jù)庫。提交處理的完整代碼session_start(); if (strtoupper($_SERVER[REQUEST_METHOD]) ! POST) { exit(非法訪問); } // 1. CSRF校驗(yàn) if (!hash_equals($_SESSION[csrf_token] ?? , $_POST[csrf_token] ?? )) { exit(CSRF校驗(yàn)失敗); } // 2. 輸入校驗(yàn) $username trim((string)($_POST[username] ?? )); $email trim((string)($_POST[email] ?? )); $content trim((string)($_POST[content] ?? )); if ($username || mb_strlen($username) 30) { exit(用戶名不能為空且不能超過30字); } if (!filter_var($email, FILTER_VALIDATE_EMAIL)) { exit(郵箱格式不正確); } if ($content || mb_strlen($content) 2000) { exit(留言內(nèi)容不能為空且不能超過2000字); } // 3. 頻率限制同一IP在60秒內(nèi)只能留言一次 $key gb_limit_ . md5($_SERVER[REMOTE_ADDR]); $last (int)($_SESSION[$key] ?? 0); if (time() - $last 60) { exit(留言過于頻繁請稍后再試); } $_SESSION[$key] time(); // 4. 參數(shù)化寫入 $ip $_SERVER[REMOTE_ADDR]; $ua substr((string)($_SERVER[HTTP_USER_AGENT] ?? ), 0, 254); $dsn mysql:host127.0.0.1;port3306;dbnameguestbook;charsetutf8mb4; $options [ PDO::ATTR_ERRMODE PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES false, ]; $pdo new PDO($dsn, gb_user, yourpassword, $options); $stmt $pdo-prepare( INSERT INTO messages (username, email, content, ip, user_agent, status, created_at) VALUES (?, ?, ?, ?, ?, 1, ?) ); $stmt-execute([ $username, $email, $content, $ip, $ua, date(Y-m-d H:i:s), ]); header(Location: list.php); exit;這段代碼把前面幾章的理念全部落地了。CSRF校驗(yàn)用的是 hash_equals 做時間安全比較比普通等號判斷更防側(cè)信道。輸入校驗(yàn)全部走白名單式的長度和格式判斷。頻率限制用會話變量做標(biāo)記簡單但有效想要更強(qiáng)的限制可以把記錄存到數(shù)據(jù)庫或內(nèi)存緩存。為什么CSRF校驗(yàn)必須放在最前面因?yàn)槿绻茸鰳I(yè)務(wù)判斷再校驗(yàn)Token攻擊者可以通過觀察不同的響應(yīng)時間差來判斷Token是否正確這等于給了側(cè)信道攻擊機(jī)會。先校驗(yàn)Token再處理業(yè)務(wù)錯誤提示統(tǒng)一攻擊者就無從分辨了。5.3 留言展示模塊留言展示是輸出側(cè)重點(diǎn)解決存儲型XSS。讀取數(shù)據(jù)用參數(shù)化查詢輸出內(nèi)容要經(jīng)過 htmlspecialchars 編碼一個地方都不能漏。$page max(1, (int)($_GET[page] ?? 1)); $perPage 10; $offset ($page - 1) * $perPage; $stmt $pdo-prepare( SELECT username, email, content, created_at FROM messages WHERE status 1 ORDER BY created_at DESC LIMIT ? OFFSET ? ); $stmt-bindValue(1, $perPage, PDO::PARAM_INT); $stmt-bindValue(2, $offset, PDO::PARAM_INT); $stmt-execute(); $rows $stmt-fetchAll();注意這里用了 bindValue 綁定 LIMIT 和 OFFSET是因?yàn)?PDO 的 execute 傳數(shù)組時默認(rèn)會把值當(dāng)成字符串而 LIMIT 語句里必須明確是整型不然在嚴(yán)格模式下會報(bào)錯。取數(shù)據(jù)只用參數(shù)化查詢配合 status1 過濾未審核留言。輸出的核心代碼foreach ($rows as $row) { echo h3 . htmlspecialchars($row[username], ENT_QUOTES, UTF-8) . /h3; echo p . htmlspecialchars($row[content], ENT_QUOTES, UTF-8) . /p; echo p . htmlspecialchars($row[created_at], ENT_QUOTES, UTF-8) . /p; }為什么用 htmlspecialchars 加 ENT_QUOTES因?yàn)閱我柡碗p引號都會被轉(zhuǎn)成實(shí)體在HTML上下文里就沒有構(gòu)造屬性、事件注入的機(jī)會。還有一點(diǎn)編碼時一定要指定 UTF-8否則默認(rèn)編碼可能導(dǎo)致實(shí)體轉(zhuǎn)換失敗等于防護(hù)失效。5.4 后臺管理模塊管理功能只有一個需求查看和刪除留言。不要小看這么簡單的后臺權(quán)限和CSRF一個都不能少。session_start(); // 管理員身份校驗(yàn) if (!isset($_SESSION[admin]) || $_SESSION[admin] ! true) { exit(無權(quán)限訪問); } if (strtoupper($_SERVER[REQUEST_METHOD]) POST) { if (!hash_equals($_SESSION[csrf_token] ?? , $_POST[csrf_token] ?? )) { exit(CSRF校驗(yàn)失敗); } $id (int)($_POST[id] ?? 0); if ($id 0) { exit(無效的留言ID); } $stmt $pdo-prepare(DELETE FROM messages WHERE id ?); $stmt-execute([$id]); }刪除操作用的還是參數(shù)化查詢。在后臺模塊里我加了一層身份校驗(yàn)確保只有管理員會話可以執(zhí)行刪除操作。管理頁面的表單里也要帶CSRF Token防止其他頁面的構(gòu)造請求冒充管理員刪除數(shù)據(jù)。這個模塊還隱含一個越權(quán)判斷刪除操作的權(quán)限校驗(yàn)放在POST分支之內(nèi)任何人只要能發(fā)起POST請求都要先通過身份和Token校驗(yàn)。順序是先認(rèn)證再授權(quán)再執(zhí)行業(yè)務(wù)三步缺一不可。6. 安全驗(yàn)證清單與測試方法功能寫完不算完安全開發(fā)必須走到驗(yàn)證環(huán)節(jié)。我有一套自己常用的測試用例表發(fā)布前過一遍能攔住絕大多數(shù)低級漏洞。6.1 十個必測用例整理成表格方便直接拿去用用例操作方法判定標(biāo)準(zhǔn)基礎(chǔ)SQL注入在留言內(nèi)容里提交單引號和典型閉合語句頁面正常顯示數(shù)據(jù)庫無異常報(bào)錯存儲型XSS提交帶script標(biāo)簽的HTML內(nèi)容頁面原樣顯示為文本不執(zhí)行腳本屬性型XSS提交帶onerror事件的img標(biāo)簽輸出時屬性轉(zhuǎn)義事件不觸發(fā)CSRF驗(yàn)證移除表單Token后再次提交提交被拒絕越權(quán)刪除非管理員會話直接POST刪除接口返回?zé)o權(quán)限提示超長輸入提交超過2000字的內(nèi)容被長度校驗(yàn)攔截類型注入把content字段提交為數(shù)組形式被類型校驗(yàn)攔截分頁注入修改page參數(shù)為非法字符串取整兜底頁面不報(bào)錯頻率刷屏短時間連續(xù)提交多條留言被限流攔截編碼繞過提交UTF-16或特殊空白字符統(tǒng)一按UTF-8編碼后正常顯示這里特別說一下編碼繞過。很多過濾邏輯只過濾了普通英文引號和括號但如果應(yīng)用和數(shù)據(jù)庫的字符集處理不一致攻擊者可以利用寬字節(jié)payload繞過。解決方法就是前面說的連接層強(qiáng)制UTF-8所有輸出指定UTF-8兩端字符集對齊后這類繞過基本失效。6.2 自動化檢查三件套人工測試能覆蓋主流程但還是建議配自動化檢查。我最常用的三件套第一php -l 做語法檢查排除低級語法錯誤。第二用包含常見payload的請求集做回歸測試每次改代碼后跑一遍。第三開啟應(yīng)用層的訪問日志和數(shù)據(jù)庫慢查詢?nèi)罩驹跍y試環(huán)境里模擬攻擊流量觀察異常。這三件套不復(fù)雜但足以攔住絕大多數(shù)因?yàn)樯暇€前倉促導(dǎo)致的低級問題。7. 常見問題排查與踩坑實(shí)錄到這里代碼和測試都講完了最后聊聊實(shí)操中一定會遇到的幾個問題。7.1 為什么表單提交后CSRF Token總是失效這是寫CSRF最容易遇到的問題。排查路徑一般是先看 session_start 有沒有在任何輸出之前調(diào)用再看表單里的Token是否來自同一個會話很多人會在兩個頁面分別生成新Token導(dǎo)致表單頁Token和校驗(yàn)頁Token不一致最后看跳轉(zhuǎn)邏輯如果提交后刷新頁面Token已經(jīng)被消費(fèi)或過期也會出現(xiàn)校驗(yàn)失敗。我的處理方式是Token在會話里只存一份表單和校驗(yàn)都讀同一個值提交成功后可以注銷Token要求刷新頁面重新生成避免重放攻擊。7.2 為什么留言內(nèi)容明明過濾了還是有XSS過濾了還是有XSS多半是輸出側(cè)出了問題。很多人只過濾了輸入側(cè)覺得壞東西已經(jīng)進(jìn)不來了卻忘了存儲型XSS的觸發(fā)點(diǎn)在輸出。如果過濾用的還是黑名單式正則防得住 script 標(biāo)簽但防不住 img 的 onerror、svg 的 onload、甚至CSS背景圖注入。解決方案是輸入側(cè)做邏輯校驗(yàn)輸出側(cè)做統(tǒng)一轉(zhuǎn)義兩條線同時存在互不替代。不要把輸出編碼的活全部交給輸入過濾因?yàn)檩敵鼍幋a才是真正的最后防線。7.3 頁面把數(shù)據(jù)庫錯誤信息給用戶看到了怎么辦報(bào)錯信息泄露是開發(fā)階段常見但上線前容易漏的坑?，F(xiàn)象是用戶提交異常數(shù)據(jù)后頁面直接打印SQL錯誤里面會帶表名、字段名甚至查詢片段這些信息會幫助攻擊者快速定位數(shù)據(jù)庫結(jié)構(gòu)。處理辦法是把PDO設(shè)置為異常模式后在入口位置統(tǒng)一捕獲異常錯誤詳情記錄到日志頁面只顯示友好的通用提示。線上環(huán)境把 display_errors 關(guān)掉日志級別保持 error這樣既能排查問題又不會把內(nèi)幕暴露給外部。7.4 引入插件后網(wǎng)站變慢變卡怎么定位第三方插件導(dǎo)致性能問題的排查思路比較直接。第一步是看請求日志找到耗時最長的請求第二步是確認(rèn)該請求是否進(jìn)了插件目錄第三步是檢查插件是否有數(shù)據(jù)庫查詢或遠(yuǎn)程請求。多數(shù)卡頓是因?yàn)椴寮诿看握埱髸r都執(zhí)行了無關(guān)的初始化代碼。我的建議是能靜態(tài)化的靜態(tài)化能懶加載的懶加載。留言列表頁用不著加載編輯器的時候就不要加載那幾百KB的腳本。功能最小化不僅為了安全也為了性能一舉兩得。寫到這里今天的留言板安全開發(fā)筆記算是閉環(huán)了。從超全局變量到數(shù)據(jù)庫操作從第三方插件引入到CSRF防護(hù)每個環(huán)節(jié)我都盡量把“為什么”背后的原理講清楚。我在實(shí)際動手過程里最大的感觸是安全開發(fā)不是某一招特別華麗而是每個環(huán)節(jié)都堅(jiān)持看似枯燥的規(guī)范來源明確、邊界清晰、權(quán)限最小、輸出編碼、參數(shù)化查詢。這些規(guī)范單拎出來都平平無奇但串在一起攻擊面就被壓縮得很干凈。最后再分享一個小技巧每次寫完一個功能都試著站在攻擊者的角度問自己一個問題——如果我是攻擊者我會怎么打這個功能順著這個角度走一遍很多漏洞根本不用掃描器就能自己暴露出來。留言板只是一個起點(diǎn)帶著這套思維去做下一個項(xiàng)目你會發(fā)現(xiàn)自己寫的代碼越來越難打。