Get ready to learn about and exploit each of the OWASP Top 10 vulnerabilities; the 10 most critical web security risks.

Time for our daily #FromZeroToHacker challenge.

Table of contents

Introduction

What I have learnt today?

Stats

Resources

Introduction to OWASP Top 10

The OWASP (or Open Worldwide Application Security Project) is a nonprofit foundation dedicated to improving software security. OWASP produces articles, methodologies, documentation, tools and technologies in the field of web application security.

The OWASP Top Ten is a list of the 10 most common application vulnerabilities. It also shows their risks, impacts and countermeasures to stop and fix them. It is updated every three or four years, being the latest update to the list on September 2021.

The current Top 10 vulnerabilities are:

1. Broken Access Control
2. Cryptographic Failures
3. Injection
4. Insecure Design
5. Security Misconfiguration
6. Vulnerable and Outdated Components
7. Identification and Authentication Failures
8. Software and Data Integrity Failures
9. Security Logging & Monitoring Failures
10. Server-Side Request Forgery (SSRF)

What I have learnt today?

1 – Broken Access Control

Websites have pages that are protected from normal users. For example, only the admin should be able to manage other users. If a normal user has access to protected pages, the access controls are broken.

A normal user that has access to protected pages could view sensitive information from other users and even could have access to unauthorized functionality.

Broken access control allows attackers to bypass any authorisation, allowing them to have access to sensitive data or perform tasks that they shouldn’t have access to.

For example, a vulnerability was found in 2019 where a normal user could get any frame from a private Youtube video. Then, you could ask for several frames, reconstructing the video that was initially private.

As of now, one should be able to have access to that video, this was a broken access control vulnerability.

Insecure Direct Object Reference

An IDOR or Insecure Direct Object Reference is a vulnerability where you can access to resources you wouldn’t be able to know even exist.

For example, if your profile URL is http://www.website.com/profile?id=389, if you can change your id (389) for any other number and you can view their profile, that is an IDOR vulnerability.

![[day_033_idor_pre.png]]
![[day_033_idor_post.png]]

The application should validate that the requested account (or Object here) belongs to the logged-in user to avoid the IDOR.

2 – Cryptographic Failures

A cryptographic failure refers to any vulnerability arising from the misuse of cryptographic algorithms for protecting sensitive information. Web applications require cryptography to provide confidentiality for their uses at many levels.

For example:

• When we access our email account, the communications between us and the server are encrypted. When the network traffic is encrypted, we are talking about encrypting data in transit.
• As the emails are stored in some server, they should be also encrypted to avoid a hacker could read them. This is encrypting data at rest.

Cryptographic failures often end up in web applications leaking sensitive data, such as personal data from customers as names, financial information, etc to usernames and passwords.

There are techniques that can take advantage of this vulnerability such as “Man in the Middle” attacks, where a user is forced to use connections that are controlled by a hacker. Then, with weak encryption, the attacker could read all the data intercepted.

We can also take advantage of databases that are flat-file based. That is, the database is stored in just one file, for example, with a client such as sqlite3. We could download the file, open it in our terminal and view all the data.

3 – Injection

Injection flaws are still very common today. These flaws occur when the application doesn’t filter out user-controlled input as commands or parameters, letting the user ask for the information they shouldn’t have access to, or even deleting or editing a database. Common examples include:

• SQL Injection: This occurs when the input is passed to SQL queries, letting an attacker pass SQL queries that can manipulate the database by granting access, modifying or even deleting information.
• Command Injection: This works like SQL injection, but lets the user pass system commands. These commands are executed on the server, potentially allowing them to access the users’ systems.

We can prevent injection attacks by sanitising user-controlled inputs, so they are not interpreted as queries or commands:

• Using an allow list, any input is compared to a list of safe inputs. If the input is marked as safe, it is executed. If not, rejected.
• Stripping input, so dangerous characters that may lead to executing something, are removed before processing.

4 – Insecure Design

Insecure design are vulnerabilities that belong to the application’s architecture. It is not a technical error, but a logical one that makes the application flawed. For example, one developer adds a “shortcut” to make testing easier and disable password validation. After testing, they forgot to re-enable it and sends the application to production.

Insecure password resets

One good example of Insecure Design was the vulnerability that Instagram used to have. Instagram allowed users to reset their password by sending them a 6-digit code to their phone via SMS. An attacker could, instead, just brute-force their way in.

To solve this, they blocked any user after 250 attempts:

But this block only applied to the IP, not the computer. An attacker could use different IP addresses, using 250 attempts per IP. A 6-digit code needs 1 million tries. 1 million/250 attempts = 4.000 IPs to cover ALL possible codes, with an average of just 2.000.

