Global security collective outlines worst app security issues
Thu 18 Sep 2014
Global security consortium the Open Web App Security Project (OWASP) have released a comprehensive guide [PDF] to web application security testing after 18 months of research among 60 of its 30,000+ members.
The highly detailed release updates the 2008 V3 report, with additional material regarding HTML5-related technologies and vulnerabilities related to websockets and Asynchronous JavaScript and XML (AJAX) exploits, as well as identity management, client-side testing and cryptography. On the subject of websockets, OWASP Canberra chapter head Andrew Muller noted “It’s a concerning technology, a potentially dangerous technology, because you can shuffle anything down through WebSockets”.
OWASP’s was formed in 2001 and gained not-for-profit charitable organization status in 2004. Its admirers include the National Security Agency (NSA), GovCertUK, the Federal Trade Commission, the European Network and Information Security Agency (ENISA) and the Cloud Security Alliance (CSA).
Though V4 does not explicitly criticise agile development workflows, much of its initial advice for the pre-development phase does seem more suited to traditional ‘waterfall’ methods such as Rational Unified Process:
“Most people today don’t test software until it has already been created and is in the deployment phase of its life cycle (i.e., code has been created and instantiated into a working web application). This is generally a very ineffective and cost-prohibitive practice. One of the best methods to prevent security bugs from appearing in production applications is to improve the Software Development Life Cycle (SDLC) by including security in each of its phases. An SDLC is a structure imposed on the development of software artefacts. If an SDLC is not currently being used in your environment, it is time to pick one!”
The revised guide constitutes a basis on which companies and individuals can form security strategies for testing, but emphasises that its advice is not code-specific but rather aimed at changing development policy. It outlines a number of useful ‘black box’ and code-based techniques for seeking potential vulnerabilities, including tools available through OWASP’s own repositories, but struggles to find solutions to the problems of weak password ecostructures and flawed business logic in application design.
The guide, which will be translated into different languages, has a few editorial inconsistencies, referring to its own future release in 2014, and retains a 2013-dated preface from OWASP board member Eoin Keary, even though previous versions of the report occurred in 2004, 2006 and 2008.
