應用系統面臨多元資安風險之教戰手則(下)

延續84 期叡揚e 論壇「應用系統面臨多元資安風險之教戰手則（上）」談生活資安與自 SSDLC 著手的資安概念，教戰手則（下）則是和大家說明從 OWASP Top10 著手時，應用程式開發該注意的安全事項，希望能與軟體開發從業人員分享交流，更提供使用者自我防範管理的方向。

從 OWASP TOP 10 談安全程式教戰手則


OWASP（Open Web Application Security Project）為專門研究網站應用程式的弱點組織，其歸納出開發人員常犯的前十大弱點。本文中我們將以 .NET 程式為說明範本。
 

含SQL Injection、Command Injection、XML Injection …等注入式攻擊手法。如圖示，SQL Injection 簡單說是程式碼 SQL 語法字串將傳入變數作條件組合引發的問題。

由於輸入介面上無任何驗證處理，故當攻擊者發現問題並輸入不當資料，便產生即使密碼輸入錯誤也可正常登入運作的狀況，避開帳密驗證。

進階攻擊為利用 Second Order SQL Injection 取得權限提升或變更系統管理者密碼，甚至摧毀資料庫造成重大影響。而對程式開發者來說，透過參數化查詢、過濾掉 SQL 溢出字元、使用 ORM 技術等皆可處理 SQL Injection 的問題。
 

早期忘記密碼時以提示功能告知，當提問答案容易被猜到時將提升取得密碼機率，因此建議採用 two factor authentication（2FA）加強安全驗證，也就是至少含以下兩種認證因子：

• Something you know：身分證字號、密碼、出生地及其他所知道的事。
• Something you have：動態密碼鎖、鑰匙、晶片卡及其他所擁有的事物。
• Something you are：性別、指紋、視網膜及其他天生的特徵。

密碼存入資料庫需以雜湊（Hash）單向加密方式儲存，確保密碼的隱密性。通常開發人員會忽略掉雜湊加密需加上「鹽巴」（Salt），這作法可避免駭客使用字典檔方式破解密碼。

Session 是記錄網頁上的狀態資訊，當登入後 Session ID 會記錄在 Cookie 中，如 Session ID 不變，攻擊者可由釣魚網站誘騙，利用固定 Session ID（Session Fixation）成功進入系統，因此程式開發者需保護 Cookie，透過調整系統設定檔（web.config）將 httpOnlyCookies 設定 true 讓 JavaScript 無法讀取，或透過圖示的範本程式碼，在使用者登入成功後，立即更換 Session ID 避免固定值問題。

網站型應用系統大部分都有此弱點。攻擊者通常會使用 JavaScript 先在網上注入惡意腳本程式碼（Script），當使用者造訪具弱點的網站時，瀏覽器會讀取惡意腳本程式碼執行，利用弱點竊取用戶 cookie；如發生上述提到因存取 cookie 讓 Session ID 被冒用時，甚至可做到鍵盤側錄（key log）將輸入資料記下。

網站弱點可分為直接讀取網站時便執行惡意腳本程式碼的 Reflected XSS 及透過不可信賴的來源如資料庫或檔案執行程式碼的 Stored XSS（或稱 Persistent XSS，常於留言板發生）；對開發者來說，只要懂原理便十分容易解決，如微軟於 .NET 開發平台內附的 Encoder，即可用 HtmlEncode 轉換字元來避免惡意腳本程式碼的輸入。
 

擁有上傳檔案功能的網頁，如不限定其上傳檔案類型，攻擊者可把惡意程式傳入系統並透過釣魚信件將 URL 提供給受害者。

另一常犯問題是下載路徑參照，攻擊者更改原使用者下載路徑參數，以操控路徑（Path Traversal）至根目錄下抓取系統設定檔案，竊取設定檔的資料庫連線帳密等資訊，再者搜尋引擎可藉由不安全參考設計找到利用 url 參數來讀取敏感性的文件。

一般而言系統出廠設定有「預設值」，但使用者常忽略更改，加上大多設備沒特別要求需修改，容易將系統敏感資訊暴露！且網站應用伺服器常將錯誤訊息顯示在畫面上，雖對開發人員來說是很好的除錯，有時卻反讓駭客得到更多資訊。

因篇幅關係，A6 - A10 風險內容請至「叡揚資安電子報第 0136 期」完整介紹。