JoshSweeney

First Steps with CodeIgniter and JQuery

When it came time to start adding some required AJAX functionality to WapSnap, I knew that hunting down and learning an AJAX/Javascript framework was going to be one of my most daunting tasks. I had played with YUI in the past with little success, likely due to my limited Javascript experience. After speaking with a few friends that are javascript experts I decided to start with JQuery.

To start with all I needed was callback functionality. Since the only tutorial on the JQuery tutorials page with callback in the title was AJAX Callbacks with JQuery, naturally that is where I started. In this tutorial there is a get method that looks like this:

1. $.get(“giveMeSomething.php”, { number1: number1, number2: number2 },
2. function(data){
3. alert(“Data Loaded: “ + data);

The problem with the way this is written is that like the page the tutorial is hosted on, it generates ugly URLs.

WapSnap is built on the CodeIgniter framework which in the default installation means that you do not use hideously formatted parameters in the URL such as ?id=1&type=2. In CI ( CodeIgniter ) the example just given could look like /1/2 or /id/1/type/2. This structure which I find more enjoyble and visually appealing became my first problem with the mentioned article.

The code snippet shown automatically adds a question mark after the GET url and then formats and appends the data in the second parameter. This instantly caused a problem which lead me to a good bit of searching. After Google didn’t return enough entry level help for my searches I turned to the JQuery IRC channel which resulted in a solution.

For anyone else that may be looking for a solution to searches like “remove ? from get request in JQuery” or “remove question mark from get request in JQuery” The solution for me was to append the variable in the first parameter and leave out the second parameter. Which resulted in the following:

var db_id = $(‘#db_server’).attr(‘value’);

$.get(“ajax/getdatabases/” + db_id, function(data)
{

Now that the URL was being requested correctly I needed to parse the data returned. More searching lead to a funkatron article: Safely Parsing JSON In Javascript. For those of you who don’t know Funkatron, he is a well know PHP speaker, creator of Spaz the open source Twitter client, and a hilarious and helpful guy. He actually gave me my first CodeIgniter lesson on the floor at PHP | Works 08. With this article I was able to quickly and easily parse the JSON data sent back from my PHP page, something that wasn’t so easy when I first tried YUI a few months ago.

While I was debugging with Firebug I noticed that as a Javascript noob the errors weren’t as helpful as they could have been so I searched for a Javascript syntax checker. I immediately found JSLint which gave a little more in depth errors.

_{»crosslinked«}

Tags: ajax, codeigniter, funkatron, jquery, WapSnap

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