邁克菲首席技術官談iPad泄密事件

　　我有一台iPad，實際上是兩台，對此我感到很自豪。我的電子郵件地址也有很多人知道，而且經常有人向我發出請求，想要知道我的郵件地址。我猜他們一定發現像這樣得到我的郵件地址不費吹灰之力。所以，前兩天iPad洩露現有11.4萬用戶信息時，為什麼會引起那麼大的騷動？

　　讓我們來看看到底發生了什麼。一個名為Goatse Security的黑客團夥發現了AT&T網站的一個安全漏洞，竊取了用戶的ICC-ID(Integrated Circuit Card ID，IC卡識別碼)並取得了與之相連的電子郵件地址。接下來，他們利用一段PHP代碼反復向AT&T網站提供大量ICC-ID，然後取得相關電子郵件地址。就這樣，他們得到了預計11.4萬ICC-ID及其相關電子郵件地址。

　　我覺得大家都會覺得這是個問題，而且是個普遍存在的問題。在我們Foundstone的安全顧問服務中(www.foundstone.com )，經常會遇到我們稱之為“信息公開”漏洞的問題。通過蒐集用戶或企業的這些信息，可以全面了解其正在使用的技術或用戶行為。同時借助社會工程技術，就可以有效的獲取一些原本無法得到的企業資源。

　　而，這樣的漏洞根本不算是最嚴重的漏洞。我們發現主要問題在於在Web應用程序的身份認證系統存在故障。也就是説，用戶會話需要避免橫向權限升級，因為橫向權限升級將允許攻擊者得到另一用戶信息。所以，與其説這是iPad的漏洞問題，不如説是我們在進行應用安全評估時經常遇到的普通問題。

　　鋻於這個漏洞利用了一個Web應用程序缺陷，我認為應該總結一下在應用安全評估時最常見的5個問題。

　　授權失敗

　　惡意認證用戶可以接觸它本無權接觸的信息。通常這樣會導致權限升級。如果權限升級發生在同級別的用戶中，則被稱為“橫向權限升級”。如果用戶可以將權限升級至更高級別用戶，即為“縱向權限升級”。在AT&T事件裏，結果只是信息洩露，而沒有權限升級。

　　跨站點腳本 (XSS)

　　跨站點腳本攻擊需要攻擊者在應用程序的數據領域中輸入惡意代碼(通常是Java腳本)，而這些數據領域對該應用程序的其他用戶而言也是可見的。當受害用戶瀏覽該數據領域時，該Java腳本就在該用戶瀏覽器中運行，並執行一些對攻擊者有用的功能。反向XSS攻擊通常用來進行釣魚攻擊。

　　跨站點請求偽造 (XSRF)

　　跨站點請求偽造攻擊(也叫XSRF，CSRF，或者會話控制)允許惡意用戶執行對攻擊者選定的用戶會話的操作，從而洩露用戶信息。這類攻擊利用了HTTP無狀態的弱點。

　　密碼重置功能

　　通常來説，應用程序允許用戶在忘記密碼的情況下重置密碼。密碼提醒/重置程序通常很容易成為被攻擊的對象。很多情況下，攻擊者首先列出所有具有同樣特徵的有效用戶名。一旦這些用戶名中有一個被辨認出來，那麼密碼問題的答案都可以猜出來。一般情況下，在密碼重設頁面沒有輸入次數的限制。而且用戶在社交網站上設置的一些問題的答案也可能被攻擊者猜中。

　　SQL注入

　　SQL注入允許攻擊者在關系數據庫裏執行任意SQL語句。通常，漏洞出現通常都是源於應用程序SQL查詢的不安全構造。即使在數據驗證很少或沒有的情況下，應用程序也會信任攻擊者提供輸入的信息，執行任意的惡意SQL語句。成功的SQL注入攻擊可以洩露基礎操作系統信息。

　　建議

　　儘管現在是“應用程序101”，我們仍然可以在每一份應用程序安全測評報告中看到幾乎所有的5個問題。下面是幾條建議：

　　授權失敗

