在滲透一個網頁的時候，我通常會先偵查（Recon）這個網站：它有什麼功能？什麼雲端環境和架站服務類型？偵查收集資料之後，才會進行攻擊，我會根據收集來的資訊思考要攻擊的方式，像是 SQL 注入（SQL Injection）。

這些「攻擊思路」是入侵網站的關鍵，通常不會只用 SQL 注入，駭客使用的攻擊類型不僅多變且難以列舉。而今天要來參考一個網站資安測試的完整列表，來幫助我們列出這一系列的攻擊思路，了解駭客攻擊的方式和做好網站安全。

OWASP Testing Guide

OWASP 這個組織致力於提供網站安全相關的技術文章、文檔與工具。其中一個項目就是 OWASP Testing Guide，它簡介了資安測試的作法於概覽。相較於 OWASP Top 10，OWASP Testing Guide 列了更完整的資安項目列表，列出建議資安滲透測試員要測試的安全項目。

裡面共分成了 11 個類別：

  • 資訊收集（Information Gathering）
  • 配置與部署管理測試（Configuration and Deployment Management Testing）
  • 身份管理測試（Identity Management Testing）
  • 認證測試（Authentication Testing）
  • 授權測試（Authorization Testing）
  • 會議管理測試（Session Management Testing）
  • 輸入驗證測試（Input Validation Testing）
  • 錯誤處理測試（Testing for Error Handling）
  • 弱加解密測試（Testing for weak Cryptography）
  • 商業邏輯測試（Business Logic Testing）
  • 用戶端測試（Client Side Testing）

並且它也建議測試者在測試該項目時可以使用的框架和工具。我在做滲透測試時也會參考這個列表，它可以幫助檢查遺漏的項目讓自己測到較全面的資安攻擊類型。

不過身為網站開發者，我們不用真的去了解每一個測試項目，但我們的確該了解一些攻擊技巧，在日後開發功能的時候，會自主的想到這些攻擊類型，並且主動做出預防手段。

我們簡短用四個段落分享一下每個類別主要的攻擊想法，如果你想使用工具實際測試或先收集這些工具，也許可以參考 OWASP 列的測試工具列表來嘗試看看。

資訊洩漏與配置部署

我們在部署網站的時候，如果網路的設定不恰當，可能會導致一些資訊洩露。一個看似無關痛癢的資訊有時在駭客眼中卻是一個成功入侵的關鍵。例如常見就是防火牆對外開放埠（Port）的設定，或像是容易被忽略的「TLS 憑證」的網域名稱洩漏。

公司裡「內部主機間通訊」，會希望也是 HTTPS 加密溝通。而目前最方便的也許是直接用 Let’s Encrypt 憑證，儘管這不是內部通訊最好的方法。因為其實駭客可以在 Censys 這個網站上查到有出現某公司名字的憑證以及該公司擁有的子網域名有哪些，進而對這些網域進行弱點掃描和攻擊。

當然不止收集 IP、網域名，駭客也會探索該網站的架構、語言以及在主機上執行的服務有哪些。Shodan 就是一個可以查找該主機上現在對外有哪些服務的搜尋引擎。而這些資訊洩露就跟我們部署與配置有關，我們使用雲端服務的方式、架構設計，如果因為方便連線、方便使用者管理，而對外了內部服務、開放了存取權限，甚至「不知道自己設定錯誤」的配置錯誤（Security Misconfiguration，OWASP Top 10 第六名），就容易造成這些資訊的洩漏。

身份驗證、權限與會議管理

一個提供服務的網站免不了這幾個功能，像是一個交友網站的使用情境：小明想要嘗試「註冊和登入」自己的帳號，並且付費讓自己帳號提升為「白金會員」，他將擁有「權限」可以瀏覽更多其他使用者資訊，並且小明可以「修改自己的個人檔案」來讓別人更加認識自己。

