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