WeTest focuses on security

Explore Assurity 11 June 2013 Katrina Clokie

Security is an important topic that’s regularly in the news so testers have to be aware and diligent. Reading security documentation makes it seem like only gurus can understand vulnerabilities. In fact, not all aspects of security are difficult. Many testers have even unknowingly found security defects and may or may not have picked their severity correctly!

David Robinson presented a number of practical tips for security testing at the fifth Wellington Tester Workshop at Assurity’s new Wellington office on 23 May. He hoped to break some of the misconceptions around security testing and give attendees some new skills and confidence in identifying security issues.

David began by speaking about when security testing usually occurs in a project and who’s responsible for it. In his experience, it was an activity left late, usually completed by a third-party penetration specialist. David thought that it was better for the project to start considering security earlier in the development lifecycle to reduce the risk of discovering major flaws close to production deployment deadlines.

David then shared a number of practical tips, many of which are shared in his blog post from the event, including:

• Treating all data that enters the application as hostile

• Switching off Javascript in the application and checking the server side validation of user input

• Using a string containing all possible non-alphanumeric characters – particularly good at detecting potential cross-site scripting (XSS) vulnerabilities

• Ensuring that stack traces are not visible in the application

• Using https for all of a web-based application, not just the login screen

• Prior to testing beginning, asking for a security review of architecture and design documentation

• Reviewing patch levels of third-party applications and libraries, particularly where patches contain security fixes

• For updates to an existing application, use the previous penetration test report as a resource for security testing of the new release

• Using the OWASP Top 10 to increase your awareness of common security problems

As discussion opened, the first debate centered on how many of these practical tips testers should really be using. There were opposing views on the value of a tester attempting to find simple security issues in the application when security was not their responsibility, but rather that of a third party.

One side of the argument looked at the opportunity cost of a tester deciding to look for security problems: "What else could be done with that time?". They proposed that security testing was best left to the specialists who could find many of these easy security problems very quickly. The idea that issues found later in the project were more expensive was also dismissed, with a recommendation to read The Leprechauns of Software Engineering by Laurent Bossavit.

The opposing view spoke of the need for testers to grow their skills. In learning about basic security problems, the tester would change the way in which they viewed the application – which would be beneficial to the organisation. Testing from a security perspective was thought to be an effective way for a functional tester to de-focus without being unproductive.

After the break, there were a number of smaller discussion threads as we picked off some niggling questions from around the room. Should all data really be treated as hostile, even for internal applications? Does a Denial of Service attack fall in to the security spectrum and how could we test for that? Was anyone using tools for security testing that they would recommend? Has anyone had experience with social engineering? What is actually in the OWASP Top 10? It was great to see the variety in topics and conclude a workshop with all the green threads addressed.

Thanks again to Assurity for supporting another great event for the Wellington testing community. We look forward to our next WeTest get-together in early July.