這樣的身份管理可以拆成四個類別來看：

  • 身份：如果這個網站服務有「多個角色」，像是一般會員、白金會員。每個角色的分權要可以在程式裡被查表確認，且程式架構可以允許日後動態增減角色和修改每個角色權限。而「提權」的概念也就此而生，是否有漏洞可以導致使用者可以直接變成白金會員？修改 Cookie 讓自己變成另一個角色？
  • 驗證：只要你有登入功能，就少不了驗證，大家都會知道密碼儲存要雜湊和加鹽，但可能會忽略其他管道上或其他驗證方式的安全，如 websocket 上要如何做驗證？OAuth 配置錯誤導致被偷走存取權杖（Access Token）？「忘記密碼」和修改密碼機制也是驗證的一環，是否可以「忘記別人的密碼」進而登入別人的帳號？
  • 授權：身為白金會員的小明應該擁有哪些權限？小明有權限可以編輯自己個人頁面，是否後端網站有檢查防止小明編輯「別人的頁面」？
  • 會議管理：為了讓使用者不用每天重複登入，我們會建立一個會議（Session），並且把 Session ID 記錄在 Cookie 當中，方便我們服務認出這個使用者。然而這個 Session ID 是否可以被假冒或暴力破解？如果我們使用 JWT（JSON Web Token），是否有設計好整個 Token 的生命週期（Token 產生、更新權限、暫時撤銷、銷毀等）？

而在日後調整權限或機制，為了一時方便而做一個臨時權限允許或臨時程式碼修改，往往容易造成漏洞或後門的發生。其實可以在開發前就做好架構設計，把這些需要的功能和權限確實考慮進來。而彈性的權限設計和每個功能的權限控管都可以減少被駭客入侵的機率。

輸入驗證

你會發現到現在都還沒提到大家最熟悉的 SQL 注入，因為網站安全其實很多需要注意的項目，如果開發者只預防 SQL 注入、跨網站指令碼攻擊（XSS，Cross-site scripting），其實只防禦到各種攻擊類型的一部分而已。

SQL 注入屬於「注入（Injection，OWASP Top 10 第一名）類型」，而注入攻擊，在 OWASP Testing Guide 是歸類在輸入驗證的部分。所有外部來的輸入、輸出，都需要進行檢查，不同的使用情境就用不同的檢查方法。

簡單的驗證概念是：我們依照要「輸出」的地方，來判斷「輸入」的數值要經過什麼樣的檢查。 例如要把使用者的參數要放到 XML 裡，就要注意 XML 注入。要放到頁面呈現，就要注意 XSS 跨網站指令碼攻擊。我們在開發時就需要時時提醒自己檢查和懷疑輸入數值。

錯誤處理、弱加解密、邏輯與用戶端

剩下最後四個 OWASP Testing Guide 類別我們綜合著講：

  • 錯誤處理：常見問題就是當輸入一個無法辨別的數值或資料型態時，或當系統發生錯誤時，我們會不會把錯誤訊息也丟出來了？的確直接丟出來很方便 DEBUG，但這也方便駭客了解裡面的系統架構與服務，並且對這些服務做針對性的攻擊。
  • 加解密：我們會用 HTTPS 來做網站加密讓網站更安全，但 HTTPS 的配置方法會決定這個加密夠不夠安全，還是形同虛設。像是是否有禁止使用過時的 RC4 串流加密？我們可以藉由 SSL Labs 來看我們部署的 HTTPS 網站加密是否夠安全並且調整配置。
  • 商業邏輯：這是一個測試範圍很廣的類別，會根據每個服務提供的功能邏輯進行測試。容易被忽略的通常會是競爭條件（Race Condition）：如果我的數位錢包有 5000 元，剛好可以發出一個請求購買一個 5000 元的數位課程，但如果「同時」送出請求兩次，會不會成功用 5000 元買到兩個數位課程？
  • 用戶端：XSS 也屬於這個類型，而跨來源資源共用（CORS, Cross-Origin Resource Sharing）的配置也是這個類別的一環，我們可以設定 HTTP 頭欄位 Access-Control-Allow-Origin 來控制我們網站的資源只能給哪些其他網站存取。

目前我們只提到上述測試類別的概念，真正 OWASP Testing Guide 其實還提到很多資安項目和測試方法。希望這是一個開始讓大家知道注意網站安全不會只有 SQL 注入和 XSS 攻擊，還有各個面向需要考慮資安，否則被駭客利用造成的危害程度甚至會高於 SQL 注入。

每個細項其實都可以再深入提到很多攻擊手法和防禦方法，我們之後會再一一跟大家分享，如果想了解更多網站安全、更新攻擊手法和如何防禦，歡迎大家持續追蹤我們 FB 粉專和來信指教。