像Enterprise2.0方案一樣，Web2.0也日漸深入到了金融服務領域，為這些服務增加了新的價值。分析師們利用信息源來透過現象分析本質。而Wells Fargo和E*Trade這樣的貿易和銀行公司正在運用Web2.0組件來開發它們的下一代技術。這些組件將會被用到銀行軟件，貿易門戶網站以及其他的周邊服務中去。比起將信息從互聯網上提取過來，RSS組件的真正優勢在于它能夠將信息直接發布給終端用戶。金融行業估計稱，95%的信息是以非RSS形式存在的，如果人們能將這些信息轉換成RSS格式，那么RSS的這項優點將成為一項關鍵的策略優勢。Wells Fargo已經實施了這樣的系統，并且開始獲得收益。然而，RSS自身所存在的安全問題對金融服務來說是非常嚴重的問題。本文將介紹RSS安全問題的熱點以及攻擊向量。

RSS反饋操作與JavaScript以及HTML標簽

RSS流從數據庫或者用戶提供的輸入獲得結構。RSS流能夠從諸如新聞站點，博客等第三方信息源獲得信息。金融服務會替終端用戶將這些信息整合起來，這樣這些信息就跟其他的敏感信息一起出現在用戶的瀏覽器中。如果RSS反饋是來自不受信任的信息源，那么它們很有可能被注入了JavaScript或者其他HTML標簽。這些惡意標簽很有可能會攻擊瀏覽器。在轉發任何來自終端用戶的信息之前，金融系統必須使用可靠的過濾表進行過濾；或者它們必須過濾特定的字符集。人們越來越多地使用RSS，這使得金融領域的用戶處在風險之中。為了抵御這種威脅，人們應當在金融應用中進行RSS輸入輸出驗證。

跨站點腳本（XSS/CSS）和RSS反饋

RSS腳本注入導致黑客們用XSS能夠成功地進行RSS攻擊。注入了JavaScript的RSS成功地到達金融系統中的終端用戶那里，那么就有可能引起諸如SCRIPT RSS反饋攻擊或者帶著“onClick”的HREF攻擊。很多攻擊是用XSS編寫的，攻擊者可以利用它們劫持會話或者在會話中運行keylogger。所有的這些攻擊都可能危及金融系統的安全。若要應付這種威脅，人們必須在它們到達終端客戶之前進行字符集“過濾”。瀏覽器并沒有自帶的過濾功能，安全起見，我們需要在應用層支持過濾功能。人們在進行跨域對話或者跨站點RSS訪問的時候一定要格外小心。

CSRF與RSS反饋

偽造跨站點請求是另一個可通過RSS反饋進行的攻擊。如果某個反饋被注入了一定的HTML標簽或者其他允許跨域對話的標簽，這些對話就會重放cookie從而導致CSRF攻擊。CSRF攻擊增大了存在漏洞的金融應用受到攻擊的幾率。由于鎖定了目標，范圍也是確定的，所以攻擊者成功的幾率也自然增加了。

假設，某個銀行操作應用的金融門戶網站上運行著RSS讀者組件。該組件包含一套用來在不同域上進行交易和其他服務的應用程序。還有，這些應用程序中的一個程序非常容易受到CSRF的攻擊，并且它還通過cookie或者普通的數據庫訪問方式共享了“single sign on”方法。在這種情況下，攻擊者可以以最適合CSRF攻擊的方式——大范圍發布CSRF攻擊來達到最佳攻擊效果——偽造一個RSS請求。一旦攻擊者能夠識別終端用戶了，被鎖定的RSS反饋讀者將成為利用該攻擊向量的助力者。

RSS反饋操作的SQL注入問題

SQL注入通常都是網絡應用的同步攻擊向量。在SQL注入攻擊中，攻擊者會發送特殊的負載然后觀察響應。如果那些響應與SQL成功注入的信號一致，那么它就可以進行更進一步的攻擊了。