While this may sound like a crazy amount, there are cloud services that for a small price, can give us this kind of service:

This is a vulnerability based on a poor design, not a flaw in the programming language or framework.

5 – Security Misconfiguration

Security misconfiguration

Security misconfiguration is a different vulnerability because they occur when security could have been configurated properly but it is not. This includes:

• Poorly configured permissions
• Having unnecessary features enabled
• Default accounts with default passwords
• Error messages that are too detailed
• Not using HTTP security headers

Sometimes, this vulnerability leads to more vulnerabilities, such as default credentials that grant you access to sensitive data, command injection, admin pages, etc.

Debugging interfaces

A common and classic security misconfiguration is exposing debugging features in production software. Debugging features are pretty helpful when developing by giving us a lot of information, but in production, this can give information to a would-be attacker. too much information. Leaving debugging features in production is like giving your GPS coordinates to a hacker, with a post-it with a “The key is under the pot :)” message.

Patreon got hacked in 2015 because of this. Patreon uses Python and had an open debug interface with a console, where you could run any code you send to it. Not your WordPress landpage to promote your cake business, but the bloody Patreon. Rooky mistake.

6 – Vulnerable and Outdated Components

Imagine that a company hasn’t updated their WordPress version for a few years and we, using a scanning tool (WPScan for example), find out they are using the 4.6 version which is pretty old.

With a quick research, we find out that WordPress 4.6 is vulnerable to unauthenticated remote code execution (RCE), as we saw on Exploit-DB. Even more: as the vulnerability is well known, somebody else has made an exploit for it.

Find a vulnerable version -> Search for an exploit in Exploit-Db -> Download it -> Run it.

With little work, this could be fixed (by just updating your website!).

7 – Identification and authentication failures

Authentication and session management are core components of modern web applications and go hand-to-hand. Authentication allows users to gain access to a web application after verifying their identities, usually with their username and password. After introducing them and, if the server verifies them, it creates a session cookie that is needed because web servers use HTTP/HTTPS to communicate: A protocol that is stateless. By attaching session cookies, the server knows who is sending what data.

By finding flaws in this process, an attacker may gain access to other users’ accounts, accessing sensitive data. Some common flaws are:

• Brute force attacks: An attacker can launch a brute-force attack that allows them to guess the username and password, using multiple and fast authentication attempts.
• Use of weak credentials: A web application should enforce strong password policies. By using weak passwords such as 1234 or password1, an attacker could guess them.
• Weak session cookies: Session cookies are how the server keeps track of its users. By containing predictable values, attackers can set their own session cookies, accessing users’ accounts.

We can mitigate these flaws:

• To avoid password-guessing attacks, ensure the application enforces a strong password policy.
• To avoid brute-force attacks, ensure that the application bans the user after a certain number of attempts.
• Implement Multi-Factor authentication. Instead of just using a username and a password, the user has to authenticate with their username and password, followed by entering a code sent to their phone or email, or a fingerprint.

8 – Software and data integrity failures

What is integrity?

When we are talking about integrity in cybersecurity, we are talking about the capacity to know that a piece of data is not modified. For example, you download an installer: How can you be sure that no one has modified it (in transit or otherwise)?

Enter the hash. Alongside or in the download website, there is a hash that can prove that the file you have just downloaded is an integer, so no one modified it. A hash is just a string that is created using a specific algorithm, from the data.

For example, on the website where you can download the WinSCP 5.21.5 installer, there is a list of hashes you can compare to:

The hashes, pre-calculated by the creators of WinSCP, can be used to verify the file’s integrity. After downloading the file, we can recalculate the hashes and compare them:

Check the last two images: The hash of the file downloaded corresponds to the hash in the download website. We can infer that the file is safe.

Software and data integrity failures

There are two types of vulnerabilities in this category:

• Software integrity failures.
• Data integrity failures.

Software integrity failures

It is common practice to use third-party libraries that are stored elsewhere. For example, let’s travel to 2014, pretend that jQuery is still relevant, and we want to use it on our website. We can include the file by linking it to their servers:

<script src="https://code.jquery.com/jquery-3.6.1.min.js"></script>

Any user that navigates to our website will download jQuery from the external source:

Nothing wrong with that. But what if an attacker somehow hacks and uploads a malicious version of the jQuery file?

Anyone visiting the website would now download the malicious code and execute it without realising it.

To avoid this, we can make that our website makes checks against the third-party library to see if it has changed by specifying a hash along the library link:

<script src="https://code.jquery.com/jquery-3.6.1.min.js" integrity="sha256-o88AwQnZB+VDvE9tvIXrMQaPlFFSUTR+nldQm1LuPXQ=" crossorigin="anonymous"></script>

