A good test to run to find sneaky authentication bugs is to edit the URL of the site you are on to see if you can get access to stuff you shouldn’t be able to see.
You might also want to change the URL and see if you can alter the data being sent or received.
Firstly it would make sense to understand how the site hangs together and which pages lead to which other pages.
You can then start to build up a profile that will help you organize your thoughts about how to try and trick the application.
So log in to your application and perform some actions, like submitting some details or checking some sensitive data. On each page copy the URL and paste it to notepad (or other tool).
Once you’ve built up a profile and a list of URLs then log out. This should now terminate that session. To make extra sure you might want to clear the cache, delete cookies and re-open the browser.
Now paste in a saved URL and see what happens. As your session is closed you shouldn’t be able to gain access to anything that required authentication (like your sensitive data).
You may also want to try logging in as someone else and pasting in the same URLs. Some of the URLS may contain account/person specific information. Therefore you may need to authenticate to view the URL. See what happens when you are authenticated as someone else.
Can you see another account?
Are you asked to authenticate again?
Any clues as to whose account it is?
Change the URL
Another trick is to look for any information in the URL that could be changed.
An obvious test would be to change the rate value and see what happens. How about making the rate a negative value? What about no value?
At the time of writing this a large global bank is in the news over a basic URL error just like this. The URL shown to a logged in user contains an account ID for the user. By simply changing this number to another number, users were able to gain access to someone else’s bank account. It is such a simple test but so often over-looked. And this was a live issue for a giant bank handling millions of peoples money. It happens.
In a sense, the above two test ideas are worthy of a decent Exploratory Testing session or two.
Seek out information, note down what happens, look for clues, work on potential security breach angles, but more than anything, have a go and learn about the potential for URL hijacking.
Using a recording tool like Selenium will give you each of the visited URLs in the script it creates whilst you work through the site.
It’s a good way of picking out the URLs of interest.
Selenium – http://seleniumhq.org/
OWASP – Direct Object References attacks
If you want to talk Testing – catch me later this year at EuroSTAR conference.