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.