End-users as security testers

Increasingly security testing of web applications are left to the end-user to discover. The web is generally seen as an imperfect thing, so it is not surprising that most users do not expect a website that works well 100%. What I have seen on the best Agile and Lean projects, is this is omitted to much further down the cycle, if at all – but why? Yes, they are skilled testing areas (and hence higher cost to secure fully skilled resource), but there is a lot that can be done, with the right tools and approach. And a lot can be done to create performance and security tests that can be integrated into the general development/test cycle. Too little is specified about testing in Agile and Lean, and this has caused a very varying adoption of testing processes. If the development team is skilled, then this will reduce testing overhead, but this level of testing is only part of the story.

There is a big benefit of utlising end-users, to some degree, on a web or mobile project, as they will often take user journeys not predicted. They are also the target audience, so any views/grievances can have validity. And the more skilled end users can find bugs or weaknesses not apparent, in a cosier development environment. But many have taken this as excuse to depend on the end-user far more than advised.

Most Facebook bugs are really something that could have been spotted using simple tool such as Zed Attack Proxy, or simply a Firefox plugin such as TamperData. So why? It’s a valid question, as it isn’t like Facebook doesn’t have the financial resources. This is the kind of testing a developer would most likely never do. If they have a sound approach to developing secure AJAX/JSON data transactions, then the problem may not exist. But it is one huge assumption, and security is not an area to take lightly.

The problem facing security testing is the same that blocks load testing, browser compatibility testing and web accessibility. They are generally seen as unnecessary until the end. ANy issues raised in these areas will generally be de-prioritised until the end, as open issues are perceived as blockers to the Agile flow. Very artificial. And when the end comes, unless there is reason to do them (Catch 22), they will more than likely simply be omitted. There is a strong argument for testing in Live regards Load/Performance, but unless you have some kind of contingency plan, what is going to be the response when a web application fails due to load or security issues?

One of my recent concerns was the new mantra “we work to the Google model!”. I doubt if that extends to the skills and resources affordable to Google, and simply an excuse to cut corners, whilst increasing pressure on development to get things right, first time. Whilst you may have some good developers, they will need support of QA to ensure that testing outside of Continuous Integration are covered. As I said, if you have star developer(s), the risk is significantly reduced, but that cannot be assumed.

No Comments

You can leave the first : )

Leave a Reply