Introduction to the OWASP Top 10

Welcome to the second part of World Wide Web Fundamental Session. In the next couple of minutes you will be introduced to the OWASP Top 10 Project and the latest published version of the awareness document. We will start with some facts about the project. Then we will do a walkthrough of the latest published version of the document. And we will close the session discussing how it is built.

The project by its author’s own words: “The OWASP top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.” The project is led by four well-known OWASP volunteers – Andrew, Brian, Neil, and Torsten. With a few little changes since it was first published, the document brings security awareness to developers and managers. It was generally adopted by software industry. And there’s always a huge expectation when the time comes for the next update. The document has been updated and published since 2003, and translated in several languages by volunteers. If you don’t find yours, I challenge you to lead that effort.

The more languages the document is translated into, the more people the message will reach. This is the project page where you’ll find a quick overview of the latest published Top 10 as well as several other links. If you prefer to read the document in your own language, look for it in the Translation Efforts tab.

If you’re interested about the source or have a question or comment, then you should go to the GitHub repo.

Better than talking, let’s see how the document looks. This is the latest published version at the time this course is being recorded. The document structure hasn’t changed that much, and you may expect future versions to keep the same structure.

The Release Notes section provides relevant information about how that specific version was built and how does the final Top 10 compares with the previous version. Let’s see how the top 10 security risks are presented in the document.

Every security risk in the top 10 looks like this one. For the next 10 sessions, we will go through all the 10 security risks, and we will exploit them in an intentionally vulnerable application. Let’s now discuss how the Top 10 is built. The process starts with a public call for data, so that companies and individuals can contribute their data. Provided data should include some metadata, such as whether the results came from a human-assisted tool or a tool-assisted human approach and the list of vulnerabilities following the core Common Weakness Enumeration. Attribute to date is analysed and normalised and some may be subject of reclassification to group things in bigger buckets.

Then comes the risk rating, which we will discuss in more detail in a few moments, but which is based on the OWASP risk assessment framework available at OWASP.org. A Top 10 draft is presented to the community for discussion and contributions, which you may expect to happen in the GitHub repo. With a table like this during our walkthrough of the document, each factor exploits ability, prevalence, detectability, and technical impact range from one (low) to three (high). Doing the simple math, you will get the risk rating used to sort of Top 10 security risks. Note that neither likelihood of the threat agent nor the business impact are taken into account.

The later is business specific and each organization should decide how much security risk it is willing to accept. Factor ranges are given by the Top 10 team. Excitability and detectability are based on public CVs. Prevalence is computed from contributed data. And the technical impact is an estimation. When the final document is published, all this was extensively discussed among the community representing a broad consensus. In the next part, we will discuss how the world wide web works.