1. 程式人生 > >AppScan 測出 跨站點請求偽造 漏洞

AppScan 測出 跨站點請求偽造 漏洞

安全風險: 可能會竊取或操縱客戶會話和 cookie,它們可能用於模仿合法使用者,從而使黑客能夠以該使用者身份檢視或變更使用者記錄以及執行事務
可能原因 應用程式使用的認證方法不充分 技術描述 “跨站點偽造請求 (CSRF)”攻擊可讓黑客以受害者的名義在易受攻擊的站點上執行操作。當易受攻擊的站點未適當驗證請求來源時,便可能出現這個攻擊。
這個漏洞的嚴重性取決於受影響的應用程式的功能,例如,對搜尋頁面的 CSRF 攻擊,嚴重性低於對轉帳頁面或概要更新頁面的 CSRF 攻擊。 這項攻擊的執行方式,是強迫受害者的瀏覽器向易受攻擊的站點發出 HTTP 請求。如果使用者目前已登入受害者站點,請求會自動使用使用者的憑證(如會話 Cookie、使用者的 IP 地址,以及其他瀏覽器認證方法)。攻擊者利用這個方法來偽造受害者的身份,再代替他來提交操作。換句話來說,易受攻擊的站點未採取適當措施來驗證使用者實際是否想執行特定操作。 強迫受害者傳送非預期的請求,方法有許多種: - 通過電子郵件向受害者傳送易受攻擊應用程式的惡意連結。 - 在黑客的 Web 頁面上,放置一個易受攻擊的站點的熱連結(如影象或幀)。 - 在公共論壇中,張貼易受攻擊站點的連結。 - 利用站點(或另一個站點)的“跨站點指令碼編制”或“連結注入”漏洞,將瀏覽器自動重定向到易受攻擊的站點。 如果攻擊者利用易受攻擊的站點本身的“連結注入”漏洞,可以增加使用者通過站點認證的可能性,進而增加攻擊成功的可能性。 例如,攻擊者可以利用上述任何選項來誘惑受害者檢視含有下列條目的頁面: <img src="http://bank/transfer?destination=John&money=1000" style='visibility:hidden'>
這會使受害者的瀏覽器自動請求 URL 及瀏覽器的當前憑證。
如果這個銀行業站點易受到 CSRF 攻擊,它會根據應用程式邏輯,從受害者的帳戶中,將 1000 美元轉賬到 John 的銀行帳戶。
“跨站點偽造請求”攻擊也稱為 CSRF(發音為 C-Serf)、XSRF、“跨站點偽造引用”、“單鍵攻擊”以及“會話騎乘”。 您可以利用下列方式來驗證您的應用程式是否易受到 CSRF 攻擊: [1] 檢查易受攻擊的連結/請求是否未包括攻擊者難以猜中的引數 [2] 檢查易受攻擊的連結/請求是否會執行只應自願執行的操作 含有使用者在不知不覺中提交的請求所能直接訪問的敏感操作的應用程式,被視為很容易遭受 CSRF 攻擊。CSRF 也可能出現在登入頁面和登出頁面上。由於攻擊者可以偽造來自受害者的連續登出請求,因此 CSRF 可能導致服務拒絕。在登入頁面上,CSRF 可以允許攻擊者使用包含攻擊者使用者名稱和密碼的偽造請求來將客戶機登入到攻擊者的賬戶中。登入 CSRF 攻擊會帶有嚴重的後果,這取決於其他站點行為。例如,如果站點保留了使用者操作的歷史記錄(例如搜尋歷史記錄),那麼攻擊者將能夠在易受攻擊的站點上檢視受害者之前執行的操作。
修訂建議
一般 如果要避免 CSRF 攻擊,每個請求都應該包含唯一標識,它是攻擊者所無法猜測的引數。 建議的選項之一是新增取自會話 cookie 的會話標識,使它成為一個引數。伺服器必須檢查這個引數是否符合會話 cookie,若不符合,便廢棄請求。 攻擊者無法猜測這個引數的原因是應用於 cookie 的“同源策略”,因此,攻擊者無法偽造一個虛假的請求,讓伺服器誤以為真。 攻擊者難以猜測且無法訪問的任何祕密(也就是無法從其他域訪問),都可用來替換會話標識。 這可以防止攻擊者設計看似有效的請求。

解決方案

建議使用者每次登入時需使用新的會話標識。應用程式實現上就是在登入模組,新增以下程式碼,即使用者登入後,重新生成會話。

HttpSession session = request.getSession(false);
if(session!=null){//讓cookie過期
         session.invalidate();
         Cookie cookie = request.getCookies()[0];//獲取cookie
         cookie.setMaxAge(0);//讓cookie過期
}
request.getSession(true);//生成新會話
經過測試,這段程式碼只在weblogic和tomcat下才有效,在公司中介軟體webspeed及jboss6.0下問題都依然存在,但從掃描的結果資訊分析看,漏洞已經解決,分析判斷應該只是session處理機制不同,AppScan工具仍認為存在漏洞風險。在與電信溝通中我們存在一個經驗教訓大家一定要吸取,不能過渡迷信流行的自動化測試工具,尤其是對於Appscan這種判斷防禦行為的複雜軟體,僅靠有限的規則設定就當做是web安全的唯一標準這顯然不太合理,這種情況一定要與測試方溝通解釋。