JoshSweeney

Attack Detection and Remediation with RIA’s

First off, What is a RIA – RIA is the term used to represent all web 2.0 type frameworks and technologies. It stands for Rich Internet Application. This encompasses frameworks like Dojo and Appcelerator.

Many security experts have gone into great detail to outline how RIA’s and AJAX based applications can be insecure or to present new ways to use old attacks against these applications. However, I have not seen anyone attempt to find a positive security aspect around RIA’s. In this article I will outline one way that the rise of RIA’s can be leveraged to provide a more secure website.

The requirement of javascript to use RIA’s or AJAX enabled websites is quickly becoming an Internet standard. A small portion of users still refuse to run javascript because of security risks but this will probably go the way of the cookie disabling of the 90’s. Since javascript is becoming a standard it makes the requirement of having javascript enabled more feasible.

With the requirement of javascript, RIA’s offer an interesting opportunity to more accurately detect attacks. Frameworks like Appcelerator have built in validators but as we all know, javascript validators can be bypassed. This is why all developers must use server side validation. The coupling of client and server side validation presents the opportunity for web application to do more complex attack detection and remediation.

By exactly matching the client side and server side validation mechanisms we can accurately tell if someone is attacking an input. Here is how: Say that we have built a new site using PHP and Appcelerator. Appcelerator has built in client side validation of fields, such as valid email address checking using regex. This will provide the immediate error feedback via javascript that users love. For the server side validation we will use the exact same regex. Knowing that both the server and client side validation is exactly the same and that javascript is a requirement to use the website, we now know that if we get a request on the server side that doesn’t match the regex then our javascript was bypassed.

Lets look at an example. A user visits the site and has javascript enabled and therefore receives any error flags on the client side. The user types an attack in a username field and then receives an error letting them know that this is not valid data. The next step is to either disable javascript or use a proxy to change the request. Since the site doesn’t allow rendering without javascript the user uses a proxy. On the next attack your server side validation receives a request that doesn’t meet the regex then it can be assumed to be an attack.

The core fact to keep in mind is that RIA’s require javascript to use the site. Therefore if javascript is disabled then the user will not be allowed to use the site or will be redirected.

The next step is to log attacks and execute remediation in real time. Since the attacks are validated at two layers, when the bottom layer receives an attack it is less likely to be a false positive. Since it is less likely then it will receive a higher certainty value. The attack certainty values can then be stored with the corresponding IP address for calculations. In my live testing I used a cron script to run calculations on the attacking IP address and then block the IP once it meets a certain attack threshold.

The key to this system is how attack metrics are assigned. Say for instance your site uses a RIA but also allows people without javascript to browse. In this instance the system would detect that javascript was disabled and as a result lower the attack certainty value. Adding other security systems such as PHP-IDS would result in a greater level of attack detection. These two systems coupled together will provide enormous insight into the number of times your site is being attacked and how.

Tags: ajax, appcelerator, application security, attack detection, ria, security