iPad泄密事件反思 應(yīng)用安全評估問題
日前iPad爆出由于AT&T網(wǎng)站的安全漏洞問題，導(dǎo)致11.4萬iPad用戶的電子郵件賬戶泄露。
邁克菲首席技術(shù)官George Kurtz昨日在邁克菲官方博客上發(fā)表文章對此事進行評論，認為本次泄密主要是 AT&T網(wǎng)站的安全漏洞造成的。同時這個漏洞還是常見的安全問題，完全可以避免。以下為其博內(nèi)容：
我有一臺iPad，實際上是兩臺，對此我感到很自豪。我的電子郵件地址也有很多人知道，而且經(jīng)常有人向我發(fā)出請求，想要知道我的郵件地址。我猜他們一定發(fā)現(xiàn)像這樣得到我的郵件地址不費吹灰之力。所以，前兩天iPad泄露現(xiàn)有11.4萬用戶信息時，為什么會引起那么大的騷動？
讓我們來看看到底發(fā)生了什么。一個名為Goatse Security的黑客團伙發(fā)現(xiàn)了AT&T網(wǎng)站的一個安全漏洞，竊取了用戶的ICC-ID（Integrated Circuit Card ID，IC卡識別碼）并取得了與之相連的電子郵件地址。接下來，他們利用一段PHP代碼反復(fù)向AT&T網(wǎng)站提供大量ICC-ID，然后取得相關(guān)電子郵件地址。就這樣，他們得到了預(yù)計11.4萬ICC-ID及其相關(guān)電子郵件地址。
我覺得大家都會覺得這是個問題，而且是個普遍存在的問題。在我們Foundstone的安全顧問服務(wù)中，經(jīng)常會遇到我們稱之為“信息公開”漏洞的問題。通過搜集用戶或企業(yè)的這些信息，可以全面了解其正在使用的技術(shù)或用戶行為。同時借助社會工程技術(shù)，就可以有效的獲取一些原本無法得到的企業(yè)資源。
然而，這樣的漏洞根本不算是最嚴重的漏洞。我們發(fā)現(xiàn)主要問題在于在Web應(yīng)用程序的身份認證系統(tǒng)存在故障。也就是說，用戶會話需要避免橫向權(quán)限升級，因為橫向權(quán)限升級將允許攻擊者得到另一用戶信息。所以，與其說這是iPad的漏洞問題，不如說是我們在進行應(yīng)用安全評估時經(jīng)常遇到的普通問題。
鑒于這個漏洞利用了一個Web應(yīng)用程序缺陷，我認為應(yīng)該總結(jié)一下在應(yīng)用安全評估時最常見的5個問題。
授權(quán)失敗
惡意認證用戶可以接觸它本無權(quán)接觸的信息。通常這樣會導(dǎo)致權(quán)限升級。如果權(quán)限升級發(fā)生在同級別的用戶中，則被稱為“橫向權(quán)限升級”。如果用戶可以將權(quán)限升級至更高級別用戶，即為“縱向權(quán)限升級”。在AT&T事件里，結(jié)果只是信息泄露，而沒有權(quán)限升級。
跨站點腳本（XSS）
跨站點腳本攻擊需要攻擊者在應(yīng)用程序的數(shù)據(jù)領(lǐng)域中輸入惡意代碼（通常是Java腳本），而這些數(shù)據(jù)領(lǐng)域?qū)υ搼?yīng)用程序的其他用戶而言也是可見的。當受害用戶瀏覽該數(shù)據(jù)領(lǐng)域時，該Java腳本就在該用戶瀏覽器中運行，并執(zhí)行一些對攻擊者有用的功能。反向XSS攻擊通常用來進行釣魚攻擊。
跨站點請求偽造（XSRF）
跨站點請求偽造攻擊（也叫XSRF，CSRF，或者會話控制）允許惡意用戶執(zhí)行對攻擊者選定的用戶會話的操作，從而泄露用戶信息。這類攻擊利用了HTTP無狀態(tài)的弱點。
密碼重置功能
通常來說，應(yīng)用程序允許用戶在忘記密碼的情況下重置密碼。密碼提醒/重置程序通常很容易成為被攻擊的對象。很多情況下，攻擊者首先列出所有具有同樣特征的有效用戶名。一旦這些用戶名中有一個被辨認出來，那么密碼問題的答案都可以猜出來。一般情況下，在密碼重設(shè)頁面沒有輸入次數(shù)的限制。而且用戶在社交網(wǎng)站上設(shè)置的一些問題的答案也可能被攻擊者猜中。
SQL注入
SQL注入允許攻擊者在關(guān)系數(shù)據(jù)庫里執(zhí)行任意SQL語句。通常，漏洞出現(xiàn)通常都是源于應(yīng)用程序SQL查詢的不安全構(gòu)造。即使在數(shù)據(jù)驗證很少或沒有的情況下，應(yīng)用程序也會信任攻擊者提供輸入的信息，執(zhí)行任意的惡意SQL語句。成功的SQL注入攻擊可以泄露基礎(chǔ)操作系統(tǒng)信息。
建議
盡管現(xiàn)在是“應(yīng)用程序101”，我們?nèi)匀豢梢栽诿恳环輵?yīng)用程序安全測評報告中看到幾乎所有的5個問題。下面是幾條建議：
授權(quán)失敗
會話應(yīng)該使用基礎(chǔ)框架提供的會話容器。為了避免橫向權(quán)限升級，應(yīng)用程序需要對以下三點進行三次確認：
需確認的授權(quán)內(nèi)容：
主體：例如用戶或群組
操作：例如CRUD —— 創(chuàng)建、讀取、更新、刪除
客體：例如數(shù)據(jù)因素（賬號、購物卡ID等）
跨站點腳本（XSS）
為了避免諸如跨站點腳本等數(shù)據(jù)驗證攻擊，我們建議采取“深層防御”策略，包括輸入驗證和輸出消毒。
阻止數(shù)據(jù)驗證攻擊的第一步就是要驗證輸入來防止接受任何在該應(yīng)用程序中或數(shù)據(jù)終端（也就是瀏覽器）中有特殊意義的語句。我們推薦的輸入驗證方式是“默認拒絕”，只接受含有預(yù)期值（也就是白名單）的輸入。日常輸入驗證必須始終檢查數(shù)據(jù)長度、范圍、類型和格式。
消毒應(yīng)用程序HTML中的惡意語句與防止跨站點腳本攻擊（XSS）同等重要。比如，“<”應(yīng)編碼為“<”；盡管對于用戶來說，這是“少于”的意思，但是它不會被用戶瀏覽器解釋為HTML標簽的起始點。
跨站點請求偽造（XSRF）
要防止XSRF攻擊，一種有效而又不唐突的方法就是在每一個可以改變某些外在狀態(tài)的表格中引入一個“隨機數(shù)”，或者一次性口令。每次用戶加載表格，一個不同的“隨機數(shù)”就被插入表格中的一個隱藏區(qū)域內(nèi)。當表格提交后，應(yīng)用程序檢查該隨機數(shù)是否有效，然后再運行所請求的操作。“隨機數(shù)”可以是現(xiàn)有會話的標識信息，這種信息一般都會附加在每個請求之后。不過，只有當目標應(yīng)用程序不存在任何XSS漏洞的情況下，這種方法才能有效。
另外一些更加不唐突的避免XSRF的方法包括使用“Captchas”、對重要操作重新授權(quán)、或使用獨立授權(quán)密碼。這些方法很有效，但也會給用戶帶來額外負擔。從用戶界面角度來看，這些方法并不常用。
密碼重置功能
密碼重置功能的推薦方法是：
1.這種方法需要用戶輸入用戶名。把下面信息傳遞給終端用戶，“如果用戶名與系統(tǒng)中的現(xiàn)有賬戶吻合，一封寫有下一步說明的電子郵件將發(fā)至賬戶所有者的注冊電子郵件地址。”
2.這封電子郵件必須含有唯一的、帶有時間限制的鏈接（比如，24小時內(nèi)有效），而且只能由用戶點擊一次。
3.點擊鏈接后，用戶將看到幾個問題。
4.成功回答問題后，用戶將被允許修改其密碼，同時對應(yīng)用程序進行授權(quán)。
SQL注入
防止SQL注入攻擊需要采取“深層防御”策略。第一步是使用阻止XSS攻擊中提到的白名單方法進行輸入驗證。
除此之外，還需要使用與動態(tài)SQL相反的參數(shù)查詢用。參數(shù)查詢可以將查詢與數(shù)據(jù)分離，支持數(shù)據(jù)庫引擎在數(shù)據(jù)缺失情況下決定運行查詢的最佳方法。數(shù)據(jù)將由查詢執(zhí)行計劃在運行時間內(nèi)使用，保證查詢執(zhí)行計劃不會被惡意數(shù)據(jù)修改。
結(jié)束語
我猜這個應(yīng)用程序漏洞之所以得到如此關(guān)注，是因為，畢竟我們所談?wù)摰氖翘O果。圍繞蘋果產(chǎn)品的炒作，比如對iPhone和iPad的炒作，令人震驚。然而事實是，這種漏洞其實并不是什么新聞，而是每天都在我們身邊發(fā)生。
現(xiàn)在，很多應(yīng)用程序并沒有經(jīng)過全面測試便推向市場。考慮到很多企業(yè)目前面臨的市場壓力，這種現(xiàn)象就變得一點都不奇怪。所以，盡管我認為這個漏洞并不像媒體渲染的那樣嚴重，但是它還是讓我們看到一個好的安全程序和生命周期研發(fā)操作是成功的關(guān)鍵。
在上面提到的最常見的5種Web應(yīng)用程序漏洞中，很多都可以通過計劃和安全測試來消除。你所面臨的最大挑戰(zhàn)就是說服你的老板，讓他相信這些漏洞確實存在。不過我想現(xiàn)在你又多了一種有力武器來達到目的。
【編輯推薦】