We can generate our own hashes in SriHash.org.

Data integrity failures

When a user logs into an application, the server assigns and sends a session token that will be saved into the user’s browser, sending it with each request (HTTP/HTTPS protocols are stateless). These sessions normally come in form of cookies (key-value pairs).

![[day_033_cookie.png]]
If the cookies are poorly created (for example, the cookie contains the username or the user’s admin level admin=False), the user could tamper with the cookie, changing the username or even setting their admin value to true!

This application would suffer from data integrity failure, as the data can be tampered with.

One solution to this is to use some integrity mechanism to guarantee that the cookie hasn’t been altered. One common implementation is JSON Web Tokens (JWT).

JWT are very simple tokens that allow you to store key-value pairs (like cookies) on a token that provides integrity as part of the token:

![[day_033_jwt.png]]

• The header contains metadata indicating that this is a JWT and the signing algorithm.
• The payload contains the data that we want to store in our browser.
• The signature is a hash, used to verify the payload’s integrity. If the payload is manipulated, the signature won’t match the payload on the server’s side. This signature involves the use of a secret key or salt.

The user can manipulate the payload, but as the server gets the JWT, it will create its signature, using the secret key, generating a payload that will compare with the JWT signature. If anything is off, it won’t follow the request, as the signatures don’t match, involving foul play.

9 – Security logging and monitoring failures

When web applications are set up, every action should be logged as, in the event of an incident, we can trace the attacker’s actions. This way, we can ascertain the risk and impact of the attack. Without logging, we couldn’t tell what actions were performed.

The more significant impacts of these include:

• Regulatory damage: If an attacker has gained access to information from the users and there is no record of this, final users are affected and the application owners may be subject to fines or more severe actions, depending on their local regulations.
• Risk of further attacks: An attacker’s presence may be undetected without logging, allowing them to launch further attacks again.

The information stored in logs should include:

• HTTP status codes
• Time stamps
• Usernames
• API endpoints/page locations
• IP addresses

These logs are very important, and they should be stored securely and multiple copies should be stored in different locations.

Logging is more important after an incident has occurred. The ideal case is to monitor everything to detect any suspicious activity and stop the attacker or at least, reduce the impact they have made. Common examples of suspicious activity include:

• Multiple unauthorised attempts for a particular action (trying to log in in the admin pages).
• Requests from anomalous IP addresses or locations.
• Use of automated tools (We can identify this by the value of User-Agent headers or the speed of requests).
• Common payloads: It is common for attackers to use known payloads. Detecting them can indicate the presence of an attack in progress.

Detecting suspicious activity isn’t enough: They also need to be rated according to the impact level. The higher the higher-impact, the sooner we have to stop them.

10 – Server-Side Request Forgery (SSRF)

This type of vulnerability (already explained) occurs when an attacker can coerce a web application into sending requests on their behalf while having control of the contents of the request itself. SSRF vulnerabilities often arise from implementations where our web application needs to use third-party services.

For example, imagine a web application that uses an external API to send SMS notifications to its clients. For each SMS, the website needs to make a web request to the SMS provider to send the content of the message to be sent. The SMS provider charges for each message, so they require you to add a secret key pre-assigned to you, to each request made to their API. The API key serves as an authentication token that allows the provider to know whom to bill each message:

It is easy to see where the vulnerability is. The application exposes the server parameter to the users, which defines the server name of the SMS service provider. An attacker could simply change the value of the server to point to a machine they control, and the application would forward the SMS request to the attacker instead of the SMS provider.

The attacker would obtain then, the API key, allowing them to use the SMS service to send messages at the user’s expense.

This is just a basic case of SSRF, but it could be worse, as SSRF can also be used for:

• Enumerate internal networks, including IP addresses and ports.
• Abuse trust relationships between servers to gain access to otherwise restricted services.
• Interact with some non-HTTP services to get remote code execution (RCE).

Summary

Time for a recap. We have learned about:

• What OWASP is
• What are the OWASP top 10 vulnerabilities
• How to fix them

Stats

From 129.124th to 121.950th. Now I’m sitting in the top 6% in TryHackMe, yay!

Here is also the Skill Matrix:

Resources

Path: Web Fundamentals

Introduction to Web Hacking

TryHackMe: OWASP Top 10

Other resources

Top 10 OWASP vulnerabilities
Stealing Your Private YouTube Videos, One Frame at a Time
SQL Injection
Command Injection
How I Could Have Hacked Any Instagram Account
How Patreon got hacked – Publicly exposed Werkzeug Debugger
Exploit-DB
SriHash.org
JSON Web Token
Server-Side Request Forgery