誤到Web安全實(shí)戰(zhàn)：SQL注入、XSS與SSRF防御指南)
1. 從一次“意外”的502錯(cuò)誤說起那天下午我正在調(diào)試一個(gè)內(nèi)部服務(wù)。本地環(huán)境跑得好好的前端頁(yè)面一調(diào)用某個(gè)API接口瀏覽器控制臺(tái)就彈出一個(gè)刺眼的紅色錯(cuò)誤unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。相信不少開發(fā)同學(xué)都見過類似的報(bào)錯(cuò)第一反應(yīng)往往是“后端服務(wù)掛了”或者“Nginx配置錯(cuò)了”。我檢查了后端服務(wù)進(jìn)程運(yùn)行正常查看了Nginx日志也沒有明顯的錯(cuò)誤。問題出在哪經(jīng)過一番排查最終定位到是服務(wù)間通信時(shí)一個(gè)上游服務(wù)因?yàn)檎?qǐng)求參數(shù)被惡意構(gòu)造導(dǎo)致了進(jìn)程崩潰進(jìn)而觸發(fā)了網(wǎng)關(guān)的502錯(cuò)誤。這個(gè)“惡意構(gòu)造”的參數(shù)本質(zhì)上就是一個(gè)非常初級(jí)的SQL注入攻擊。這件事讓我感觸很深。我們常常把“Web安全”想象成防火墻、WAFWeb應(yīng)用防火墻這些運(yùn)維或安全團(tuán)隊(duì)負(fù)責(zé)的“高大上”的東西覺得離日常業(yè)務(wù)開發(fā)很遠(yuǎn)。但實(shí)際上很多安全問題就源于我們寫的一行行業(yè)務(wù)代碼。那個(gè)導(dǎo)致502錯(cuò)誤的注入點(diǎn)可能就是某位同事在趕工期時(shí)圖省事直接拼接了SQL語(yǔ)句。unexpected status 502 bad gateway這個(gè)錯(cuò)誤本身不是漏洞但它像是一個(gè)“癥狀”背后隱藏的可能是SQL注入、SSRF服務(wù)器端請(qǐng)求偽造甚至是因過濾不嚴(yán)導(dǎo)致的資源耗盡等問題。所以今天我想拋開那些復(fù)雜的學(xué)術(shù)定義和龐雜的安全體系就從一個(gè)一線開發(fā)者的視角聊聊Web安全里最基礎(chǔ)、最常見但也最要命的幾個(gè)“老朋友”HTTP/HTTPS、SQL注入、XSS跨站腳本和SSRF。我會(huì)結(jié)合像ctfshow、ctfhub這類實(shí)戰(zhàn)靶場(chǎng)中常見的套路以及開發(fā)中真實(shí)遇到的坑比如配置http客戶端卻訪問了https的phpmyadmin導(dǎo)致的failed to set session cookie問題把這些知識(shí)揉碎了講明白它們到底是怎么發(fā)生的我們?cè)撊绾卧诖a層面就“御敵于國(guó)門之外”。2. 一切的基礎(chǔ)HTTP與HTTPS不只是“S”的區(qū)別我們每天開發(fā)的Web應(yīng)用都跑在HTTP超文本傳輸協(xié)議或HTTPSHTTP Secure之上。很多人對(duì)它們的理解停留在“HTTPS更安全是加密的HTTP”。這個(gè)說法沒錯(cuò)但太籠統(tǒng)了。理解它們之間的區(qū)別是理解很多Web攻擊手法的前提。2.1 HTTP的“透明”與風(fēng)險(xiǎn)HTTP協(xié)議是明文傳輸?shù)?。這意味著從你的瀏覽器到服務(wù)器之間所有數(shù)據(jù)包括URL、請(qǐng)求頭、Cookie尤其是POST請(qǐng)求體里的用戶名和密碼就像一張明信片途徑的任何一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)比如咖啡館的Wi-Fi路由器、運(yùn)營(yíng)商網(wǎng)關(guān)都能看得一清二楚。這就是為什么在公共網(wǎng)絡(luò)下登錄不使用HTTPS的網(wǎng)站是極度危險(xiǎn)的行為。除了竊聽HTTP還面臨篡改和冒充的風(fēng)險(xiǎn)。攻擊者可以攔截你的請(qǐng)求修改其中的內(nèi)容比如將轉(zhuǎn)賬金額從100元改成10000元或者偽裝成目標(biāo)網(wǎng)站與你通信中間人攻擊。你可能會(huì)想我的網(wǎng)站就是個(gè)內(nèi)部系統(tǒng)不對(duì)外網(wǎng)開放用HTTP沒問題吧這里就引出一個(gè)常見的配置錯(cuò)誤。在部署諸如phpMyAdmin、Jenkins這類Web管理界面時(shí)我們有時(shí)會(huì)圖方便直接用HTTP訪問。但如果你的Web服務(wù)器或反向代理如Nginx配置了強(qiáng)制HTTPS跳轉(zhuǎn)或者應(yīng)用本身對(duì)Cookie設(shè)置了Secure屬性要求僅通過HTTPS傳輸那么通過HTTP訪問就會(huì)出問題。就像錯(cuò)誤提示failed to set session cookie. maybe you are using http instead of https to access phpmyadmin.所說你明明登錄了但會(huì)話Cookie無法被瀏覽器保存或發(fā)送導(dǎo)致一直處于“未登錄”狀態(tài)。這雖然是個(gè)配置問題但從安全角度看它強(qiáng)制了安全通道的使用是好事。2.2 HTTPS如何構(gòu)建安全通道HTTPS并非一個(gè)新的協(xié)議而是在HTTP和TCP之間加入了一個(gè)安全層——TLS/SSL協(xié)議。這個(gè)協(xié)議主要干了三件大事加密通過對(duì)稱加密算法如AES對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密即使被截獲也是亂碼。認(rèn)證通過數(shù)字證書驗(yàn)證服務(wù)器的身份。你瀏覽器地址欄的小鎖圖標(biāo)就代表當(dāng)前連接的服務(wù)器的證書是受信任的機(jī)構(gòu)頒發(fā)的你確實(shí)在訪問“真正的”百度或谷歌而不是一個(gè)山寨網(wǎng)站。完整性校驗(yàn)通過消息認(rèn)證碼MAC確保數(shù)據(jù)在傳輸過程中沒有被篡改。所以將網(wǎng)站從HTTP升級(jí)到HTTPS是Web安全最基礎(chǔ)、最重要的一步。它不僅保護(hù)用戶數(shù)據(jù)也關(guān)乎搜索引擎排名Google對(duì)HTTPS網(wǎng)站有排名加成和現(xiàn)代瀏覽器API的調(diào)用資格如地理位置、Service Worker等。2.3 開發(fā)中的HTTP客戶端安全在我們的后端代碼中經(jīng)常需要扮演“客戶端”的角色去調(diào)用其他服務(wù)的HTTP/HTTPS接口。這里就藏著SSRF的隱患我們稍后會(huì)詳細(xì)講。但首先一個(gè)基礎(chǔ)的安全實(shí)踐是務(wù)必驗(yàn)證和限制出站請(qǐng)求。當(dāng)你使用HttpClientJava、requestsPython、axiosJavaScript等庫(kù)時(shí)默認(rèn)它們可能是“信任”你所提供的URL的。但如果你從用戶輸入中動(dòng)態(tài)拼接了URL比如一個(gè)讓用戶輸入頭像鏈接的功能就必須警惕協(xié)議限制只允許http://或https://開頭的URL。防止類似file:///etc/passwd讀取服務(wù)器本地文件或gopher://利用舊協(xié)議進(jìn)行攻擊的惡意協(xié)議。目標(biāo)限制避免請(qǐng)求內(nèi)網(wǎng)IP段如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16和本地回環(huán)地址127.0.0.1,localhost。這是防止SSRF攻擊內(nèi)網(wǎng)服務(wù)的關(guān)鍵。響應(yīng)處理對(duì)返回的數(shù)據(jù)大小、類型做限制。防止服務(wù)器返回一個(gè)巨大的文件拖慢你的服務(wù)或者將響應(yīng)內(nèi)容直接輸出到頁(yè)面而引發(fā)新的XSS。一個(gè)常見的反面教材是某些配置或腳本中允許用戶輸入完整的URL如某些爬蟲或代理配置。如果過濾不嚴(yán)攻擊者可以輸入http://127.0.0.1:8080/admin/deleteAll這樣的地址讓你的服務(wù)器從內(nèi)部攻擊自己。3. 數(shù)據(jù)庫(kù)的“刺客”SQL注入詳解與實(shí)戰(zhàn)防御回到開頭那個(gè)引發(fā)502錯(cuò)誤的罪魁禍?zhǔn)住猄QL注入。它常年位居OWASP Top 10開放式Web應(yīng)用程序安全項(xiàng)目十大安全風(fēng)險(xiǎn)前列原理簡(jiǎn)單危害極大可以導(dǎo)致數(shù)據(jù)庫(kù)信息泄露、數(shù)據(jù)篡改、甚至服務(wù)器被完全控制。3.1 SQL注入是如何發(fā)生的它的本質(zhì)是“數(shù)據(jù)被當(dāng)成了代碼執(zhí)行”。我們來看一段經(jīng)典的錯(cuò)誤代碼以PHP為例$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);看起來很正常如果用戶老實(shí)地輸入用戶名admin和密碼123456SQL語(yǔ)句是SELECT * FROM users WHERE username admin AND password 123456但如果用戶在用戶名輸入框里輸入的是admin --注意最后有個(gè)空格那么拼接后的SQL語(yǔ)句就變成了SELECT * FROM users WHERE username admin -- AND password ...在SQL中--是注釋符它會(huì)把后面的語(yǔ)句都注釋掉。這意味著攻擊者無需知道密碼就能以管理員身份登錄這就是所謂的“萬能密碼”繞過的一種形式。更危險(xiǎn)的攻擊是使用UNION查詢。假設(shè)用戶輸入 UNION SELECT username, password FROM users --那么原查詢可能變成SELECT id, name FROM products WHERE id UNION SELECT username, password FROM users -- 這樣攻擊者就能把用戶表的敏感信息直接“聯(lián)合查詢”出來顯示在頁(yè)面上。在ctfshow、sql注入靶場(chǎng)等練習(xí)平臺(tái)上你會(huì)遇到各種過濾和限制比如過濾了空格、union、select等關(guān)鍵詞。這時(shí)就需要用到各種繞過技巧比如用/**/代替空格用ununionion繞過簡(jiǎn)單的union關(guān)鍵詞刪除刪除后變成union用select的十六進(jìn)制編碼0x73656c656374等等。這些技巧的核心思路就是利用WAF或簡(jiǎn)單過濾規(guī)則的缺陷讓惡意SQL“變形”后依然能被數(shù)據(jù)庫(kù)解析。3.2 如何徹底防御SQL注入防御的核心原則就是讓代碼和數(shù)據(jù)分家。永遠(yuǎn)不要相信用戶輸入永遠(yuǎn)不要拼接SQL語(yǔ)句。使用參數(shù)化查詢預(yù)編譯語(yǔ)句這是最重要、最有效的手段。幾乎所有現(xiàn)代編程語(yǔ)言和數(shù)據(jù)庫(kù)驅(qū)動(dòng)都支持。Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); // 參數(shù)1綁定用戶名 stmt.setString(2, password); // 參數(shù)2綁定密碼 ResultSet rs stmt.executeQuery();Python (sqlite3):cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);它的原理是數(shù)據(jù)庫(kù)引擎會(huì)先編譯SQL語(yǔ)句的結(jié)構(gòu)SELECT * FROM users WHERE username ? AND password ?這個(gè)結(jié)構(gòu)是固定的。之后傳入的參數(shù)username,password會(huì)被嚴(yán)格視為數(shù)據(jù)無論里面包含什么引號(hào)、分號(hào)、SQL關(guān)鍵詞都不會(huì)改變?cè)Z(yǔ)句的結(jié)構(gòu)從而從根本上杜絕注入。使用ORM框架像MyBatis注意要使用#{}而非${}、Hibernate、Django ORM、Sequelize等它們底層通常也使用參數(shù)化查詢能提供更安全的數(shù)據(jù)庫(kù)操作方式。嚴(yán)格的輸入驗(yàn)證雖然不能替代參數(shù)化查詢但作為輔助手段很有用。例如對(duì)于已知是數(shù)字的ID參數(shù)如/product?id123在代碼里強(qiáng)制轉(zhuǎn)換為整數(shù)類型int productId Integer.parseInt(request.getParameter(id))這樣即使攻擊者傳入id1 OR 11也會(huì)在轉(zhuǎn)換時(shí)拋出異常而不是傳入數(shù)據(jù)庫(kù)。最小權(quán)限原則連接數(shù)據(jù)庫(kù)的應(yīng)用程序賬號(hào)不應(yīng)該擁有DROP TABLE、DELETE *等高危權(quán)限。通常只賦予SELECT、INSERT、UPDATE等必要權(quán)限這樣即使發(fā)生注入危害也能被限制。注意有些古老的教程或代碼中會(huì)推薦使用“轉(zhuǎn)義”用戶輸入如PHP的mysqli_real_escape_string。這種方法容易出錯(cuò)需要知道數(shù)據(jù)庫(kù)字符集且對(duì)于數(shù)字注入無效不推薦作為主要防御手段參數(shù)化查詢才是黃金標(biāo)準(zhǔn)。4. 前端頁(yè)面里的“幽靈”XSS攻擊與防護(hù)如果說SQL注入是攻擊數(shù)據(jù)庫(kù)那么XSS跨站腳本攻擊就是攻擊訪問網(wǎng)頁(yè)的用戶。它的原理同樣是“數(shù)據(jù)被當(dāng)成了代碼執(zhí)行”只不過這個(gè)“代碼”是JavaScript執(zhí)行環(huán)境是用戶的瀏覽器。4.1 XSS的三種主要類型反射型XSS攻擊腳本“反射”在URL中。常見于搜索框、錯(cuò)誤信息提示頁(yè)。比如一個(gè)搜索功能將用戶輸入的關(guān)鍵詞直接顯示在結(jié)果頁(yè)p您搜索的關(guān)鍵詞是?php echo $_GET[q]; ?/p。如果用戶訪問一個(gè)構(gòu)造好的鏈接http://example.com/search?qscriptalert(XSS)/script那么這段腳本就會(huì)在用戶的瀏覽器中執(zhí)行。反射型XSS通常需要誘導(dǎo)用戶點(diǎn)擊惡意鏈接。存儲(chǔ)型XSS攻擊腳本被“存儲(chǔ)”在服務(wù)器上如數(shù)據(jù)庫(kù)、評(píng)論內(nèi)容當(dāng)其他用戶瀏覽到該頁(yè)面時(shí)自動(dòng)執(zhí)行。比如一個(gè)論壇的評(píng)論功能如果沒有過濾攻擊者可以提交一條包含script.../script的評(píng)論。此后所有查看這條評(píng)論的用戶都會(huì)中招。危害最大因?yàn)樗浅志眯缘?。DOM型XSS漏洞存在于前端JavaScript代碼中不經(jīng)過服務(wù)器。例如一段不安全的JS代碼從URL的hash部分#后面獲取數(shù)據(jù)并動(dòng)態(tài)寫入頁(yè)面var data decodeURIComponent(location.hash.substr(1)); document.getElementById(message).innerHTML data;攻擊者可以構(gòu)造URLhttp://example.com/page#img srcx onerroralert(XSS)導(dǎo)致腳本執(zhí)行。在ctfshow、ctfhub的XSS挑戰(zhàn)中你會(huì)遇到各種過濾比如將、轉(zhuǎn)義成lt;、gt;這就是所謂的尖括號(hào)轉(zhuǎn)義。繞過的方法包括利用事件處理器img srcx onerroralert(1)不需要閉合標(biāo)簽。利用JavaScript偽協(xié)議a hrefjavascript:alert(1)click/a。在DOM型XSS中如果innerHTML被轉(zhuǎn)義可以嘗試innerText或document.write等不同的輸出點(diǎn)。4.2 如何有效防御XSS防御XSS的核心是區(qū)分“數(shù)據(jù)”和“代碼”對(duì)用戶輸入進(jìn)行正確的編碼/轉(zhuǎn)義并設(shè)置嚴(yán)格的內(nèi)容安全策略。對(duì)輸出進(jìn)行編碼HTML轉(zhuǎn)義這是最普適的防御措施。在將不可信數(shù)據(jù)輸出到HTML頁(yè)面時(shí)必須根據(jù)上下文進(jìn)行編碼。輸出到HTML標(biāo)簽內(nèi)容textContent將,,,,分別轉(zhuǎn)義為amp;,lt;,gt;,quot;,#x27;。幾乎所有后端模板引擎如Thymeleaf, Freemarker, Jinja2都默認(rèn)開啟或提供了自動(dòng)轉(zhuǎn)義功能。輸出到HTML屬性值除了上述字符空格也需要視情況處理。最好總是用引號(hào)包裹屬性值。輸出到JavaScript代碼或事件處理器如onclick這非常危險(xiǎn)應(yīng)盡量避免。如果必須需使用JavaScript專用的編碼如\uXXXX形式的Unicode轉(zhuǎn)義。輸出到URL如果用戶輸入要作為URL的一部分需要使用URL編碼如encodeURIComponent。實(shí)操心得不要試圖用黑名單過濾script、onerror等來防御XSS繞過方法太多。堅(jiān)持使用白名單只允許安全的標(biāo)簽和屬性如富文本編輯器場(chǎng)景和上下文相關(guān)的編碼才是正道。使用現(xiàn)代前端框架React、Vue、Angular等框架在設(shè)計(jì)上就考慮了XSS防護(hù)。它們默認(rèn)會(huì)對(duì)渲染到DOM中的數(shù)據(jù)進(jìn)行轉(zhuǎn)義。例如在React中使用{}插入變量是安全的但使用dangerouslySetInnerHTML就需要你格外小心確保內(nèi)容可信。設(shè)置Content-Security-PolicyCSP這是一個(gè)強(qiáng)大的瀏覽器安全特性通過HTTP響應(yīng)頭來告訴瀏覽器哪些外部資源腳本、樣式、圖片、字體等可以被加載和執(zhí)行。一個(gè)嚴(yán)格的CSP可以極大地緩解XSS的影響。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;這個(gè)策略表示默認(rèn)只允許加載同源資源腳本只允許同源和指定的CDN樣式允許同源和內(nèi)聯(lián)樣式unsafe-inline是寬松策略理想情況應(yīng)避免。即使攻擊者成功注入了script標(biāo)簽如果該腳本的源不在白名單內(nèi)瀏覽器也不會(huì)執(zhí)行它。使用HttpOnly Cookie將敏感的會(huì)話Cookie標(biāo)記為HttpOnlySet-Cookie: sessionIdabc123; HttpOnly這樣JavaScript就無法通過document.cookie訪問它。即使網(wǎng)站存在XSS漏洞攻擊者也無法直接竊取用戶的會(huì)話憑證。5. 讓服務(wù)器“內(nèi)訌”SSRF漏洞剖析SSRF服務(wù)器端請(qǐng)求偽造是一種由攻擊者構(gòu)造請(qǐng)求讓服務(wù)器向內(nèi)部或外部的任意地址發(fā)起請(qǐng)求的攻擊。它危害巨大因?yàn)楣粽呖梢岳檬苄湃蔚姆?wù)器作為跳板去探測(cè)或攻擊內(nèi)網(wǎng)中那些本應(yīng)被防火墻保護(hù)的服務(wù)。5.1 SSRF的常見觸發(fā)場(chǎng)景與危害功能設(shè)計(jì)缺陷很多Web應(yīng)用提供了“網(wǎng)頁(yè)抓取”、“URL預(yù)覽”、“文件導(dǎo)入”、“網(wǎng)絡(luò)診斷”等功能。例如一個(gè)社交網(wǎng)站允許用戶輸入頭像URL服務(wù)器會(huì)去抓取這個(gè)URL的圖片并保存。如果這個(gè)功能沒有對(duì)URL做任何限制攻擊者就可以輸入file:///etc/passwd來讀取服務(wù)器本地文件或者輸入http://192.168.1.1/admin來探測(cè)內(nèi)網(wǎng)管理后臺(tái)。引用外部資源比如在Markdown編輯器里插入圖片如果服務(wù)器為了生成縮略圖或驗(yàn)證圖片會(huì)主動(dòng)去請(qǐng)求這個(gè)URL。利用協(xié)議和URL解析差異這是SSRF攻擊中非常狡猾的一點(diǎn)。攻擊者可以利用瀏覽器、服務(wù)器、庫(kù)之間對(duì)URL解析的差異來繞過防御。利用符號(hào)http://expected-hostattacker-host。一些舊的解析器可能會(huì)將前面的部分認(rèn)為是認(rèn)證信息實(shí)際請(qǐng)求的是attacker-host。利用IPv6地址和[]http://[::ffff:127.0.0.1]:8080可能被解析為訪問本地環(huán)回地址。利用DNS重綁定攻擊者控制一個(gè)域名其DNS記錄TTL極短。第一次解析時(shí)返回一個(gè)合法的外網(wǎng)IP通過校驗(yàn)服務(wù)器發(fā)起請(qǐng)求時(shí)DNS再次解析返回一個(gè)內(nèi)網(wǎng)IP如127.0.0.1從而成功攻擊內(nèi)網(wǎng)。這就是所謂的“未知SSRF”或需要高級(jí)技巧的SSRF。它的危害包括攻擊內(nèi)網(wǎng)服務(wù)掃描內(nèi)網(wǎng)存活主機(jī)和端口攻擊Redis、MySQL、Memcached等未授權(quán)訪問的內(nèi)網(wǎng)服務(wù)。讀取本地文件利用file://、gopher://、dict://等協(xié)議。繞過認(rèn)證如果內(nèi)網(wǎng)應(yīng)用采用IP白名單或基礎(chǔ)認(rèn)證服務(wù)器發(fā)起請(qǐng)求時(shí)會(huì)自動(dòng)帶上這些信任關(guān)系。5.2 防御SSRF的層層設(shè)防防御SSRF需要從多個(gè)層面共同構(gòu)建防線因?yàn)楣粽呖倳?huì)尋找最薄弱的一環(huán)。輸入校驗(yàn)與白名單這是第一道也是最重要的防線。協(xié)議白名單只允許http://和https://。明確拒絕file://、gopher://、dict://、ftp://等危險(xiǎn)協(xié)議。目標(biāo)地址黑名單/白名單黑名單禁止請(qǐng)求內(nèi)網(wǎng)IP、回環(huán)地址127.0.0.1、localhost、鏈路本地地址169.254.0.0/16等。但黑名單可能被繞過如用127.0.0.1.nip.io域名解析到本地。白名單推薦如果業(yè)務(wù)明確只允許請(qǐng)求有限的、已知可信的外部域名或IP。這是最安全的方式。統(tǒng)一出口與網(wǎng)絡(luò)隔離設(shè)置網(wǎng)絡(luò)訪問控制運(yùn)行Web應(yīng)用的服務(wù)器DMZ區(qū)與核心內(nèi)網(wǎng)業(yè)務(wù)服務(wù)器如數(shù)據(jù)庫(kù)之間應(yīng)設(shè)置嚴(yán)格的防火墻策略限制DMZ區(qū)服務(wù)器對(duì)內(nèi)網(wǎng)的訪問權(quán)限遵循最小權(quán)限原則。使用專用出站代理所有需要外發(fā)請(qǐng)求的服務(wù)統(tǒng)一通過一個(gè)配置了嚴(yán)格白名單的代理服務(wù)器進(jìn)行。這樣即使應(yīng)用層存在漏洞網(wǎng)絡(luò)層的限制也能起到作用。響應(yīng)處理限制服務(wù)器請(qǐng)求的響應(yīng)時(shí)間、響應(yīng)大小防止被用于發(fā)起DoS攻擊或讀取大文件。不要將請(qǐng)求的原始響應(yīng)內(nèi)容直接返回給前端用戶。如果業(yè)務(wù)需要如URL預(yù)覽應(yīng)對(duì)返回的內(nèi)容如圖片、文本進(jìn)行嚴(yán)格的檢查和過濾防止成為XSS等攻擊的二傳手。代碼層面使用安全的庫(kù)使用諸如url.parseNode.js注意舊版本有問題、Java的URI類等標(biāo)準(zhǔn)庫(kù)來解析URL并仔細(xì)檢查解析后的host、protocol等屬性避免使用正則表達(dá)式做簡(jiǎn)單的匹配容易出錯(cuò)。6. 實(shí)戰(zhàn)中的組合拳與縱深防御在實(shí)際的滲透測(cè)試或CTF比賽中漏洞往往不是孤立存在的。攻擊者會(huì)像玩解謎游戲一樣將各種基礎(chǔ)漏洞組合起來形成一條完整的攻擊鏈攻擊路徑。一個(gè)假設(shè)的攻擊場(chǎng)景攻擊者首先發(fā)現(xiàn)一個(gè)反射型XSS漏洞但無法直接竊取Cookie因?yàn)樵O(shè)置了HttpOnly。他利用這個(gè)XSS讓受害者的瀏覽器向網(wǎng)站內(nèi)部一個(gè)存在SSRF漏洞的端點(diǎn)發(fā)起請(qǐng)求因?yàn)闉g覽器發(fā)起的請(qǐng)求會(huì)攜帶用戶的Cookie所以這個(gè)請(qǐng)求是“已認(rèn)證”的。這個(gè)SSRF漏洞被用來攻擊內(nèi)網(wǎng)的一個(gè)Redis服務(wù)未設(shè)置密碼。通過構(gòu)造特定協(xié)議的數(shù)據(jù)包如使用gopher協(xié)議攻擊者可以向Redis寫入數(shù)據(jù)。攻擊者將一條惡意的PHP代碼寫入網(wǎng)站服務(wù)器的臨時(shí)目錄并通過Redis配置使Web服務(wù)器將其作為PHP文件執(zhí)行最終獲得一個(gè)Webshell完全控制服務(wù)器。這個(gè)鏈條里XSS是入口SSRF是橋梁內(nèi)網(wǎng)未授權(quán)訪問的Redis是目標(biāo)。防御這樣的攻擊就需要縱深防御思想在每一個(gè)環(huán)節(jié)都設(shè)置防護(hù)即使一道防線被突破還有其他防線阻止攻擊者達(dá)成最終目標(biāo)。第一層安全編碼。做好輸入驗(yàn)證、輸出編碼使用參數(shù)化查詢杜絕SQL注入和XSS的產(chǎn)生。第二層應(yīng)用配置。設(shè)置嚴(yán)格的CSP、HttpOnly Cookie使用最小權(quán)限的數(shù)據(jù)庫(kù)賬戶。第三層服務(wù)器與網(wǎng)絡(luò)配置。及時(shí)更新系統(tǒng)和中間件補(bǔ)丁配置嚴(yán)格的防火墻規(guī)則隔離網(wǎng)絡(luò)區(qū)域。第四層安全監(jiān)控與響應(yīng)。部署WAF、IDS/IPS監(jiān)控異常日志如大量502錯(cuò)誤、異常的本地請(qǐng)求建立應(yīng)急響應(yīng)流程。Web安全不是一個(gè)可以“一鍵修復(fù)”的模塊它需要開發(fā)、運(yùn)維、測(cè)試各個(gè)角色在軟件生命周期的每個(gè)階段都保持安全意識(shí)。從寫出第一行安全的代碼開始到設(shè)計(jì)一個(gè)安全的架構(gòu)再到部署時(shí)進(jìn)行安全的配置每一步都算數(shù)。別再讓那個(gè)unexpected status 502 bad gateway的錯(cuò)誤成為你系統(tǒng)被攻破的第一次警報(bào)。 從502錯(cuò)誤到Web安全實(shí)戰(zhàn)：SQL注入、XSS與SSRF防御指南
1. 從一次“意外”的502錯(cuò)誤說起那天下午我正在調(diào)試一個(gè)內(nèi)部服務(wù)。本地環(huán)境跑得好好的前端頁(yè)面一調(diào)用某個(gè)API接口瀏覽器控制臺(tái)就彈出一個(gè)刺眼的紅色錯(cuò)誤unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。相信不少開發(fā)同學(xué)都見過類似的報(bào)錯(cuò)第一反應(yīng)往往是“后端服務(wù)掛了”或者“Nginx配置錯(cuò)了”。我檢查了后端服務(wù)進(jìn)程運(yùn)行正常查看了Nginx日志也沒有明顯的錯(cuò)誤。問題出在哪經(jīng)過一番排查最終定位到是服務(wù)間通信時(shí)一個(gè)上游服務(wù)因?yàn)檎?qǐng)求參數(shù)被惡意構(gòu)造導(dǎo)致了進(jìn)程崩潰進(jìn)而觸發(fā)了網(wǎng)關(guān)的502錯(cuò)誤。這個(gè)“惡意構(gòu)造”的參數(shù)本質(zhì)上就是一個(gè)非常初級(jí)的SQL注入攻擊。這件事讓我感觸很深。我們常常把“Web安全”想象成防火墻、WAFWeb應(yīng)用防火墻這些運(yùn)維或安全團(tuán)隊(duì)負(fù)責(zé)的“高大上”的東西覺得離日常業(yè)務(wù)開發(fā)很遠(yuǎn)。但實(shí)際上很多安全問題就源于我們寫的一行行業(yè)務(wù)代碼。那個(gè)導(dǎo)致502錯(cuò)誤的注入點(diǎn)可能就是某位同事在趕工期時(shí)圖省事直接拼接了SQL語(yǔ)句。unexpected status 502 bad gateway這個(gè)錯(cuò)誤本身不是漏洞但它像是一個(gè)“癥狀”背后隱藏的可能是SQL注入、SSRF服務(wù)器端請(qǐng)求偽造甚至是因過濾不嚴(yán)導(dǎo)致的資源耗盡等問題。所以今天我想拋開那些復(fù)雜的學(xué)術(shù)定義和龐雜的安全體系就從一個(gè)一線開發(fā)者的視角聊聊Web安全里最基礎(chǔ)、最常見但也最要命的幾個(gè)“老朋友”HTTP/HTTPS、SQL注入、XSS跨站腳本和SSRF。我會(huì)結(jié)合像ctfshow、ctfhub這類實(shí)戰(zhàn)靶場(chǎng)中常見的套路以及開發(fā)中真實(shí)遇到的坑比如配置http客戶端卻訪問了https的phpmyadmin導(dǎo)致的failed to set session cookie問題把這些知識(shí)揉碎了講明白它們到底是怎么發(fā)生的我們?cè)撊绾卧诖a層面就“御敵于國(guó)門之外”。2. 一切的基礎(chǔ)HTTP與HTTPS不只是“S”的區(qū)別我們每天開發(fā)的Web應(yīng)用都跑在HTTP超文本傳輸協(xié)議或HTTPSHTTP Secure之上。很多人對(duì)它們的理解停留在“HTTPS更安全是加密的HTTP”。這個(gè)說法沒錯(cuò)但太籠統(tǒng)了。理解它們之間的區(qū)別是理解很多Web攻擊手法的前提。2.1 HTTP的“透明”與風(fēng)險(xiǎn)HTTP協(xié)議是明文傳輸?shù)?。這意味著從你的瀏覽器到服務(wù)器之間所有數(shù)據(jù)包括URL、請(qǐng)求頭、Cookie尤其是POST請(qǐng)求體里的用戶名和密碼就像一張明信片途徑的任何一個(gè)網(wǎng)絡(luò)節(jié)點(diǎn)比如咖啡館的Wi-Fi路由器、運(yùn)營(yíng)商網(wǎng)關(guān)都能看得一清二楚。這就是為什么在公共網(wǎng)絡(luò)下登錄不使用HTTPS的網(wǎng)站是極度危險(xiǎn)的行為。除了竊聽HTTP還面臨篡改和冒充的風(fēng)險(xiǎn)。攻擊者可以攔截你的請(qǐng)求修改其中的內(nèi)容比如將轉(zhuǎn)賬金額從100元改成10000元或者偽裝成目標(biāo)網(wǎng)站與你通信中間人攻擊。你可能會(huì)想我的網(wǎng)站就是個(gè)內(nèi)部系統(tǒng)不對(duì)外網(wǎng)開放用HTTP沒問題吧這里就引出一個(gè)常見的配置錯(cuò)誤。在部署諸如phpMyAdmin、Jenkins這類Web管理界面時(shí)我們有時(shí)會(huì)圖方便直接用HTTP訪問。但如果你的Web服務(wù)器或反向代理如Nginx配置了強(qiáng)制HTTPS跳轉(zhuǎn)或者應(yīng)用本身對(duì)Cookie設(shè)置了Secure屬性要求僅通過HTTPS傳輸那么通過HTTP訪問就會(huì)出問題。就像錯(cuò)誤提示failed to set session cookie. maybe you are using http instead of https to access phpmyadmin.所說你明明登錄了但會(huì)話Cookie無法被瀏覽器保存或發(fā)送導(dǎo)致一直處于“未登錄”狀態(tài)。這雖然是個(gè)配置問題但從安全角度看它強(qiáng)制了安全通道的使用是好事。2.2 HTTPS如何構(gòu)建安全通道HTTPS并非一個(gè)新的協(xié)議而是在HTTP和TCP之間加入了一個(gè)安全層——TLS/SSL協(xié)議。這個(gè)協(xié)議主要干了三件大事加密通過對(duì)稱加密算法如AES對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行加密即使被截獲也是亂碼。認(rèn)證通過數(shù)字證書驗(yàn)證服務(wù)器的身份。你瀏覽器地址欄的小鎖圖標(biāo)就代表當(dāng)前連接的服務(wù)器的證書是受信任的機(jī)構(gòu)頒發(fā)的你確實(shí)在訪問“真正的”百度或谷歌而不是一個(gè)山寨網(wǎng)站。完整性校驗(yàn)通過消息認(rèn)證碼MAC確保數(shù)據(jù)在傳輸過程中沒有被篡改。所以將網(wǎng)站從HTTP升級(jí)到HTTPS是Web安全最基礎(chǔ)、最重要的一步。它不僅保護(hù)用戶數(shù)據(jù)也關(guān)乎搜索引擎排名Google對(duì)HTTPS網(wǎng)站有排名加成和現(xiàn)代瀏覽器API的調(diào)用資格如地理位置、Service Worker等。2.3 開發(fā)中的HTTP客戶端安全在我們的后端代碼中經(jīng)常需要扮演“客戶端”的角色去調(diào)用其他服務(wù)的HTTP/HTTPS接口。這里就藏著SSRF的隱患我們稍后會(huì)詳細(xì)講。但首先一個(gè)基礎(chǔ)的安全實(shí)踐是務(wù)必驗(yàn)證和限制出站請(qǐng)求。當(dāng)你使用HttpClientJava、requestsPython、axiosJavaScript等庫(kù)時(shí)默認(rèn)它們可能是“信任”你所提供的URL的。但如果你從用戶輸入中動(dòng)態(tài)拼接了URL比如一個(gè)讓用戶輸入頭像鏈接的功能就必須警惕協(xié)議限制只允許http://或https://開頭的URL。防止類似file:///etc/passwd讀取服務(wù)器本地文件或gopher://利用舊協(xié)議進(jìn)行攻擊的惡意協(xié)議。目標(biāo)限制避免請(qǐng)求內(nèi)網(wǎng)IP段如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16和本地回環(huán)地址127.0.0.1,localhost。這是防止SSRF攻擊內(nèi)網(wǎng)服務(wù)的關(guān)鍵。響應(yīng)處理對(duì)返回的數(shù)據(jù)大小、類型做限制。防止服務(wù)器返回一個(gè)巨大的文件拖慢你的服務(wù)或者將響應(yīng)內(nèi)容直接輸出到頁(yè)面而引發(fā)新的XSS。一個(gè)常見的反面教材是某些配置或腳本中允許用戶輸入完整的URL如某些爬蟲或代理配置。如果過濾不嚴(yán)攻擊者可以輸入http://127.0.0.1:8080/admin/deleteAll這樣的地址讓你的服務(wù)器從內(nèi)部攻擊自己。3. 數(shù)據(jù)庫(kù)的“刺客”SQL注入詳解與實(shí)戰(zhàn)防御回到開頭那個(gè)引發(fā)502錯(cuò)誤的罪魁禍?zhǔn)住猄QL注入。它常年位居OWASP Top 10開放式Web應(yīng)用程序安全項(xiàng)目十大安全風(fēng)險(xiǎn)前列原理簡(jiǎn)單危害極大可以導(dǎo)致數(shù)據(jù)庫(kù)信息泄露、數(shù)據(jù)篡改、甚至服務(wù)器被完全控制。3.1 SQL注入是如何發(fā)生的它的本質(zhì)是“數(shù)據(jù)被當(dāng)成了代碼執(zhí)行”。我們來看一段經(jīng)典的錯(cuò)誤代碼以PHP為例$username $_POST[username]; $password $_POST[password]; $sql SELECT * FROM users WHERE username $username AND password $password; $result mysqli_query($conn, $sql);看起來很正常如果用戶老實(shí)地輸入用戶名admin和密碼123456SQL語(yǔ)句是SELECT * FROM users WHERE username admin AND password 123456但如果用戶在用戶名輸入框里輸入的是admin --注意最后有個(gè)空格那么拼接后的SQL語(yǔ)句就變成了SELECT * FROM users WHERE username admin -- AND password ...在SQL中--是注釋符它會(huì)把后面的語(yǔ)句都注釋掉。這意味著攻擊者無需知道密碼就能以管理員身份登錄這就是所謂的“萬能密碼”繞過的一種形式。更危險(xiǎn)的攻擊是使用UNION查詢。假設(shè)用戶輸入 UNION SELECT username, password FROM users --那么原查詢可能變成SELECT id, name FROM products WHERE id UNION SELECT username, password FROM users -- 這樣攻擊者就能把用戶表的敏感信息直接“聯(lián)合查詢”出來顯示在頁(yè)面上。在ctfshow、sql注入靶場(chǎng)等練習(xí)平臺(tái)上你會(huì)遇到各種過濾和限制比如過濾了空格、union、select等關(guān)鍵詞。這時(shí)就需要用到各種繞過技巧比如用/**/代替空格用ununionion繞過簡(jiǎn)單的union關(guān)鍵詞刪除刪除后變成union用select的十六進(jìn)制編碼0x73656c656374等等。這些技巧的核心思路就是利用WAF或簡(jiǎn)單過濾規(guī)則的缺陷讓惡意SQL“變形”后依然能被數(shù)據(jù)庫(kù)解析。3.2 如何徹底防御SQL注入防御的核心原則就是讓代碼和數(shù)據(jù)分家。永遠(yuǎn)不要相信用戶輸入永遠(yuǎn)不要拼接SQL語(yǔ)句。使用參數(shù)化查詢預(yù)編譯語(yǔ)句這是最重要、最有效的手段。幾乎所有現(xiàn)代編程語(yǔ)言和數(shù)據(jù)庫(kù)驅(qū)動(dòng)都支持。Java (JDBC):String sql SELECT * FROM users WHERE username ? AND password ?; PreparedStatement stmt connection.prepareStatement(sql); stmt.setString(1, username); // 參數(shù)1綁定用戶名 stmt.setString(2, password); // 參數(shù)2綁定密碼 ResultSet rs stmt.executeQuery();Python (sqlite3):cursor.execute(SELECT * FROM users WHERE username ? AND password ?, (username, password))PHP (PDO):$stmt $pdo-prepare(SELECT * FROM users WHERE username :username AND password :password); $stmt-execute([username $username, password $password]);它的原理是數(shù)據(jù)庫(kù)引擎會(huì)先編譯SQL語(yǔ)句的結(jié)構(gòu)SELECT * FROM users WHERE username ? AND password ?這個(gè)結(jié)構(gòu)是固定的。之后傳入的參數(shù)username,password會(huì)被嚴(yán)格視為數(shù)據(jù)無論里面包含什么引號(hào)、分號(hào)、SQL關(guān)鍵詞都不會(huì)改變?cè)Z(yǔ)句的結(jié)構(gòu)從而從根本上杜絕注入。使用ORM框架像MyBatis注意要使用#{}而非${}、Hibernate、Django ORM、Sequelize等它們底層通常也使用參數(shù)化查詢能提供更安全的數(shù)據(jù)庫(kù)操作方式。嚴(yán)格的輸入驗(yàn)證雖然不能替代參數(shù)化查詢但作為輔助手段很有用。例如對(duì)于已知是數(shù)字的ID參數(shù)如/product?id123在代碼里強(qiáng)制轉(zhuǎn)換為整數(shù)類型int productId Integer.parseInt(request.getParameter(id))這樣即使攻擊者傳入id1 OR 11也會(huì)在轉(zhuǎn)換時(shí)拋出異常而不是傳入數(shù)據(jù)庫(kù)。最小權(quán)限原則連接數(shù)據(jù)庫(kù)的應(yīng)用程序賬號(hào)不應(yīng)該擁有DROP TABLE、DELETE *等高危權(quán)限。通常只賦予SELECT、INSERT、UPDATE等必要權(quán)限這樣即使發(fā)生注入危害也能被限制。注意有些古老的教程或代碼中會(huì)推薦使用“轉(zhuǎn)義”用戶輸入如PHP的mysqli_real_escape_string。這種方法容易出錯(cuò)需要知道數(shù)據(jù)庫(kù)字符集且對(duì)于數(shù)字注入無效不推薦作為主要防御手段參數(shù)化查詢才是黃金標(biāo)準(zhǔn)。4. 前端頁(yè)面里的“幽靈”XSS攻擊與防護(hù)如果說SQL注入是攻擊數(shù)據(jù)庫(kù)那么XSS跨站腳本攻擊就是攻擊訪問網(wǎng)頁(yè)的用戶。它的原理同樣是“數(shù)據(jù)被當(dāng)成了代碼執(zhí)行”只不過這個(gè)“代碼”是JavaScript執(zhí)行環(huán)境是用戶的瀏覽器。4.1 XSS的三種主要類型反射型XSS攻擊腳本“反射”在URL中。常見于搜索框、錯(cuò)誤信息提示頁(yè)。比如一個(gè)搜索功能將用戶輸入的關(guān)鍵詞直接顯示在結(jié)果頁(yè)p您搜索的關(guān)鍵詞是?php echo $_GET[q]; ?/p。如果用戶訪問一個(gè)構(gòu)造好的鏈接http://example.com/search?qscriptalert(XSS)/script那么這段腳本就會(huì)在用戶的瀏覽器中執(zhí)行。反射型XSS通常需要誘導(dǎo)用戶點(diǎn)擊惡意鏈接。存儲(chǔ)型XSS攻擊腳本被“存儲(chǔ)”在服務(wù)器上如數(shù)據(jù)庫(kù)、評(píng)論內(nèi)容當(dāng)其他用戶瀏覽到該頁(yè)面時(shí)自動(dòng)執(zhí)行。比如一個(gè)論壇的評(píng)論功能如果沒有過濾攻擊者可以提交一條包含script.../script的評(píng)論。此后所有查看這條評(píng)論的用戶都會(huì)中招。危害最大因?yàn)樗浅志眯缘?。DOM型XSS漏洞存在于前端JavaScript代碼中不經(jīng)過服務(wù)器。例如一段不安全的JS代碼從URL的hash部分#后面獲取數(shù)據(jù)并動(dòng)態(tài)寫入頁(yè)面var data decodeURIComponent(location.hash.substr(1)); document.getElementById(message).innerHTML data;攻擊者可以構(gòu)造URLhttp://example.com/page#img srcx onerroralert(XSS)導(dǎo)致腳本執(zhí)行。在ctfshow、ctfhub的XSS挑戰(zhàn)中你會(huì)遇到各種過濾比如將、轉(zhuǎn)義成lt;、gt;這就是所謂的尖括號(hào)轉(zhuǎn)義。繞過的方法包括利用事件處理器img srcx onerroralert(1)不需要閉合標(biāo)簽。利用JavaScript偽協(xié)議a hrefjavascript:alert(1)click/a。在DOM型XSS中如果innerHTML被轉(zhuǎn)義可以嘗試innerText或document.write等不同的輸出點(diǎn)。4.2 如何有效防御XSS防御XSS的核心是區(qū)分“數(shù)據(jù)”和“代碼”對(duì)用戶輸入進(jìn)行正確的編碼/轉(zhuǎn)義并設(shè)置嚴(yán)格的內(nèi)容安全策略。對(duì)輸出進(jìn)行編碼HTML轉(zhuǎn)義這是最普適的防御措施。在將不可信數(shù)據(jù)輸出到HTML頁(yè)面時(shí)必須根據(jù)上下文進(jìn)行編碼。輸出到HTML標(biāo)簽內(nèi)容textContent將,,,,分別轉(zhuǎn)義為amp;,lt;,gt;,quot;,#x27;。幾乎所有后端模板引擎如Thymeleaf, Freemarker, Jinja2都默認(rèn)開啟或提供了自動(dòng)轉(zhuǎn)義功能。輸出到HTML屬性值除了上述字符空格也需要視情況處理。最好總是用引號(hào)包裹屬性值。輸出到JavaScript代碼或事件處理器如onclick這非常危險(xiǎn)應(yīng)盡量避免。如果必須需使用JavaScript專用的編碼如\uXXXX形式的Unicode轉(zhuǎn)義。輸出到URL如果用戶輸入要作為URL的一部分需要使用URL編碼如encodeURIComponent。實(shí)操心得不要試圖用黑名單過濾script、onerror等來防御XSS繞過方法太多。堅(jiān)持使用白名單只允許安全的標(biāo)簽和屬性如富文本編輯器場(chǎng)景和上下文相關(guān)的編碼才是正道。使用現(xiàn)代前端框架React、Vue、Angular等框架在設(shè)計(jì)上就考慮了XSS防護(hù)。它們默認(rèn)會(huì)對(duì)渲染到DOM中的數(shù)據(jù)進(jìn)行轉(zhuǎn)義。例如在React中使用{}插入變量是安全的但使用dangerouslySetInnerHTML就需要你格外小心確保內(nèi)容可信。設(shè)置Content-Security-PolicyCSP這是一個(gè)強(qiáng)大的瀏覽器安全特性通過HTTP響應(yīng)頭來告訴瀏覽器哪些外部資源腳本、樣式、圖片、字體等可以被加載和執(zhí)行。一個(gè)嚴(yán)格的CSP可以極大地緩解XSS的影響。Content-Security-Policy: default-src self; script-src self https://trusted.cdn.com; style-src self unsafe-inline;這個(gè)策略表示默認(rèn)只允許加載同源資源腳本只允許同源和指定的CDN樣式允許同源和內(nèi)聯(lián)樣式unsafe-inline是寬松策略理想情況應(yīng)避免。即使攻擊者成功注入了script標(biāo)簽如果該腳本的源不在白名單內(nèi)瀏覽器也不會(huì)執(zhí)行它。使用HttpOnly Cookie將敏感的會(huì)話Cookie標(biāo)記為HttpOnlySet-Cookie: sessionIdabc123; HttpOnly這樣JavaScript就無法通過document.cookie訪問它。即使網(wǎng)站存在XSS漏洞攻擊者也無法直接竊取用戶的會(huì)話憑證。5. 讓服務(wù)器“內(nèi)訌”SSRF漏洞剖析SSRF服務(wù)器端請(qǐng)求偽造是一種由攻擊者構(gòu)造請(qǐng)求讓服務(wù)器向內(nèi)部或外部的任意地址發(fā)起請(qǐng)求的攻擊。它危害巨大因?yàn)楣粽呖梢岳檬苄湃蔚姆?wù)器作為跳板去探測(cè)或攻擊內(nèi)網(wǎng)中那些本應(yīng)被防火墻保護(hù)的服務(wù)。5.1 SSRF的常見觸發(fā)場(chǎng)景與危害功能設(shè)計(jì)缺陷很多Web應(yīng)用提供了“網(wǎng)頁(yè)抓取”、“URL預(yù)覽”、“文件導(dǎo)入”、“網(wǎng)絡(luò)診斷”等功能。例如一個(gè)社交網(wǎng)站允許用戶輸入頭像URL服務(wù)器會(huì)去抓取這個(gè)URL的圖片并保存。如果這個(gè)功能沒有對(duì)URL做任何限制攻擊者就可以輸入file:///etc/passwd來讀取服務(wù)器本地文件或者輸入http://192.168.1.1/admin來探測(cè)內(nèi)網(wǎng)管理后臺(tái)。引用外部資源比如在Markdown編輯器里插入圖片如果服務(wù)器為了生成縮略圖或驗(yàn)證圖片會(huì)主動(dòng)去請(qǐng)求這個(gè)URL。利用協(xié)議和URL解析差異這是SSRF攻擊中非常狡猾的一點(diǎn)。攻擊者可以利用瀏覽器、服務(wù)器、庫(kù)之間對(duì)URL解析的差異來繞過防御。利用符號(hào)http://expected-hostattacker-host。一些舊的解析器可能會(huì)將前面的部分認(rèn)為是認(rèn)證信息實(shí)際請(qǐng)求的是attacker-host。利用IPv6地址和[]http://[::ffff:127.0.0.1]:8080可能被解析為訪問本地環(huán)回地址。利用DNS重綁定攻擊者控制一個(gè)域名其DNS記錄TTL極短。第一次解析時(shí)返回一個(gè)合法的外網(wǎng)IP通過校驗(yàn)服務(wù)器發(fā)起請(qǐng)求時(shí)DNS再次解析返回一個(gè)內(nèi)網(wǎng)IP如127.0.0.1從而成功攻擊內(nèi)網(wǎng)。這就是所謂的“未知SSRF”或需要高級(jí)技巧的SSRF。它的危害包括攻擊內(nèi)網(wǎng)服務(wù)掃描內(nèi)網(wǎng)存活主機(jī)和端口攻擊Redis、MySQL、Memcached等未授權(quán)訪問的內(nèi)網(wǎng)服務(wù)。讀取本地文件利用file://、gopher://、dict://等協(xié)議。繞過認(rèn)證如果內(nèi)網(wǎng)應(yīng)用采用IP白名單或基礎(chǔ)認(rèn)證服務(wù)器發(fā)起請(qǐng)求時(shí)會(huì)自動(dòng)帶上這些信任關(guān)系。5.2 防御SSRF的層層設(shè)防防御SSRF需要從多個(gè)層面共同構(gòu)建防線因?yàn)楣粽呖倳?huì)尋找最薄弱的一環(huán)。輸入校驗(yàn)與白名單這是第一道也是最重要的防線。協(xié)議白名單只允許http://和https://。明確拒絕file://、gopher://、dict://、ftp://等危險(xiǎn)協(xié)議。目標(biāo)地址黑名單/白名單黑名單禁止請(qǐng)求內(nèi)網(wǎng)IP、回環(huán)地址127.0.0.1、localhost、鏈路本地地址169.254.0.0/16等。但黑名單可能被繞過如用127.0.0.1.nip.io域名解析到本地。白名單推薦如果業(yè)務(wù)明確只允許請(qǐng)求有限的、已知可信的外部域名或IP。這是最安全的方式。統(tǒng)一出口與網(wǎng)絡(luò)隔離設(shè)置網(wǎng)絡(luò)訪問控制運(yùn)行Web應(yīng)用的服務(wù)器DMZ區(qū)與核心內(nèi)網(wǎng)業(yè)務(wù)服務(wù)器如數(shù)據(jù)庫(kù)之間應(yīng)設(shè)置嚴(yán)格的防火墻策略限制DMZ區(qū)服務(wù)器對(duì)內(nèi)網(wǎng)的訪問權(quán)限遵循最小權(quán)限原則。使用專用出站代理所有需要外發(fā)請(qǐng)求的服務(wù)統(tǒng)一通過一個(gè)配置了嚴(yán)格白名單的代理服務(wù)器進(jìn)行。這樣即使應(yīng)用層存在漏洞網(wǎng)絡(luò)層的限制也能起到作用。響應(yīng)處理限制服務(wù)器請(qǐng)求的響應(yīng)時(shí)間、響應(yīng)大小防止被用于發(fā)起DoS攻擊或讀取大文件。不要將請(qǐng)求的原始響應(yīng)內(nèi)容直接返回給前端用戶。如果業(yè)務(wù)需要如URL預(yù)覽應(yīng)對(duì)返回的內(nèi)容如圖片、文本進(jìn)行嚴(yán)格的檢查和過濾防止成為XSS等攻擊的二傳手。代碼層面使用安全的庫(kù)使用諸如url.parseNode.js注意舊版本有問題、Java的URI類等標(biāo)準(zhǔn)庫(kù)來解析URL并仔細(xì)檢查解析后的host、protocol等屬性避免使用正則表達(dá)式做簡(jiǎn)單的匹配容易出錯(cuò)。6. 實(shí)戰(zhàn)中的組合拳與縱深防御在實(shí)際的滲透測(cè)試或CTF比賽中漏洞往往不是孤立存在的。攻擊者會(huì)像玩解謎游戲一樣將各種基礎(chǔ)漏洞組合起來形成一條完整的攻擊鏈攻擊路徑。一個(gè)假設(shè)的攻擊場(chǎng)景攻擊者首先發(fā)現(xiàn)一個(gè)反射型XSS漏洞但無法直接竊取Cookie因?yàn)樵O(shè)置了HttpOnly。他利用這個(gè)XSS讓受害者的瀏覽器向網(wǎng)站內(nèi)部一個(gè)存在SSRF漏洞的端點(diǎn)發(fā)起請(qǐng)求因?yàn)闉g覽器發(fā)起的請(qǐng)求會(huì)攜帶用戶的Cookie所以這個(gè)請(qǐng)求是“已認(rèn)證”的。這個(gè)SSRF漏洞被用來攻擊內(nèi)網(wǎng)的一個(gè)Redis服務(wù)未設(shè)置密碼。通過構(gòu)造特定協(xié)議的數(shù)據(jù)包如使用gopher協(xié)議攻擊者可以向Redis寫入數(shù)據(jù)。攻擊者將一條惡意的PHP代碼寫入網(wǎng)站服務(wù)器的臨時(shí)目錄并通過Redis配置使Web服務(wù)器將其作為PHP文件執(zhí)行最終獲得一個(gè)Webshell完全控制服務(wù)器。這個(gè)鏈條里XSS是入口SSRF是橋梁內(nèi)網(wǎng)未授權(quán)訪問的Redis是目標(biāo)。防御這樣的攻擊就需要縱深防御思想在每一個(gè)環(huán)節(jié)都設(shè)置防護(hù)即使一道防線被突破還有其他防線阻止攻擊者達(dá)成最終目標(biāo)。第一層安全編碼。做好輸入驗(yàn)證、輸出編碼使用參數(shù)化查詢杜絕SQL注入和XSS的產(chǎn)生。第二層應(yīng)用配置。設(shè)置嚴(yán)格的CSP、HttpOnly Cookie使用最小權(quán)限的數(shù)據(jù)庫(kù)賬戶。第三層服務(wù)器與網(wǎng)絡(luò)配置。及時(shí)更新系統(tǒng)和中間件補(bǔ)丁配置嚴(yán)格的防火墻規(guī)則隔離網(wǎng)絡(luò)區(qū)域。第四層安全監(jiān)控與響應(yīng)。部署WAF、IDS/IPS監(jiān)控異常日志如大量502錯(cuò)誤、異常的本地請(qǐng)求建立應(yīng)急響應(yīng)流程。Web安全不是一個(gè)可以“一鍵修復(fù)”的模塊它需要開發(fā)、運(yùn)維、測(cè)試各個(gè)角色在軟件生命周期的每個(gè)階段都保持安全意識(shí)。從寫出第一行安全的代碼開始到設(shè)計(jì)一個(gè)安全的架構(gòu)再到部署時(shí)進(jìn)行安全的配置每一步都算數(shù)。別再讓那個(gè)unexpected status 502 bad gateway的錯(cuò)誤成為你系統(tǒng)被攻破的第一次警報(bào)。