|
A1 – Injection（注入攻擊）
網站應用程式執行來自外部包括資料庫在內的惡意指令，SQL Injection與Command Injection等攻擊包括在內。因為駭客必須猜測管理者所撰寫的方式，因此又稱「駭客的填空遊戲」。
舉例來說，原本管理者設計的登入頁面資料庫語法如下：
$str = "SELECT * FROM Users WHERE Username='“.$user."' and
Password=‘”.$pass."'“;
如果說$user以及$pass變數沒有做保護，駭客只要輸入「’ or ‘‘=’」字串，就會變成以下：
$str = “SELECT * FROM Users WHERE Username='' or ''='' and Password= '' or
‘’=‘’”;
如此一來，這個SQL語法就會規避驗證手續，直接顯示資料。
簡述駭客攻擊流程：
- 找出未保護變數，作為注入點
- 猜測完整Command並嘗試插入
- 推測欄位數、Table名稱、SQL版本等資訊
- 完整插入完成攻擊程序
防護建議：
- 使用Prepared Statements，例如Java PreparedStatement()，.NET SqlCommand(), OleDbCommand()，PHP PDO bindParam()
- 使用Stored Procedures
- 嚴密的檢查所有輸入值
- 使用過濾字串函數過濾非法的字元，例如mysql_real_escape_string、addslashes
- 控管錯誤訊息只有管理者可以閱讀
- 控管資料庫及網站使用者帳號權限為何
A2 – Cross Site Scripting ( XSS )（跨站腳本攻擊）
網站應用程式直接將來自使用者的執行請求送回瀏覽器執行，使得攻擊者可擷取使用者的Cookie或Session資料而能假冒直接登入為合法使用者。
此為目前受災最廣的攻擊。簡稱XSS攻擊。攻擊流程如下圖：
- 受害者登入一個網站
- 從Server端取得Cookie
- 但是Server端上有著XSS攻擊，使受害者將Cookie回傳至Bad Server
- 攻擊者從自己架設的Bad Server上取得受害者Cookie
- 攻擊者取得控制使用受害者的身分
防護建議：
- 檢查頁面輸入數值
- 輸出頁面做Encoding檢查
- 使用白名單機制過濾，而不單只是黑名單
- PHP使用htmlentities過濾字串
- .NET使用Microsoft Anti-XSS Library
- OWASP Cross Site Scripting Prevention Cheat Sheet
- 各種XSS攻擊的Pattern參考
A3 – Broken Authentication and Session Management（身分驗證功能缺失）
網站應用程式中自行撰寫的身分驗證相關功能有缺陷。例如，登入時無加密、SESSION無控管、Cookie未保護、密碼強度過弱等等。
例如：
應用程式SESSION Timeout沒有設定。使用者在使用公用電腦登入後卻沒有登出，只是關閉視窗。攻擊者在經過一段時間之後使用同一台電腦，卻可以直接登入。
網站並沒有使用SSL / TLS加密，使用者在使用一般網路或者無線網路時，被攻擊者使用Sniffer竊聽取得User ID、密碼、SESSION ID等，進一步登入該帳號。
這些都是身分驗證功能缺失的例子。
管理者必須做以下的檢查：
- 所有的密碼、Session ID、以及其他資訊都有透過加密傳輸嗎？
- 憑證都有經過加密或hash保護嗎？
- 驗證資訊能被猜測到或被其他弱點修改嗎？
- Session ID是否在URL中暴露出來？
- Session ID是否有Timeout機制？
防護建議：
- 使用完善的COOKIE / SESSION保護機制
- 不允許外部SESSION
- 登入及修改資訊頁面使用SSL加密
- 設定完善的Timeout機制
- 驗證密碼強度及密碼更換機制
A4 – Insecure Direct Object References（不安全的物件參考）
攻擊者利用網站應用程式本身的檔案讀取功能任意存取檔案或重要資料。進一步利用這個弱點分析網站原始碼、系統帳號密碼檔等資訊，進而控制整台主機。
例如：http://example/read.php?file=../../../../../../../c:oot.ini。
防護建議：
- 避免將私密物件直接暴露給使用者
- 驗證所有物件是否為正確物件
- 使用Index / Hash等方法，而非直接讀取檔案
A5 – Cross Site Request Forgery (CSRF)（跨站冒名請求）
已登入網站應用程式的合法使用者執行到惡意的HTTP指令，但網站卻當成合法需求處理，使得惡意指令被正常執行。
舉例來說，攻擊者在網站內放置了 <img src=”http://server.com/send.asp?to=...”> ，受害者讀取到此頁面之後，就會去server.com主機執行send.asp惡意行為。
例如Web 2.0時代的社交網站等等，都是CSRF攻擊的天堂。
防護建議：
- 確保網站內沒有任何可供XSS攻擊的弱點
- 在Input欄位加上亂數產生的驗證編碼
- 在能使用高權限的頁面，重新驗證使用者
- 禁止使用GET參數傳遞防止快速散佈
- 使用Captcha等技術驗證是否為人為操作
或者參考OWASP所提供的CSRF Solution
- OWASP CSRFTester Project
- OWASP CSRFGuard Project
- OWASP CSRF Prevention Cheat Sheet
A6 – Security Misconfiguration（安全性設定疏失）
系統的安全性取決於應用程式、伺服器、平台的設定。因此所有設定值必須確保安全，避免預設帳號、密碼、路徑等。甚至被Google Hacking直接取得攻擊弱點。
防護建議：
- 軟體、作業系統是否都有更新到最新版本？是否都有上最新Patch?
- 不需要的帳號、頁面、服務、連接埠是否都有關閉？
- 預設密碼是否都有更改？
- 安全設定是否都完備？
- 伺服器是否都有經過防火牆等設備保護？
各種設備、系統的預設密碼，都可以在網路上找到一些整理資料。
http://www.phenoelit-us.org/dpl/dpl.html
http://www.routerpasswords.com/
http://www.defaultpassword.com/
A7 – Failure to Restrict URL Access（限制URL存取失敗）
網頁因為沒有權限控制，使得攻擊者可透過網址直接存取能夠擁有權限或進階資訊的頁面。例如管理介面、修改資料頁面、個人機敏資訊頁面洩漏等等。
舉例來說，
/admin
/backup
/logs
/phpmyadmin
/phpinfo.php
/manage
這些都是常見的路徑及檔案。攻擊者只要猜測到，就可以操弄主機。
防護建議：
- HTTP Service直接限制來源IP
- 使用防火牆阻擋
- 密碼授權加密頁面
- 網站架構最佳化
A8 – Unvalidated Redirects and Forwards（未驗證的導向）
網頁應用程式經常將使用者Forward或Redirect至其他頁面或網站，沒有驗證的機制。攻擊者可將受害者導向至釣魚網站或惡意網站，甚至存取受限制的資源。
例如：
http://example.cc/redir.jsp?url=evil.com
http://example.cc/func.jsp?fwd=admin.jsp
http://g.msn.com/9SE/1?http://xxx.com
防護建議：
- 非必要時避免使用Redirect及Forward
- 驗證導向位置及存取資源是合法的
A9 – Insecure Cryptographic Storage（未加密的儲存設備）
網站應用程式沒有對敏感性資料使用加密、使用較弱的加密演算法或將金鑰儲存於容易被取得之處。加密演算法是安全防護的最後一道防線，當駭客取得了帳號密碼，可以簡單地使用一些破解軟體甚至線上服務進行破解。例如Cain & Abel，MD5 Reverse Lookup等。
防護建議：
- 使用現有公認安全的加密演算法
- 減少使用已有弱點的演算法，例如MD5 / SHA-1，甚至更簡單的加密法
- 安全的保存私鑰
A10 – Insufficient Transport Layer Protection（傳輸層保護不足）
網頁應用程式未在傳輸機敏資訊時提供加密功能，或者是使用過期、無效的憑證，使加密不可信賴。
例如：攻擊者竊聽無線網路，偷取使用者cookie；網站憑證無效，使用者誤入釣魚網站。
防護建議：
Cookie Secure Flag設定：
- PHP setcookie ("TestCookie", "", time() - 3600, “/", ".example.com", 1);
- JSP cookie.setSecure(true);
- ASP.NET cookie.Secure = True;
| 