現在，新的應用都提供按照用戶要求定制的RSS反饋。例如，RSS反饋的內容可能是在一段時間內的10條最新的報告或者聲明。所有這些參數都是由終端用戶提供的，并且將被RSS反饋生成程序用來進行SQL查詢。如果RSS反饋生成程序容易受到SQL注入攻擊，那么攻擊者就可以偽造一個SQL負載然后將其發送給RSS反饋，從而引起非同步的SQL注入攻擊。一旦反饋生成程序運行了用戶的請求，并為客戶端建立定制的RSS反饋，這種攻擊也隨之成功運行，攻擊者不需授權就可以訪問用戶信息。為了阻止此類攻擊，人們必須對RSS反饋的生成路線進行適當的代碼審查；這種攻擊向量是非同步的，所以用黑箱檢測的方法是很難發現它的。

RSS反饋的驗證和授權問題

在HTTP形式下，RSS不具備鑒別字頭的機制，因此RSS反饋傳輸必須從網絡服務器或者應用層取得認證許可。由于RSS屬于靜態XML反饋，從安全角度來考慮，這是很難平衡的。人們可以檢索到未經任何認證、一直處于開放狀態的RSS反饋。如果某個應用使用隱藏參數或者安全代碼來提供RSS反饋，那么人們可以根據極少的可用信息猜測出或者強制破解出這些參數。銀行應用的合法用戶知道訪問他定制的反饋的URL，但他有可能嘗試不同的URL組合，從而訪問到其他用戶的反饋。如果RSS反饋在應用層配置的方法符合條件，那么就很有可能出現以上情況的。通常人們可以強行破解那種用Basic/NTLM認證鎖定的RSS反饋。處理重要金融信息時，人們必須使用那種整合了會話審查功能的強有力的應用層反饋。另一個需要解決的安全問題是：諸如密碼這樣的敏感信息會被發送給線上RSS讀者們。因此，使用金融服務的時候，“在何處閱讀你的RSS反饋”是至關重要的。

RSS加密問題

在XML層面上，人們無法對RSS進行加密。與網絡服務不同，現在還沒有現成的RSS安全標準。Atom公司有XML加密以及簽名方案，但是這些技術并沒有得到普及。為了保證傳輸中的RSS信息的安全，人們需要在HTTPS上使用它。如果已有定制的加密機制，那么人們就需要給其他地方傳遞“密鑰”信息，可能是傳給瀏覽器或者是第三方應用。這么做本身就存在風險。如果想要更高的安全性，人們應當點對點地進行RSS加密，否則RSS信息就有可能在傳輸過程中被窺視，從而造成不必要的安全問題。因此，人們在決定配置或者接收之前，應當確保目標RSS反饋是HTTP/HTTPS形式的。當我們使用金融服務的時候，HTTPS形式是必須的。

RSS窗口小部件

JavaScript窗口小部件很受人們的歡迎，RSS反饋中也有這種小部件。人們很容易就能配置第三方RSS窗口小部件，并將其整合到網絡應用中去。為了降低安全風險，人們應當察看金融應用中所使用的RSS窗口部件的源代碼。攻擊者還可能將這些小部件用到個人網頁或者計算機中——不安全的窗口小部件有可能危及用戶會話的安全。

結論

人們越來越多地使用RSS，于是它開始與重要的金融數據庫聯接到了一起。它存在兩方面的威脅：服務器方面，攻擊者可以利用定制的反饋路由線路進行攻擊。而客戶端方面，攻擊者也可以進行會話攔截或者執行惡意代碼。盡管RSS靈活性非常高，并且能夠將數據發布給客戶，但是它的安全成本非常高。終端客戶可以閱讀反饋；如何應用這些反饋完全由終端客戶決定。這就使得雙方很難平衡，并且安全性也很低。反饋很有可能是由存在漏洞的、特殊環境中運行著的軟件所接收，這樣的話客戶端將非常容易受到攻擊。對金融服務來說，最重要的是控制RSS反饋的接收情況，還有就是進行的有效的RSS內容隔離。

=============================================

原文作者：Shreeraj Shah

原文來源：Net Square

原文鏈接：http://www.net-security.org/article.php?id=990&p=1