Introduction to the OWASP Top 10
Since 2003, the OWASP Top 10 has become the de facto generic vulnerability standard for many in the industry. It offers a valuable insight into where we as an industry are heading, as well as which areas we’re still struggling to resolve.
First of all, what is OWASP?
OWASP is the “Open Web Application Security Project”, a non-profit organization with the goal of improving security of web applications. It has been running for the last 20 years and in that time has become synonymous with everything from tooling and documentation to standards.
Got it. So what is the OWASP Top 10?
This lists out the top 10 most impactful vulnerabilities an organization should focus on when looking to improve the security of applications and reduce their overall risk. It has become the de-facto standard in application security, and is often referenced in security tooling as well as other materials, like penetration reports and training.
Broken Access Control
Access control limits the exposure of resources, including data and application features, to unauthorized entities. This category covers vulnerabilities that allow for unauthorized access, either by a human or by other systems, to the resources you want to protect.
This category used to be referred to as ‘Sensitive Data Exposure’. Protecting sensitive information is an important step to securing an application, and cryptographic functions are often used to do this; for example, by using encryption to encrypt a database password, hashing a user’s password, or correctly configuring TLS within an application.
This category covers vulnerabilities where weak or flawed cryptographic configuration and/or implementations have been used, thereby risking the exposure of sensitive data.
Numerous technologies are capable of interpreting or translating data into a form they can understand and consume. Additional data can be inserted (or injected) into existing data to be interpreted and used by the system. This is known as an injection vulnerability.
Designing security from the beginning is part of the “shift left” mantra. Ensuring security is baked in from the beginning of the development process will result in a more secure application or feature. Leaving these types of decisions until after implementation will likely be more taxing and costly to address, and in some cases may never be addressed at all. Many insecure design flaws can also be attributed to business logic vulnerabilities.
An application is only as secure as the environment it operates in. Technology has many configuration settings which can be changed and tweaked, some of which are security-focused or can have an impact on the security of the system. Vulnerabilities covered by this category point to where a system configuration was incorrectly or insecurely set.
Vulnerable and Outdated Components
Over recent years, there has been an explosion of applications and systems leveraging third-party components such as open-source libraries and frameworks. This is fantastic from a delivery perspective since it allows for faster delivery; however, like most code, these components have vulnerabilities of their own or fall out of support. The result is that the application or service which uses the component could also be vulnerable.
Identification and Authentication Failures
Authentication is the process of identifying who is accessing a resource, so it’s important that it is robust and effective. If there are any flaws during this identification process it could allow others – including those with malicious intent – to access the resource.
Software and Integrity Failures
Security Logging and Monitoring Failures
Attribution and auditing is an important concept in security. Although this will rarely prevent a security incident, it certainly helps with the investigation and recovery. You need to be able to determine who did what and when. Similarly, it is important to monitor logs, especially security-related logs and events, so you are alert to when an attacker is attempting to target the application or service.
Server-Side Request Forgery (SSRF)
This vulnerability occurs when an application or service retrieves a user-defined resource without validating that is a valid resource. This allows for an unintended interaction with unintended resources.
Embed security expertise across the software development lifecycle
Application security is critical to your organization’s software development lifecycle, from your front-line developers, to QA/testing, and operations. With a constantly evolving threat landscape, SDLC members must have the knowledge, skills and judgment to keep pace with emerging attacks.
Immersive Labs’ solution for development and engineering teams enables confident and accountable tasking, upskilling, and the development of security champions by providing:
- Targeted role-specific training injected into individuals and teams
- Constantly updated lab content, covering new vulnerabilities, tools and techniques being exploited in the wild
- Evidencing and baselining of the capabilities of the development team using data insights mapped to risk
- A platform designed to appeal to creative hands-on individuals
- A way to 'shift left' which doesn't require significant resource drain on security teams