RSS Security Threats With Financial Services

Web 2.0 technologies are penetrating deeper into the financial services sector as Enterprise 2.0 solutions, adding value to financial services. Analysts can leverage information sources to go beyond the obvious. Trading and Banking companies like Wells Fargo and E*Trade are developing their next generation technologies using Web 2.0 components; components that will be used in banking software, trading portals and other peripheral services. The true advantage of RSS components is to push information to the end user rather than pull it from the Internet. The financial industry estimates that 95% of information exists in non-RSS formats and could become a key strategic advantage if it can be converted into RSS format. Wells Fargo has already implemented systems on the ground and these have started to yield benefits. RSS comes with its own security issues that assume critical significance with regard to financial services. In this article we will see some of the security concerns around RSS security and attack vectors.

RSS feed manipulation with JavaScript and HTML tags
RSS stream gets builds from databases or input supplied by users. RSS streams can source information from third party sources such as news sites, blogs, etc. Financial services incorporate this information for end user’s benefits and it get served in the browser along with other sensitive information. If RSS feeds originate from untrusted sources then they are likely to be injected with JavaScript or other HTML tags. These malicious tags can have capabilities to exploit the browser. Financial systems must have sound filtering lists prior to forwarding any information coming from the end user to the system or filtering certain character sets that hit the end browser. Increasing RSS consumption is going to put at risk clients in financial sectors. To combat the threat, RSS input and output validation must be handled in the application.

Cross site scripting (XSS/CSS) with RSS feeds
The cause of successful RSS exploitation with XSS lies in RSS script injection. RSS that is injected with JavaScript and successfully passed to end clients in financial systems can lead to exploits such as RSS feeds with SCRIPT or HREF with “onClick” being successful on these systems. Several exploits written on top of XSS exist, by with attackers can hijack sessions or run keyloggers on the session. All these exploits can put the financial system at risk. Once again, countermeasures to this threat lie in “filtering” the characters before they hit the end client. Browsers don’t have any built in filtering capabilities and application layer needs to support it for better security. Extra precaution is needed against cross domain calls as well cross site RSS access.

CSRF with RSS feeds
Cross Site Request Forgery is another attack vector that can be exploited through RSS feeds. If a feed is injected with certain HTML tags like or any other tags that allow cross domain calls, these calls replay the cookie causing a CSRF exploit to be run. CSRF attacks expand possibilities for exploits to be run on financial applications that are vulnerable. An attacker has greater opportunity since the target set and scope is defined.

Consider a financial portal for banking operations application that runs with an RSS feed reader component. This component has a set of applications for trading and other services running on different domains. One of these domain applications is vulnerable to CSRF and shares the “single sign on” methods either by cookie or by a common database access. In this case, an attacker can craft an RSS feed in a way that is best suited for CSRF exploitation over broad range CSRF exploit distribution for maximum effect. Targeting RSS feed readers can help in leveraging this attack vector when the end user can be identified.

SQL injection for RSS feed manipulation
Usually SQL injection is a synchronous attack vector directed at Web applications. In a SQL Injection attack, an attacker sends a particular payload and observes the response. If responses conform to SQL injection success signatures then the situation can be exploited further.

Now, new applications provide RSS feeds for your customized needs. For example, RSS feeds for the last 10 transactions or statements for a particular period, etc. All these parameters can be supplied by the end user and will be used to craft the SQL query for the RSS feed generation program. If RSS feed generation program is vulnerable to a SQL injection, a SQL payload can be crafted and passed to the RSS feed to cause an asynchronous SQL injection attack. This attack gets successful over time when this feed generator program runs the user request and builds a customized RSS feed for the client, leading to unauthorized information access. A proper code review of the RSS feed generation routine is a must to prevent this attack; this attack vector is asynchronous and difficult to identify using a black box approach.

Authentication and Authorization issues with RSS feed
RSS doesn’t have an authentication header mechanism over HTTP so RSS feed delivery must be authenticated at the web server or at the application level. RSS is a static XML feed. From a security perspective, this is a difficult equation. It is possible to retrieve an RSS feed that is kept open without any authentication. If an application is serving RSS feeds with hidden parameters or security tokens then it may be possible to guess or bruteforce the parameters based on minimum available information. A legitimate user of a banking application who knows the URL to access his feed may try different combinations of the URL and get access to another user’s feed. This scenario is possible depending on the way the application layer is implemented for RSS feeds. Often RSS feeds that are locked using Basic/NTLM authentication can be bruteforced. A strong application layer feed defense integrated with session checking is required for critical financial information. Sensitive information such as passwords that are being passed to online RSS readers make for another security issue that must be addressed. Hence, “where to read your RSS feed” is very important when dealing with financial services.

RSS encryption issues
RSS encryption is not possible at XML level. Unlike Web services, there are no existing RSS security standards. Atom has XML encryption and signature methods but is yet to gain in popularity. To secure RSS information in transit one needs to use it over HTTPS. If a customized encryption mechanism is in place then one need to pass “key” information to some place, either to the browser or a third-party application. This in itself, is a risk. RSS encryption needs to be point-to-point for better security otherwise it could be sniffed in transit needlessly opening up a security issue. Hence, one needs to make sure the target RSS feed coming on HTTP/HTTPS before making final decision on configuring or consuming. It is imperative to have HTTPS when we are looking at financial services as a target.

RSS widgets
JavaScript widgets are popular and are available for RSS feeds as well. Third-party RSS widgets are easy to implement and integrate in web applications. Source code reviews must be conducted on RSS widgets used in the financial application to smooth out security issues and mitigate risk. It is also possible to use these widgets on personal pages or desktops – another scenario in which unsecured widgets can compromise user sessions.

Conclusion
RSS is getting popular, as a result of which it is being linked to important financial databases. It poses a threat in two dimensions. On the server side customized feed routines can be exploited by an attacker. On the client side session hijacking and malicious code execution is possible. RSS offers great flexibility and capability to push data to the client but the security cost involved is high. Feeds are available for the end client to read; how to consume feeds is up to the end client entirely. This makes the equation difficult and less secure. This feed may be consumed by vulnerable software running in a specific zone context and the client may be vulnerable to exploits. For financial services it is important to control the consumption of the RSS feeds along with the content to make a secure RSS compartment.