OWASP Top 10: Key Takeaways from a Secure Code Training Course

I recently attended a Secure Code Training course hosted by PrivSec Consulting. The course broadly followed the OWASP Top Ten, representing the most critical security risks to web applications.

The course highlighted how easy it is to miss small issues with significant security implications and the importance of understanding and mitigating these vulnerabilities. The course goes much more in-depth about each vulnerability, known exploits, and hands-on exercises to exploit them yourself which were particularly helpful in understanding each vulnerability's anatomy. I highly recommend this course to anyone interested in application security or penetration testing.

This article summarizes the key takeaways and mitigations discussed in the course.

The list is in the same order as the OWASP Top 10, which is sorted from most to least impactful. This isn't to say that number 10 on the list can't be just as devastating as number 1; it just outlines the broader risk as identified by OWASP.

If you want to learn more, hit us up at Abletech!

1. Broken Access Control #

Being able to access things you shouldn't be able to can result in users being able to edit another user's account data, access restricted pages, perform actions while unauthenticated, or read arbitrary files via path traversal.

Exploit example: If relying purely on client-side validation, a malicious user might change information in the payload sent to the server, such as making changes to another user's data by changing the user ID in the request body.

Mitigations:

• Deny access by default unless the resource is public.
• Ensure validations are also performed on the server, including checking that the user requesting to view or change information has access to the resource, is able to perform the specific action, and is only able to provide a list of permitted values.
• Any information that doesn't need to be provided by the user shouldn't be.
• Lock down resource handlers to specific public directories so path traversal is not possible.
• Only return as much data as needed.
• Implement alerting for large influxes of requests, specifically 401/403, which might indicate a malicious party is attempting to see what they can and can't access.
• Embody common vulnerabilities into unit tests so you will be aware if code changes introduce vulnerabilities.

2. Cryptographic Failure #

A breakdown in encryption/security that leads to exposing sensitive data.

Examples include:

• Using a weak password hashing function.
• Using passwords as cryptographic keys.
• Accidentally checking secrets or keys into git.
• Implementing your own insecure algorithms.
• Presence of Cryptographic Oracle (an oracle is any system that can give some extra information on a system, which otherwise would not be available).

Exploit example: A malicious user could find a secret key hard-coded into JavaScript and use it to impersonate other users.

Mitigations:

• If you don't need it, don't store it.
• Encrypt all data in transit and at rest.
• Disable caching for any sensitive data.
• Don't roll your own crypto.
• Ensure error messages don't give any insight into the system.

3. Injection #

When a client is providing data, there is a possibility of injection where the user can cause some unexpected behavior with their input.

Examples include:

• SQL Injection
• Cross-Site Scripting (XSS)
• Command Injection
• Template Injection

Exploit example: If an application is sorting items on a page using query params with keywords like DESC or ASC, they might be feeding these user inputs straight into the SQL query. We can send another malicious query instead and potentially get information about the structure of the database or users' password hashes.

Mitigations:

• User-provided data should be untrusted.
• Any client input should be sanitized before usage.
• Use prepared statements and parameterized queries to handle data inputs.

4. Insecure Design #

This refers to design flaws in application development that expose security risks and may be consequences of application architecture.

Examples include:

• Actions that use unnecessary user input.
• Returning whether an account with a provided email exists on login/reset.
• Leaving deployment artifacts such as .git in the web root.

Exploit example: If your application returns an error saying this user doesn't have an account on the login or reset flow for provided email addresses, a malicious user can use this to determine which accounts exist and use this information in further vulnerabilities.

Mitigations:

• Use secure and established design patterns.
• Use threat modeling to identify potential security issues.

5. Security Misconfiguration #

This refers to security settings or configurations that may be implemented or set improperly.

Examples include:

• Default username/password.
• Bad error handling that gives information about the underlying system.
• Intentionally disabling security features.

Exploit example: A default admin account exists for some applications. If the password for this account hasn't been changed, malicious users may be able to access the application's admin functionality with a known default username/password.

Mitigations:

• Regular audits of configuration.
• Automate the process of deploying configuration to avoid human error.
• Use Infrastructure as Code (IaC) to store configuration in repeatable and reviewed code.

6. Vulnerable and Outdated Components #

Components are constantly being updated and improved as new vulnerabilities are discovered. It is important to keep them up to date as older versions may be susceptible to other vulnerabilities on this list.

Exploit example: A malicious user is able to use a known flaw in a dependency to compromise your application.

Mitigations:

• Keep software up to date.
• Use dependency checking tools like Dependabot to alert you to vulnerabilities.
• Avoid using unmaintained components that aren't getting security updates.
• Make sure you are downloading components from a reputable source.
• Remove any unused dependencies.

7. Identification and Authentication Failures #

Security weaknesses in the application's identification and authentication processes that lead to unauthorized access.

Exploit example: If you aren't prompting for the current password when changing a user's password, a malicious user can leverage this to use cross-site scripting to take over another user's account.

Mitigations:

• Implement Multi-Factor Authentication (MFA).
• Use a strong hashing algorithm.
• Lock accounts after failed login attempts.
• Use established design patterns.
• Implement strong password requirements.

8. Software and Data Integrity Failures #

Code and infrastructure that doesn't protect against integrity violations can lead to unauthorized software modification and malicious code execution.

Exploit example: If a malicious user is able to replace a package your application depends on, or if you are using an untrusted package in the first place, they might be able to compromise your application without you knowing.

Mitigations:

• Ensure your libraries and dependencies are coming from trusted sources.
• Ensure your CI/CD has good segregation and access control.
• Use dependency checkers.

9. Security Logging and Monitoring Failures #

This occurs when there is insufficient logging or monitoring which might leave you unaware of suspicious activities or when security breaches may have occurred.

Exploit example: If a malicious user is attempting to brute force a bunch of different path combinations in the hopes of gaining some information about the system and you aren't being alerted, this may go unnoticed and you won't have the chance to stop them.

Mitigations:

• Persist logs somewhere that is not locally on the server.
• Monitor logs in real-time to look for suspicious activity.
• Set up alerts if certain conditions are met (e.g., failed login or 403 responses).

10. Server-Side Request Forgery (SSRF) #

This is a vulnerability that allows an attacker to cause the server-side application to make requests to an unintended location, often bypassing security controls.

Exploit example: A malicious user may upload an SVG image that contains a URL to some domain they control. If this is executed, it may be used to gain information from the server.

Mitigations:

• Validate and sanitize user input.
• Implement firewall rules and network segmentation to keep servers contained.