Web開發者一定要懂的駭客攻防術

 

在工作上一直都是擔任後端應用的職務，即便是目前負責的大數據與推薦引擎，依舊是歸屬在後端運算的範疇。然而在Web/HTTP影響力與日俱增的大環境下，單單開發一個API也擺脫不掉SOAP/REST這樣依附在HTTP協定的軟體架構風格。因此針對Web的安全性議題，是不分前、後端工程師都得認真學習、思考的核心知識。Web開發者一定要懂的駭客攻防術是一本堪稱完美的Web資安入門書，流暢又精確的文字內容，在資訊類型的書中相當罕見（IT類型的書多半文字用詞繞口，也會有一兩個勘誤）。全書分成必要的基礎知識和常見威脅兩部份，很完整又詳細地解說，Web應用程式是什麼？有哪些常見的漏洞？（更重要的是）如何防止哪些漏洞？

雖然駭客攻擊聽起來總是神秘莫測，令人聯想到諜報電影裡相當高上大的設備與工具。但比較落地的實情是，多數讓駭客入侵成功的程式漏洞，總數加起來不會超過手指數量（小提醒，是十）。這些可以一一細數的程式瑕疵，造成這麼多企業、個人的財務損失，起因常常是開發團隊沒有能力處理（知識不足）或低估資安漏洞的嚴重性。藉由研讀Web開發者一定要懂的駭客攻防術，足於讓從業人員認識、理解Web開發時應留意的重點，進而打造出有高防禦力的Web應用。想若所有開發者都被要求要通過此書提及的漏洞攻防國家測驗，才能從事Web程式開發職務（類似駕照考試），網路世界在這群有著資安DNA的工程師們推動之下，相信未來駭客產業將會大受打擊。

下列心得就針對第二部份常見威脅的內容，進行概略的重點整理，也方便未來回過頭來查閱。

1.注入攻擊
起因：
　程式中使用SQL語法查詢資料庫；程式中執行作業系統指令。
手法：
　利用外部可以輸入的介面或檔案上傳功能，將攻擊用的字串與檔案（WebShell）傳送到程式主機，並觸發予以攻擊
防止：
　SQL注入：唯一作法是採用參數化語句或是ORM技術。如果無法修改程式，至少要做到最小權限原則，讓程式只擁有最少的必要權限，將傷害減到最低。
　避免傳回暴露過多資訊的傳回值，例如此帳號不存在，而是採用模糊的回應，例如找不到此帳號和密碼。
　命令注入：如果無法避免支援執行作業系統指令的功能，一定要將控制字元轉義，並採用白名單限制可以被執行的命令。
　遠端程式碼執行：不要直接使用未經檢查的序列化／反序列化的資料來當輸入值，並留意伺服器軟體的漏洞，以即時修補。
　檔案上傳漏洞：最好直接將檔案放在CDN雲端服務中，將風險轉移到雲端業者。不然就確保上傳的檔案無法被執行（無執行權），並進行強制的檔案轉製（圖檔／文字檔）。

2.跨腳本攻擊（XSS）
起因：
　程式中有接受外部輸入的進入點，卻沒有將HTML控制字元轉義。
手法：
　儲存型XSS：將惡意JavaScript藉由輸入功能（例如FB、留言板），儲存到系統資料庫中。
　反射型XSS：將惡意JavaScript藉由輸入參數加在電子郵件／網頁的超連結中，誘使受害者點擊。
　DOM型XSS：將惡意JavaScript加在URL中的URI片段中，讓沒有防護JavaScript前端程式（網站本身的程式碼）誤讀並執行惡意功能。
防止：
　一律將外部輸入值進行HTML字元轉義，特別是"&'<>等控制符號。
　使用內容安全原則（CSP）HTTP回應標頭功能，可指定只允許同站台與apis.google.com的JavaScript來源（<script src="..."/>），不允許內聯（inline)的JavaScript，設定方法如下：
　Content-Security-Policy: script-src 'self' https://apis.google.com
　也可以用HTTP <meta>標題來設定，方法如下：
　<meta http-content="Content-Security-Policy" content="script-src" 'self' https://apis.google.com">
　DOM型XSS：在使用URL字串時，都要進行控制字元轉義。

