Yesterday I did my first weekend testing session. Weekend testing is an event where a group of testers hop onto Skype on the weekend to do some testing-related activity and talk about it. Collaborative learning! Very geeky, very fun.
I really have to give a big thanks to Marlena Compton for organising weekend testing for Australia and New Zealand (WTANZ), otherwise I would have been testing in the middle of the night instead of at the leisurely time of 4.30pm EST.
We had a small group of about 5 testers, and our mission for the afternoon was Jarlsberg. This brought a smile to my face – Jarlsberg is a tutorial on web security created by Google, and I’ve had it on my to-do list for quite some time now.
I had done a bit of security testing before, because in late August last year, not long after I had joined Campaign Monitor, we had a security breach by a hacker looking to use our network to deliver large amounts of spam. That was a very memorable week. We of course upgraded our security very significantly, and organised regular professional security audits, but it really drove me to improve my own security testing skills and try to work security testing into our regular test cycles.
So anyway, back to the weekend testing. We started going through the exercises at our own pace, but I think most of us just managed to get through the Cross-site Scripting (XSS) section. Cross-site scripting was a great thing to learn more about. One thing I found interesting was that if I started with a black box approach, I could notice interesting behaviours in the application (like accepting certain script tags), then when I looked at the application code it showed me why the system was behaving that way and I could extrapolate more attacks from there. I doubt I would have had as much success if I had looked at the code before trying a few things “blind” first, as it would have guided my thinking towards what the programmer DID do, rather than what they DIDN’T do.
I was glad to pick up a few more tricks, but one thing that always proves a problem for me with XSS vulnerability bugs is the bug advocacy side. Examples for methods of exposing these vulnerabilities generally give you a script that will create an alert box on the screen – if you see the alert box, then you know that scripts can be executed on this page. But try taking that to a developer to fix – “So? You made an alert box appear in your own account. It’s not hurting anybody but yourself.” The reason that the more evil scripts aren’t widely available is because basically it’s illegal to use them. So the challenge is trying to convince them that even though all they can see is alert boxes, that is because I am a nice security tester, and not an evil mastermind hacker, so I don’t know what nasty hacker tricks the hacker will use but if he sees alert boxes jumping around he’s probably going to think it’s his birthday and go nuts on it. Marlena recommended using Cornify, as a more sparkly rainbowy way to attract attention to the vulnerability, which is something I want to try.
Another thing I found interesting was that the choice of web browser made a big difference. Some browsers block certain XSS attacks by default. I was using Chrome, and in some of the exercises I couldn’t get the attacks to happen. It said in the tutorial that Chrome and Internet Explorer blocked against some attacks, so maybe Firefox or Safari would have been better for this kind of testing.
We all had a good talk about the session, and came away with some good ideas. I want to continue through the Jarlsberg tutorial sometime.
The next WTANZ session is on July 7. Marlena has some information on how to sign up here. Hope to see some new Skypers there next time!