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.