3.跨站請求偽造攻擊（CSRF）
起因：
　HTTP的Cookie預設行為，是在任何請求中都會帶回指定URL同一Domain的Cookie值。
手法：
　藉由惡意超連結，讓受害者對未防護的網站執行本人未同意的操作。
防止：
　開發網站程式時要遵守REST原則，HTTP GET只用來讀取資料，不能用來新增、修改和刪除資料。
　啟動網站伺服器或軟體框架裡的防CSRF Cookie功能。
　設定Cookie為SameSite=Strict，確保同Domain的請求才能一併附帶Cookie資料
　Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Strict;
　較寬鬆的設定是SameSite=Lax，允許GET請求可以不限定來源Domain，都會附帶Cookie資料（適用於「分享」功能），其它請求一樣限定同Domain。
　Set-Cookie: _xsrf=5978e29d4ef434a1; SameSite=Lax;
　對於敏感操作要求重複登入以驗證身份

4.攻擊身份驗證機制
起因：
　駭客直接以假身份操作網站系統
手法：
　暴力破解或暗網名單
防止：
　使用多因子身份驗證機制（MFA）
　實作安全的登出功能，將session Cookie清除

5.連線狀態劫持
起因：
　利用Cookie來保持連線狀態（session），卻沒有完善保護Cookie。
手法：
　駭客取得使用者的session id或session狀態，藉以偽裝成使用者的身份進行操作。
防止：
　竊取Cookie：將Cookie設定如下。HttpOnly能讓JavaScript無法讀取Cookie，Secure確保只能在HTTPS時傳送Cookie，SameSite=Lax能避免CSRF攻擊。
　Set-Cookie: session_id=278283910977381992837; HttpOnly; Secure; SameSite=Lax
　Session定置：一律不使用「URL改寫」來傳遞session id。
　脆弱Session ID：避免使用流水號式的Session ID設計，並留意Web伺服器在Session ID實作的漏洞公告。

6.規避權限管制
起因：
　系統在權限設計或目錄規劃上有缺失。
手法：
　駭客利用系統的缺失得以執行未經授權的操作或是取得未經授權的檔案。
防止：
　實作嚴謹的以角色為基礎的存取控制，避免任何垂直提權（執行高一級的操作）和水平提權（以他人身份執行操作）的攻擊。
　增加稽核軌跡。
　避免使用任何過於直覺的URL路徑與參數設計。例如/reports/<公司名稱>/<月份-年度>，讓駭客能猜測到合法路徑。
　確切設定Web伺服器，不允許顯示目錄內容、不允許利用相對路徑指定父目錄中的檔案。
　不要直接引用檔案，要自行維護一組暗碼代號用以連結到主機上的實體檔案。
　對任何有關指定檔案位置的外部參數，都要進行最嚴格的安全檢查。

7.資訊洩漏
起因：
　因疏失造成系統將機敏資訊呈現給外部使用者。
手法：
　針對系統進行探索式操作，以收集可用來進行後續攻擊的機敏資訊。
防止：
　不使用系統預設的回應標題（像預設的4xx、5xx頁面）。
　使用未帶程式副檔名（.php、jsp、aspx）的簡潔URL。
　Cookie的健值不要用預設值（JESSIONID）。
　不要在正式環境中顯示詳細的錯誤描述。
　壓縮或模糊化JavaScript程式。
　清理前端程式中不必要的註解和程式碼。

8.加解密機制
起因：
　未使用加密通訊協定。
手法：
　竊聽網路封包。
防止：
　一律使用HTTPS。

9.第三方元件
起因：
　使用到不安全的第三方元件。
手法：
　針對已知的元件漏洞攻擊。
防止：
　留意第三方元件安全公告，及時更新。
　保護好第三方服務的系統金鑰。

10.XML攻擊
起因：
　DTD的設計漏洞。
手法：
　藉由內聯的DTD宣告，讓系統主機資源耗盡。
　在DTD宣告外聯以下載惡意檔案。
　利用XML解析失敗時會顯示檔案內容的特性，指定主機上的機敏檔案。
防止：
　關閉DTD內聯功能。
　設定防火牆限制外聯對象。
　盡量不使用XML，非得使用時要再三確保XML解析器的安全設定已就位。