1. 為什么每個開發(fā)者的書架上都該有一份OWASP Top 10如果你寫過哪怕一個帶登錄功能的頁面或者調(diào)過任何一個對外暴露的接口那你其實已經(jīng)在網(wǎng)絡(luò)安全的風(fēng)險敞口里了。很多剛?cè)胄械呐笥延X得“安全”是安全工程師的事自己只要把業(yè)務(wù)邏輯跑通就行。但現(xiàn)實情況是絕大多數(shù)被利用的漏洞都藏在最普通的業(yè)務(wù)代碼里——一個沒過濾的查詢參數(shù)、一個圖省事的字符串拼接、一個忘了加權(quán)限校驗的接口。OWASP Top 10 就是把這些“最容易被踩中”的坑按風(fēng)險和出現(xiàn)頻率整理出來的一份清單。它不是一本需要從頭讀到尾的教科書更像是一份“體檢表”你拿著它逐條對照自己的項目就能發(fā)現(xiàn)大部分顯而易見的問題。我剛開始接觸這塊的時候也覺得這十個名詞看著都認(rèn)識但真到代碼里就不知道從哪下手。后來踩過幾次坑才明白OWASP Top 10 的價值不在于讓你背下十個條目而在于幫你建立一種“攻擊者視角”——寫代碼的時候會下意識地想這個參數(shù)如果被人改了會怎樣這個接口如果被人直接調(diào)用會怎樣這份清單適合所有需要寫代碼、搭服務(wù)、做運維的人不管你是前端、后端還是全棧只要你的代碼跑在網(wǎng)絡(luò)上它就和你有關(guān)。接下來我會按“漏洞長什么樣、怎么被利用、代碼里怎么防、實際踩過什么坑”這個順序把每一類都拆開講清楚。2. 注入類漏洞當(dāng)你的查詢語句變成了攻擊者的提線木偶2.1 SQL注入的本質(zhì)是“代碼和數(shù)據(jù)沒分家”注入類漏洞常年霸占各類安全風(fēng)險榜單的前列原因很簡單它太容易出現(xiàn)了而且一旦出現(xiàn)后果往往很嚴(yán)重。所謂注入說白了就是攻擊者把你原本打算當(dāng)“數(shù)據(jù)”處理的內(nèi)容變成了“代碼”的一部分去執(zhí)行。最典型的就是SQL注入。假設(shè)你寫了一個登錄接口SQL語句是這樣拼的sql SELECT * FROM users WHERE username username AND password password 正常用戶輸入zhangsan和123456語句沒問題。但如果有人在用戶名框里輸入 OR 11整條語句就變成了SELECT * FROM users WHERE username OR 11 AND password 11永遠為真于是這條查詢會返回用戶表里的所有記錄攻擊者不需要知道任何密碼就能登錄。這就是注入的核心你用來拼接的字符串被對方當(dāng)成了SQL語法的一部分。2.2 參數(shù)化查詢?yōu)槭裁茨軓母旧辖鉀Q問題防注入最有效的手段就是參數(shù)化查詢也叫預(yù)編譯語句。它的原理是先把SQL語句的結(jié)構(gòu)發(fā)給數(shù)據(jù)庫編譯好占位符的位置留空然后再把用戶輸入的值填進去。這樣一來無論用戶輸入什么數(shù)據(jù)庫都只把它當(dāng)成一個“值”而不是“語法”。用Python的數(shù)據(jù)庫驅(qū)動舉例cursor.execute(SELECT * FROM users WHERE username %s AND password %s, (username, password))注意這里用的是%s占位符而不是字符串拼接。很多新手會問那我用ORM框架是不是就自動安全了大部分情況下是的但前提是你沒有在ORM里寫原生SQL。我見過有人在ORM里用raw()方法拼字符串那等于繞過了ORM的保護照樣會中招。所以關(guān)鍵不是用不用框架而是有沒有把“數(shù)據(jù)”和“指令”分開。2.3 命令注入和LDAP注入的隱蔽性更強除了SQL注入命令注入也很常見。比如你的程序需要調(diào)用系統(tǒng)命令去處理一個文件代碼寫成os.system(convert filename output.jpg)。如果攻擊者把文件名改成test.jpg; rm -rf /那系統(tǒng)在執(zhí)行完轉(zhuǎn)換之后還會額外執(zhí)行刪除命令。這種漏洞的可怕之處在于它直接操作服務(wù)器權(quán)限往往很高。防御方法和SQL注入類似盡量不要拼接命令如果必須調(diào)用外部程序用參數(shù)列表的方式傳參而不是拼成一個字符串。LDAP注入、XPath注入原理相通都是因為把用戶輸入直接嵌入了查詢語句。記住一個原則任何你拼接進“指令”里的用戶輸入都是潛在的注入點。3. 失效的身份認(rèn)證你的登錄邏輯真的經(jīng)得起推敲嗎3.1 弱密碼策略和暴力破解的邊界身份認(rèn)證出問題往往不是技術(shù)多復(fù)雜而是設(shè)計上偷了懶。最常見的就是允許用戶設(shè)置“123456”這種弱密碼或者登錄接口沒有任何頻率限制。攻擊者可以用一個字典每秒嘗試幾百次密碼如果你的系統(tǒng)不限制嘗試次數(shù)那破解只是時間問題。我見過一個內(nèi)部系統(tǒng)登錄接口連失敗次數(shù)都不記錄跑一個常用密碼字典十分鐘就試出了三個賬號。防御措施很直接強制密碼復(fù)雜度、限制登錄嘗試次數(shù)、失敗多次后鎖定賬號或加驗證碼。但這里有個平衡點——鎖定策略太激進會影響正常用戶太寬松又起不到防護作用。我的經(jīng)驗是連續(xù)失敗5次后加一個圖形驗證碼失敗10次后鎖定15分鐘這樣既能擋住自動化腳本又不會讓用戶太難受。3.2 Session和Token管理里的那些坑登錄成功之后怎么維持登錄狀態(tài)也有講究。有些系統(tǒng)把用戶ID直接存在Cookie里比如user_id1001而且不做任何簽名。攻擊者只要把1001改成1002就能以別人的身份操作。正確的做法是使用服務(wù)端生成的Session ID或者用簽名過的Token比如JWT。但JWT也不是萬能的我踩過一個坑JWT的簽名密鑰用了默認(rèn)值或者太簡單攻擊者可以自己偽造Token。還有一個常見問題是Token沒有設(shè)置過期時間一旦泄露就永久有效。所以Token里一定要有exp字段并且密鑰要足夠復(fù)雜最好定期輪換。3.3 多因素認(rèn)證不是萬能藥但能擋住大部分自動化攻擊多因素認(rèn)證MFA現(xiàn)在越來越普及它的邏輯是即使密碼泄露了攻擊者還需要第二個因素比如手機驗證碼、硬件密鑰才能登錄。這能有效擋住大部分自動化撞庫攻擊。但MFA也有自己的坑短信驗證碼可能被攔截而且有些系統(tǒng)在驗證MFA之前就把用戶信息返回給前端了這等于給了攻擊者一個“密碼正確”的信號。正確的流程應(yīng)該是密碼驗證通過后先不返回任何敏感信息只返回一個臨時的、一次性的憑證等MFA驗證通過后再正式建立會話。這個細(xì)節(jié)很多開發(fā)者會忽略但它在實際攻防中很關(guān)鍵。4. 敏感數(shù)據(jù)泄露與安全配置錯誤那些你以為沒人會看的角落4.1 數(shù)據(jù)在傳輸和存儲時到底該怎么保護敏感數(shù)據(jù)泄露的范圍很廣從用戶的手機號、身份證號到系統(tǒng)的API密鑰、數(shù)據(jù)庫密碼都屬于敏感數(shù)據(jù)。很多開發(fā)者覺得“我的系統(tǒng)又不出名沒人會盯著”但自動化掃描工具是不分目標(biāo)的它們會掃描整個IP段發(fā)現(xiàn)暴露的敏感信息就記錄下來。傳輸層面全站HTTPS現(xiàn)在是基本要求但要注意配置正確的TLS版本和加密套件老舊的SSLv3、TLS 1.0早就該禁用了。存儲層面密碼絕對不能明文存也不能用MD5或SHA1這種已經(jīng)被證明不安全的哈希算法。推薦用bcrypt、scrypt或者Argon2這類專門為密碼設(shè)計的算法它們計算慢能有效抵抗暴力破解。對于其他敏感數(shù)據(jù)比如身份證號如果業(yè)務(wù)上不需要完整展示可以考慮加密存儲或者脫敏展示。4.2 默認(rèn)配置和錯誤信息泄露的連鎖反應(yīng)安全配置錯誤是OWASP Top 10里覆蓋面最廣的一類因為它涉及的東西太多了默認(rèn)賬號密碼沒改、目錄列表沒關(guān)、錯誤堆棧直接返回給前端、云存儲桶權(quán)限設(shè)置成公開可讀……我見過一個案例某系統(tǒng)的數(shù)據(jù)庫管理后臺用了默認(rèn)的admin/admin而且端口直接暴露在公網(wǎng)上結(jié)果被自動化工具掃到整個數(shù)據(jù)庫被拖走。還有一個常見問題是錯誤信息泄露當(dāng)程序出錯時直接把完整的堆棧信息返回給前端里面可能包含數(shù)據(jù)庫連接字符串、文件路徑、框架版本號。攻擊者拿到這些信息就能針對性地找漏洞。正確的做法是生產(chǎn)環(huán)境關(guān)閉詳細(xì)錯誤輸出只給用戶一個通用的錯誤提示詳細(xì)的錯誤記錄到服務(wù)端日志里。4.3 依賴組件和API接口的“隱形”風(fēng)險現(xiàn)代項目很少從零寫起大部分都會引入第三方庫和框架。但這些依賴組件本身也可能有漏洞。比如某個常用的JSON解析庫出了反序列化漏洞所有用了這個庫的項目都受影響。所以定期檢查依賴組件的版本、關(guān)注安全公告是每個項目維護者的日常功課。API接口方面常見的問題是接口沒有做權(quán)限校驗或者返回了過多的數(shù)據(jù)。比如一個查詢用戶信息的接口本來只需要返回用戶名和頭像結(jié)果把手機號、郵箱、地址全返回了。攻擊者拿到這些數(shù)據(jù)可以進行精準(zhǔn)的釣魚攻擊。防御原則是接口只返回業(yè)務(wù)必需的最小數(shù)據(jù)集并且每個接口都要校驗當(dāng)前用戶是否有權(quán)限訪問。5. 從代碼到上線把安全左移的實操思路5.1 在開發(fā)階段就引入安全檢查很多團隊的安全工作是在上線前才做的這時候發(fā)現(xiàn)問題修復(fù)成本已經(jīng)很高了。更好的做法是把安全左移在開發(fā)階段就引入檢查。比如在代碼倉庫里配置靜態(tài)代碼掃描工具每次提交代碼時自動跑一遍發(fā)現(xiàn)明顯的注入、硬編碼密碼等問題就報警。還可以在代碼審查清單里加入安全項這個接口有沒有做權(quán)限校驗這個參數(shù)有沒有做輸入驗證這個SQL是不是參數(shù)化的這些檢查不需要安全專家來做普通開發(fā)者花幾分鐘就能完成。我自己的習(xí)慣是寫完一個接口后先自己用工具掃一遍再提交給同事審查這樣能提前發(fā)現(xiàn)大部分低級問題。5.2 上線前的安全測試怎么做才有效上線前的安全測試不一定要買昂貴的商業(yè)掃描器。開源的漏洞掃描工具配合手工測試就能覆蓋大部分常見問題。自動化掃描器可以快速發(fā)現(xiàn)配置錯誤、已知漏洞、弱密碼等問題但它對業(yè)務(wù)邏輯漏洞的發(fā)現(xiàn)能力有限。所以手工測試很重要重點測這幾個地方登錄、注冊、密碼重置、支付、文件上傳、權(quán)限切換。測試的時候要站在攻擊者的角度想如果我是一個惡意用戶我會怎么繞過限制比如文件上傳功能我能不能上傳一個腳本文件權(quán)限切換功能我能不能通過修改請求參數(shù)訪問別人的數(shù)據(jù)這些測試不需要很深的專業(yè)知識但需要細(xì)心和耐心。5.3 上線后的監(jiān)控和應(yīng)急響應(yīng)系統(tǒng)上線不代表安全工作就結(jié)束了。你需要有監(jiān)控機制能發(fā)現(xiàn)異常的訪問模式。比如某個IP在短時間內(nèi)大量請求登錄接口或者某個賬號在異地登錄這些都應(yīng)該觸發(fā)告警。日志要記錄關(guān)鍵操作但注意不要把敏感信息寫進日志比如密碼、Token。萬一真的發(fā)生了安全事件要有應(yīng)急響應(yīng)流程先隔離受影響的服務(wù)再分析日志定位問題然后修復(fù)漏洞并通知受影響的用戶。這個過程最好提前演練一遍免得到時候手忙腳亂。我經(jīng)歷過一次小規(guī)模的數(shù)據(jù)泄露就是因為沒有提前準(zhǔn)備應(yīng)急流程發(fā)現(xiàn)漏洞后花了很長時間才搞清楚影響范圍教訓(xùn)很深刻。6. 那些年我踩過的安全坑和總結(jié)出的經(jīng)驗6.1 不要相信任何客戶端傳來的數(shù)據(jù)這是我踩過的最大的坑。早期做項目的時候我覺得前端已經(jīng)做了輸入驗證后端就不用再做了。結(jié)果有人直接繞過前端用工具構(gòu)造請求把惡意數(shù)據(jù)發(fā)到了后端。從那以后我養(yǎng)成了一個習(xí)慣所有來自客戶端的數(shù)據(jù)不管是表單、URL參數(shù)、HTTP頭還是Cookie一律在后端重新驗證一遍。驗證的內(nèi)容包括數(shù)據(jù)類型對不對、長度有沒有超限、格式是否符合預(yù)期、有沒有包含特殊字符。這個習(xí)慣看起來麻煩但能擋住大部分注入和越權(quán)問題。6.2 權(quán)限校驗要放在每一個接口里另一個常見的坑是權(quán)限校驗遺漏。比如一個系統(tǒng)有普通用戶和管理員兩種角色大部分接口都做了角色校驗但有一個查詢接口忘了加結(jié)果普通用戶可以通過這個接口看到所有用戶的數(shù)據(jù)。這種問題在代碼審查時很難發(fā)現(xiàn)因為接口本身邏輯沒問題只是少了一行校驗代碼。我的做法是把權(quán)限校驗做成一個統(tǒng)一的攔截器或中間件所有接口默認(rèn)都需要登錄需要特定角色的接口再單獨聲明。這樣就不會因為疏忽而漏掉某個接口。6.3 安全是一個持續(xù)的過程而不是一次性的任務(wù)最后想說的是安全不是做完一次滲透測試就萬事大吉了。新的漏洞不斷出現(xiàn)業(yè)務(wù)代碼也在不斷變化今天安全的設(shè)計明天可能就因為新功能而變得不安全。所以要把安全檢查融入到日常開發(fā)流程里每次代碼提交都跑一遍掃描每次上線前都做一次安全測試定期更新依賴組件關(guān)注安全社區(qū)的最新動態(tài)。這些工作看起來瑣碎但比起被攻擊后造成的損失這些投入是值得的。我在實際項目中的體會是安全做得好的團隊往往也是代碼質(zhì)量高、工程規(guī)范好的團隊因為兩者背后的思維方式是一樣的嚴(yán)謹(jǐn)、細(xì)致、不抱僥幸心理。