Rich Internet Applications – The New Security Frontier

In the past we have been relying on the web browser to provide/restrict the user interface for interacting with applications on the Internet. As security teams slowly work to fix the usual SQL Injection, XSS, Input validation attacks there is a whole new can of worms(or opportunities) waiting just around the corner. This is related to the recent trend starting with Ajax and more complex technologies like Microsoft's Acropolis -  which allow you to provide a rich user experience when interacting with applications on the Internet. This trend removes the restriction that the user interface for web applications be restricted to a web browser and instead allow for thicker/richer stand alone clients with "rich client-side code".

Now, this trend opens up new security opportunites as developers are no longer restricted to programming internet applications assuming a very thin client; they are able to/and are pushing a lot more UI and other functionality into client side code. However, most developers are assuming that the client side code is also trusted and hence are failing to take into consideration the potential security issues that open up with this assumption. Very basic assumptions such as when client side code that connects to a webservice - will make the WSDL of the webservice public; such issues are not being considered by the application developers.

So what does this mean to web application security in the long run? This potentially means that hackers will soon be targetting these "rich client-side code" applications and will reverse engineer them to expand the attack surface on the server-side code of these applications. You will begin to see a new set of security issues with these thick client web applications.

Now, the one thing to remember here is that some intranet based applications (mostly Line of Business applications) have been using this approach of having "rich client-side code". And most security teams like ACE have been ensuring that these "rich client-side code" LoB applications have the right security assumptions. This experience will prove valuable in securing the next wave of Internet applications that have a "rich client-side code" or thick clients.

What should your action plan look like to accomodate for these new threats? If you are a company that is building new Internet applications - educate your developers that client side code cannot be trusted and trusting it will expand the exposed attack surface on the Webservice. Furthermore, look at building a proper security development process for building these new rich internet applications. Utilize the IT Infosec departments expertise in securing rich Line of business applications and get their guidance on securing these new web applications.

Here are some articles that talk more about Rich Internet applications.

These predictions are solely my thoughts and do not represent any opinions of either Microsoft or the ACE team.

Deepak Manohar

Comments (3)

  1. cbchhaya says:

    I think the most important part of your posting is the one where you suggest that dev teams should consult the IT infosec departments, educate developers and build a process around embracing these technologies. I say this because of a recent experience I had where a developer asked how he could pull information off another server not on his domain, and a second developer responded with a slew of options, including dynamic script tags and using the FlashXMLHttpRequest (redesign the app) or change the domain to the parent if host is on same domain domain. While these are “legitimate” in terms of hacks or techniques, a well-informed developer would never post these suggestions and an active IT InfoSec department would never allow an application with such a design through. I guess the application designers need to be educated as well so that they can come up with a design that then does not require hacks or workarounds.

  2. South india tourist spots says:

    I say this because of a recent experience I had where a developer asked how he could pull information off another server not on his domain….

Skip to main content