　　會話應該使用基礎框架提供的會話容器。為了避免橫向權限升級，應用程序需要對以下三點進行三次確認：

　　需確認的授權內容：

　　主體：例如用戶或群組

　　操作：例如CRUD —— 創建、讀取、更新、刪除

　　客體：例如數據因素(賬號、購物卡ID等)

　　跨站點腳本 (XSS)

　　為了避免諸如跨站點腳本等數據驗證攻擊，我們建議採取“深層防禦”策略，包括輸入驗證和輸出消毒。

　　阻止數據驗證攻擊的第一步就是要驗證輸入來防止接受任何在該應用程序中或數據終端(也就是瀏覽器)中有特殊意義的語句。我們推薦的輸入驗證方式是“默認拒絕”，只接受含有預期值(也就是白名單)的輸入。日常輸入驗證必須始終檢查數據長度、範圍、類型和格式。

　　消毒應用程序HTML中的惡意語句與防止跨站點腳本攻擊(XSS)同等重要。比如，“<”應編碼為“<”；儘管對於用戶來説，這是“少於”的意思，但是它不會被用戶瀏覽器解釋為HTML標簽的起始點。

　　跨站點請求偽造 (XSRF)

　　要防止XSRF攻擊，一種有效而又不唐突的方法就是在每一個可以改變某些外在狀態的表格中引入一個“隨機數”，或者一次性口令。每次用戶加載表格，一個不同的“隨機數”就被插入表格中的一個隱藏區域內。當表格提交後，應用程序檢查該隨機數是否有效，然後再運行所請求的操作。“隨機數”可以是現有會話的標識信息，這種信息一般都會附加在每個請求之後。不過，只有當目標應用程序不存在任何XSS漏洞的情況下，這種方法才能有效。

　　另外一些更加不唐突的避免XSRF的方法包括使用“Captchas”、對重要操作重新授權、或使用獨立授權密碼。這些方法很有效，但也會給用戶帶來額外負擔。從用戶界面角度來看，這些方法並不常用。

　　密碼重置功能

　　密碼重置功能的推薦方法是：

　　1. 這種方法需要用戶輸入用戶名。把下面信息傳遞給終端用戶，“如果用戶名與系統中的現有賬戶吻合，一封寫有下一步説明的電子郵件將發至賬戶所有者的註冊電子郵件地址。”

　　2. 這封電子郵件必須含有唯一的、帶有時間限制的鏈結(比如，24小時內有效)，而且只能由用戶點擊一次。

　　3. 點擊鏈結後，用戶將看到幾個問題。

　　4. 成功回答問題後，用戶將被允許修改其密碼，同時對應用程序進行授權。

　　SQL注入

　　防止SQL注入攻擊需要採取“深層防禦”策略。第一步是使用阻止XSS攻擊中提到的白名單方法進行輸入驗證。

　　除此之外，還需要使用與動態SQL相反的參數查詢用。參數查詢可以將查詢與數據分離，支持數據庫引擎在數據缺失情況下決定運行查詢的最佳方法。數據將由查詢執行計劃在運行時間內使用，保證查詢執行計劃不會被惡意數據修改。

　　結束語

　　我猜這個應用程序漏洞之所以得到如此關注，是因為，畢竟我們所談論的是蘋果。圍繞蘋果産品的炒作，比如對iPhone和iPad的炒作，令人震驚。然而事實是，這種漏洞其實並不是什麼新聞，而是每天都在我們身邊發生。

　　現在，很多應用程序並沒有經過全面測試便推向市場。考慮到很多企業目前面臨的市場壓力，這種現象就變得一點都不奇怪。所以，儘管我認為這個漏洞並不像媒體渲染的那樣嚴重，但是它還是讓我們看到一個好的安全程序和生命週期研發操作是成功的關鍵。

　　在上面提到的最常見的5種Web應用程序漏洞中，很多都可以通過計劃和安全測試來消除。你所面臨的最大挑戰就是説服你的老闆，讓他相信這些漏洞確實存在。不過我想現在你又多了一種有力武器來達到目的。