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)程運(yù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)用防火墻這些運(yùn)維或安全團(tuán)隊負(fù)責(zé)的“高大上”的東西覺得離日常業(yè)務(wù)開發(fā)很遠(yuǎn)。但實際上很多安全問題就源于我們寫的一行行業(yè)務(wù)代碼。那個導(dǎo)致502錯誤的注入點(diǎn)可能就是某位同事在趕工期時圖省事直接拼接了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é)點(diǎn)比如咖啡館的Wi-Fi路由器、運(yùn)營商網(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配置了強(qiáng)制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)。這雖然是個配置問題但從安全角度看它強(qiáng)制了安全通道的使用是好事。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ù)器的證書是受信任的機(jī)構(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在代碼里強(qiáng)制轉(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)用戶點(diǎn)擊惡意鏈接。存儲型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等不同的輸出點(diǎn)。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這是一個強(qiáng)大的瀏覽器安全特性通過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攻擊中非常狡猾的一點(diǎn)。攻擊者可以利用瀏覽器、服務(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)存活主機(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ā)起請求時會自動帶上這些信任關(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ò)訪問控制運(yùn)行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漏洞的端點(diǎn)發(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)和中間件補(bǔ)丁配置嚴(yán)格的防火墻規(guī)則隔離網(wǎng)絡(luò)區(qū)域。第四層安全監(jiān)控與響應(yīng)。部署WAF、IDS/IPS監(jiān)控異常日志如大量502錯誤、異常的本地請求建立應(yīng)急響應(yīng)流程。Web安全不是一個可以“一鍵修復(fù)”的模塊它需要開發(fā)、運(yùn)維、測試各個角色在軟件生命周期的每個階段都保持安全意識。從寫出第一行安全的代碼開始到設(shè)計一個安全的架構(gòu)再到部署時進(jìn)行安全的配置每一步都算數(shù)。別再讓那個unexpected status 502 bad gateway的錯誤成為你系統(tǒng)被攻破的第一次警報。