Who moved my session? : Best practices for preventing session abuse in Web Applications !

Recently someone came to me with a question on how to prevent users of a web application from misusing the session. Specifically, she wanted to know how to prevent users from copying a cookie from another user and then using that to stay logged in for a long time.

Digging into the subject a bit, it became clear that session attacks are one of the tricky ones to test and protect against, as every countermeasure that you take has some negative effects also on the user (either as a flexibility or user experience trade-off)

As described in this link, http://www.lucato.it/session-security ; the session atttacks fall into three categories : Session pollution, Session hijacking and Session Fixation.

This link http://www.acros.si/papers/session_fixation.pdf gave a background on the need of session and details about the session fixation and session Hijacking, and the possible measures that the developer can take to ward off these attacks.

However the list of countermeasures is always a trade-off, as said before.
A list of measures that are not much restrictive from a user experience point of view, and are effective from a security point of view is needed.

Some useful measures :

-    The sessions expire in 30 minutes

-       The cookies are configured as httpOnly and secure (not all browsers support this, notably Opera and Safari)

-      Randomly change the session ID

-      Invalidate any previous sessions on login each time, with the consequence that you can have only one login instance active at a time.

Automated acceptance testing of Android Mobile Apps using Robotium

Robotium : your mobile application's trusted friend

Acceptance testing (testing the product as a black box, from the end costumer’s perspective) is required for all products before delivering to the client.  In the case of Mobile Applications, this is complicated by the diverse platforms available and the time that is needed to test these manually. This is further complicated by the fact that in these days, the same application might be ported to various formats (Symbian, J2ME, iPhone, Android, Palm, Web-app, etc..). Manual testing of these applications are time consuming and error prone, and hence a better solution needs to be found.

Automation of such tests is a time tested solution, borrowed from the PC environment, where tools such as Selenium has been used for years to do automated acceptance testing. 

Robotium is an open source project, aimed at bringling selenium-like functionality of test automation to the Android platform.

Assuming you have a basic knowledge of Android application development. Read the references indicated if not.

Getting to run from Eclipse

Step 1. Installing android sdk and building and running your application on the emulator.

Step2: download Robotium and include it in the project references of your application

Step3: build with the new robotium,

Step 4: Run as Android JUnit test case

Getting to run from outside Eclipse:

Go to the project directory, do android –p . …

Now that you can manually do this, let us see how we can integrate this to a Continuous Integration tool such as Hudson.

Step 1: install Hudson

Step2: install the android sdk and Robotium as the user Hudson

Step3: install ant android plugin of Hudson

Step4: include svn

Step5: in the ant build options, give your build.xml of the project

Now when you start a build, from Hudson, you can see that  there is an INJECT_EVENTS_PERMISSION needed error for the application. This is due to the fact that the screen Is locked. So you need to programmatically unlock the screen. I have a program that does this, (thanks to this blog post), and it needs to be installed and launched prior to the test application.

Making sense of the results..

The results are written to a log file, this could be parsed to see success or failure.

Firefox fails ecmascript test

ECMAScript, the self proclaimed "language of the web" has become the cornerstone of contemporarty web front end engineering.

There is an official test suite maintained by ECMAScript, which will allow anyone to test his/her browser against the specs. This would run a test suite of more than 1000 tests and give a report.

I evaluated FireFox4, Safari on my Mac OSX 10.6.7

Firefox 4 results of ECMAScript at test262.com

Turned to Safari5