I am aware that this topic has been covered a million times already within testing circles. Apparently Citi didn't do their homework and put an account identifier in the URL after a user had logged in. Without any further authentication, anyone could simply change the identifier to access another user's account. You can read more about it here.
The NY Times spins this as sophistication on the part of the villains in this piece.
One security expert familiar with the investigation wondered how the hackers could have known to breach security by focusing on the vulnerability in the browser. “It would have been hard to prepare for this type of vulnerability,” he said. The security expert insisted on anonymity because the inquiry was at an early stage.
I love how things like this still happen. I tried to mentally defend the Citi folk by putting myself in their testers' position, thinking "hey, I could probably have overlooked a mistake like that as well - it's too simple, I'd probably begin testing something much more complex .." and so on. Also disregarding, of course, the fact that there were probably a whole group of testers involved in this, as well as audits by third parties etcetera.
The more I thought about it, though, the more I realize that no, no I wouldn't miss something like this. Even if I just spent a single test session on security testing, a flaw like this would be evident within the first five minutes. I hope so, at least, I really do - or I might as well hand in my keyboard and join the circus right now.
The other angle of this that is absolutely adorable is the alleged security experts who are interviewed by the NY Times.
The method is seemingly simple, but the fact that the thieves knew to focus on this particular vulnerability marks the Citigroup attack as especially ingenious, security experts said.
I think "ingenious" might be a strong word for this. Sure, if the number sequence isn't obviously a social security number or bank account number, it would require an ounce of imagination. An ounce. Didn't we do this to Hotmail accounts 15 years ago? Also no, it would not have been "hard to prepare for this type of vulnerability". If this isn't the first rule of handling accounts on the web, it should at least be among the top three.
Still, I love the whole thing. It bears witness of an innocence, a naïvité - as well as a fundamental conviction of refusing to learn anything from history that promises I will be able to find work as a tester for many years to come.
Friday, 17 June 2011
Wednesday, 1 June 2011
New Employer
On a personal note, I have recently changed employer. The choice was mine, and the reason behind it was to surround myself with like-minded testers - something my previous arrangement could not provide. Thus, since a few weeks, I am a part of the Swedish consulting company AddQ.
Short story, I love it. Suddenly, all my colleagues are experienced and committed professionals who have grazed the testing field for several years - an excellent opportunity for me to soak up all the knowledge I can handle. It also makes it easier for me to attend testing conferences and similar venues, to keep up with who's who and what's what at the forefront of testing.
I'll also try to get involved in AddQ's wide offering of testing courses and process improvement services. Closest at hand will most likely be teaching one-day classes in thread-based and session-based test management.
Another push towards further learning and valuable experiences, I hope.
Short story, I love it. Suddenly, all my colleagues are experienced and committed professionals who have grazed the testing field for several years - an excellent opportunity for me to soak up all the knowledge I can handle. It also makes it easier for me to attend testing conferences and similar venues, to keep up with who's who and what's what at the forefront of testing.
I'll also try to get involved in AddQ's wide offering of testing courses and process improvement services. Closest at hand will most likely be teaching one-day classes in thread-based and session-based test management.
Another push towards further learning and valuable experiences, I hope.
Picking Raisins
I have had the good fortune to work at a customer where there is a tradition of involving support staff in testing activities. Partly because there aren't a whole lot of dedicated testers, but the benefits extend beyond pure addition of manpower.
In an organization developing a complex system, a lot of roles tend to be filled by domain experts; customers, perhaps, with long experience of using similar systems. It's easy to see how an individual with extensive knowledge of the domain would fit well into the support department or as a product owner, for instance. As a tester? Naturellement.
It might be difficult, I imagine, to find a team of people with good product knowledge and refined testing skills - or at least quite time-consuming to train such a team. So why not simple pick the finest raisins from both cakes (assuming you like raisins .. if not, reverse the analogy) and have a customer-savvy product whiz performing exploratory testing together with a tester who can add fuel to the testing fire in the form of test ideas and techniques. The tester should also take care of documentation - i.e write a session report, keep track of any deviations from the charter and file trouble reports - to maximize their co-tester's play time with the software.
I'm doing just this at my current assignment, and I love it.
Of course, allocating resources from different departments always requires some planning ahead and can be subject to sudden change - but once things fall into place, testing is a breeze. The service-minded contributors have really appreciated the level of steering that the charters provide, and the testers get an opportunity to learn lots about how the product is perceived and used by the customers.
In an organization developing a complex system, a lot of roles tend to be filled by domain experts; customers, perhaps, with long experience of using similar systems. It's easy to see how an individual with extensive knowledge of the domain would fit well into the support department or as a product owner, for instance. As a tester? Naturellement.
It might be difficult, I imagine, to find a team of people with good product knowledge and refined testing skills - or at least quite time-consuming to train such a team. So why not simple pick the finest raisins from both cakes (assuming you like raisins .. if not, reverse the analogy) and have a customer-savvy product whiz performing exploratory testing together with a tester who can add fuel to the testing fire in the form of test ideas and techniques. The tester should also take care of documentation - i.e write a session report, keep track of any deviations from the charter and file trouble reports - to maximize their co-tester's play time with the software.
I'm doing just this at my current assignment, and I love it.
Of course, allocating resources from different departments always requires some planning ahead and can be subject to sudden change - but once things fall into place, testing is a breeze. The service-minded contributors have really appreciated the level of steering that the charters provide, and the testers get an opportunity to learn lots about how the product is perceived and used by the customers.
Subscribe to:
Posts (Atom)