作者:baiboyang,发布于2012-1-12
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指令,但網站卻當成合法需求處理,使得惡意指令被正常執行。
舉例來說,攻擊者在網站內放置了 ,受害者讀取到此頁面之後,就會去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直接取得攻擊弱點。