The OWASP project is concerned with all aspects of application security and trust. Developers play a crucial role in delivering secure applications; if the code doesn’t follow sound principles to begin with, it’s built on a shaky foundation and can’t easily be fixed. OWASP provides plenty of resources to help developers create secure applications.
They aren’t all polished works. Some are under ongoing development and are incomplete or in a hard-to-use format. However, all of them include a trove of information for managers and developers trying to create the most secure code possible.
In 2014, OWASP issued a complete rewrite of its Developer Guide, which dates back to 2002. Before its current release, it was really more of a guide to penetration testing. There’s now a separate Testing Guide as well.
The Developer Guide is a collection of Markdown files, which is inconvenient to view. The documentation recommends using GitBook, which is complicated to install and run. The least cumbersome way to view it may be to download the ZIP file from GitHub, expand it, and view individual files in a text editor.
The Developer Guide doesn’t get into the details of coding and isn’t language-specific. Rather, it describes principles to follow. It has advice for managers as well as developers. It’s a work in constant progress, and some parts are obviously incomplete. People responsible for software development projects should familiarize themselves with it, but how they apply its recommendations will vary greatly from one project to another.
Code Review Guide
The Code Review Guide will also help developers to create consistent procedures that will improve the safety of code. This one is available as a downloadable PDF. It’s aimed at three audience segments: managers, lead developers, and code reviewers. The document distinguishes between “code review” and “secure code review,” with the latter being a more focused practice.
A large part of the document covers methodology, including risk analysis, threat modeling, and analysis of the application. Then it goes into the OWASP Top 10 issues and technical considerations for each of them. This document gets closer to the actual coding process than the Developer Guide does. It covers specific scenarios and includes code examples.
Top 10 Cheat Sheet
We usually think of a “cheat sheet” as having brief, direct instructions on how to do things, but the OWASP Top 10 Cheat Sheet isn’t really that. It’s a hierarchical list of points for addressing the Top 10 vulnerability types. For each issue, it includes points under Presentation, Controller, Model, and Testing.
Unfortunately, it doesn’t include an explanation of these categories. In some cases, the same recommendation appears in more than one category. It’s probably best to look at the Presentation, Controller, and Model points as a single collection of useful advice without worrying about the category distinctions.
The Testing points, on the other hand, are links to descriptions of specific tests. Many of these descriptions explain coding antipatterns that need to be avoided, so they’re useful reading for the developer.
Application Security Verification
The OWASP Application Security Verification Standard Project aims at defining a standard for verifying that code has met certain requirements for avoiding or mitigating risks. OWASP’s recommended approach is to use it to create a checklist for a particular situation or organization. OWASP doesn’t certify software; the standard is only a set of recommendations.
It defines three verification levels:
- Level 1: for all software. It’s sufficient if the software doesn’t deal in high-value information.
- Level 2: for software that handles sensitive data. Healthcare information and customer records are examples.
- Level 3: for software that requires a high level of trust. Military activities and critical infrastructure fall into this category.
The requirements at each level are a subset of the requirements at the next higher level. They’re grouped into categories such as authentication, malicious input handling, error logging, and HTTP/HTTPS configuration.
The document is available as a clean PDF file, without any obvious signs of incomplete work.
Security Knowledge Framework
The OWASP Security Knowledge Framework isn’t a document but a software tool. It asks the project manager questions and generates a security checklist based on the responses. Project leaders can use the checklist to guide development and review. They can use the tool to consult the knowledge base for explanations of terminology and threat families. Examples of securely written code are available in several programming languages, including Java, PHP, Ruby, Python, and Go.
The SKF tool is written in Python and will run almost anywhere. An online demo is available. Just studying the code in the developer’s preferred language will provide a lot of ideas for writing secure applications.
Broken Web Applications Project
It’s helpful to learn from negative examples as well as positive ones. The OWASP Broken Web Applications Project is a collection of deliberately vulnerable applications, running on a virtual machine, for study. This appears to be an incomplete project developed by one person, and it hasn’t been updated in a few years. It could still be an interesting resource for code analysts and penetration testers.
On a lighter note, the card game OWASP Cornucopia is basically a framework for raising a project’s security issues in a geeky, informal environment. The cards have five suits, plus a trump suit called “Cornucopia.” (Might “Pandora’s Box” have been more appropriate?) Each player in turn plays a card, such as the “queen of data validation and encoding,” whose text describes a security issue. If the consensus is that the card identifies an existing concern in the project, then the player gets a point. Card files are available which can be printed out on card stock and cut up.
OWASP offers free, downloadable resources for many aspects of secure software development. Some are better polished than others, but all contain valuable advice for managing a project so it has the necessary level of security built into it. The lesson that runs through all of them is that adding on security afterward won’t work, and neither will a vague commitment to writing secure code. Developers need to work with lists of specific concerns, and they have to make sure the code satisfies them as it’s created.
The single most useful resource appears to be the Developer Guide. Hopefully OWASP will soon make it available as a single, downloadable document, so that as many project managers and lead developers as possible will pay attention. Even in its present form, it’s worth navigating the multi-file format for the information it contains.