像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