4. OWASP Top 10 Exploits
Fourth section in the Complete Beginner learning path.
Introduction
The top ten being exploited & investigated here are:
Broken Access Control
Cryptographic Failure
Injection
Insecure Design
Security Misconfiguration
Vulnerable and Outdated Components
Identification and Authentication Failures
Software and Data Integrity Failures
Security Logging & Monitoring Failures
Server-Side Request Forgery (SSRF)
1. Broken Access Control
Websites have pages protected from regular visitors, for example, only the sites admin user should be able to access a page to manage other users. If a website visitor can access pages they are not supposed to, then access control is broken.
If a regular visitor can access protected pages it can lead to them viewing sensitive information from other users or accessing unauthorised functionality. An example of this is a vulnerability from 2019 where an attacker could retrieve frames from YouTube videos marked as private.
Insecure Direct Object Reference (IDOR) is an access control vulnerability where you can access resources you wouldn't normally be able to see. For example, if you were logging into a bank account and receive the URL "https://bank.thm/account?id=111111" you can try to change the "?id=111111" to another, you could assume "?id=222222" is another users account, if incorrectly configured, this would allow you access.
2. Cryptographic Failure
A cryptographic failure is a vulnerability that arises for misuse (or lack of use) of cryptographic algorithms for protecting sensitive information. For example, in a secure email application you want to make sure that when you are accessing your email account in browser that your emails are encrypted. This way, any eavesdroppers won't be able to recover data from captured packets. This is known as encrypting data in transit. It is also desirable to ensure the email provider cannot read your emails when stored, this is referred to as encrypting at rest.
These often result in web apps accidentally divulging sensitive data, this data is often directly linked to customers like names and DoBs, but could contain more sensitive info like passwords.
3. Injection
Injection flaws are common in modern applications, these occur because the app interprets user-controlled inputs as commands or parameters. Some common examples are:
SQL Injection: user-controlled input is passed to SQL queries, potentially allowing an attacker to access, modify or delete database information or steal personal details/credentials.
Command Injection: user-controlled input is passed to system commands, allowing attackers to execute arbitrary system commands.
The main defence for preventing injection attacks is ensuring user-controlled input is not interpreted as queries or commands. An allow list can be used to compare user input against a list of safe inputs or characters or input can be stripped of dangerous characters. Dangerous characters are any characters that can change the way underlying data is processed.
4. Insecure Design
Insecure design refers to vulnerabilities inherent to an apps architecture. This means that the idea behind part of (or an entire) application was inherently flawed.
A good example of insecure design is a flaw with Instagram, which allowed users to reset their passwords by sending them a six-digit SMS code for validation. Attackers could try to brute-force this code, however, this was rate limited after about 250 attempts. It was discovered that the rate-limiting only applied to attempts made from the same IP, therefore, if an attacker had many different IPs, they could try 250 codes per IP. A max of 4000 IPs would be required to fully try this, which is feasible with cloud service providers.
5. Security Misconfiguration
These occur when security could be configured appropriately, but was not. Security misconfigurations include:
Poorly configured permissions on cloud services
Unnecessary features being left enabled
Default accounts and default passwords
Overly detailed error messages
Not using HTTP security headers (more detail at Secure Headers Project)
A common misconfiguration involves exposure of debug interfaces on production software. Debug features are often available to programmers to access advanced functionality when it is in development. These can be abused if developers forget to disable them when publishing applications. An example of this is the Werkzeug console, accessible via the /console URL which allows the user access to a Python console.
6. Vulnerable and Outdated Components
Occurs when a program or service with a well known vulnerability is being used. For example, if a company has not updated their WordPress for many years, you could find its version using WPScan and use some quick research to find ready-made exploits.
7. Identification and Authentication Failures
Authentication and session management are core in modern web apps. Authentication allows users to verify their identities. Servers will provide session cookies to authenticated users to allow users' actions be tracked by the browser (HTTPS communication is stateless).
Flaws in authentication mechanisms can be exploited in many ways:
Brute force : can be used against usernames/passwords where no lockout or rate limiting is enforced.
Use of weak credentials : web apps should have strong password policies, users may otherwise set easily guessable passwords (like "Password").
Weak session cookies: session cookies that contain predictable values can be manipulated by attackers to access users' accounts.
8. Software and Data Integrity Failures
Integrity is being able to ascertain that a piece of data is unmodified. Integrity is essential to make sure data is free from malicious or unwanted modifications. Often, a hash will be sent alongside a file to verify its integrity. A hash (sometimes referred to as a digest) is a number that results from applying an algorithm over a piece of data. There are two types of vulnerability here: software and data.
An example of software integrity failure is a website using libraries stored in external servers out of their control. If these libraries do not have a hash specified, it is possible that the original code could be modified, meaning users of your site would be unknowingly injecting malicious code into their browsers.
An example of data integrity failure would be a website storing a username in a cookie, allowing an attacker to modify this and impersonate another user. A solution to this is to use a data integrity mechanism like JSON Web Tokens (JWT). These allow key pairs to be stored on a token. If the payload is changed then the web server can verify this and know that the JWT has been tampered with.
9. Security Logging and Monitoring Failures
Every action taken by a user on a web app should be logged, this allows incidents to be traced back to their source. Once an incident has been traced, its risk and impact can be determined. Without logging there is a risk of both regulatory damage and further attacks being carried out. Log info should contain:
HTTP Status Codes
Time Stamps
Usernames
API Endpoints/Page Locations
IP Addresses
It is also important to store logs securely and keep multiple copies. Logging can help detect lots of common malicious activity like repeated unauthorised login attempts, anomalous IP requests, automated tool usage or common payloads.
10. Server-Side Request Forgery (SSRF)
This allows attackers to coerce a web app into sending requests on their behalf while being in control of the request contents. These vulnerabilities often appear when web apps need to use third-party services.
Last updated