# **OWASP Top 10 - 2021**

1. Broken Access Control

- **Definition**

- Failure in access controls allowing unauthorized access

- **Consequences**

- View sensitive information

- Access unauthorized functionality

- **Example Case**

- 2019 vulnerability in YouTube

- Attacker accessed private video frames

- Reconstructed the video despite privacy settings

- **Key Takeaway**

- Broken access control compromises data security and user trust.

### Insecure Direct Object Reference (IDOR)

- **Definition**

- Access control vulnerability allowing unauthorized resource access

- **Mechanism**

- Exposure of Direct Object References (e.g., user IDs, account numbers)

- **Example Scenario**

- User accesses own bank details

-

- **Vulnerability**

- Changing ID parameter (e.g., `id=222222`)

- Accessing other users' bank information

-

- **Key Insight**

- Problem lies in lack of validation on ownership of the referenced object.

### Cryptographic Failures

- **Definition**

- Vulnerabilities from misuse or lack of cryptographic algorithms

- **Importance of Cryptography**

- Provides confidentiality at multiple levels in web applications

- **Data Protection**

- **Data in Transit**

- Encryption of communications between client and server

- Prevents eavesdropping on network traffic

- **Data at Rest**

- Encryption of stored emails to prevent unauthorized access by providers

- **Consequences of Failures**

- Accidental disclosure of sensitive data

- Personal data (names, dates of birth, financial info)

- Technical data (usernames, passwords)

Subtopic

- **Attack Techniques**

- **Man-in-the-Middle Attacks**

- Intercepting data through compromised connections

- Exploiting weak encryption or lack of encryption

- **Common Vulnerabilities**

- Simpler vulnerabilities that can be exploited without advanced knowledge

- Sensitive data sometimes found directly on web servers

### Flat-File Databases

1. **Definition**

- **Flat-file databases** are simple databases stored as a single file on a computer. Unlike traditional databases that run on servers (like MySQL), they don’t require complex setups.

2. **Common Use**

- Often used in **small web applications** where simplicity is key. They allow for quick data storage and retrieval without needing a full database server.

3. **Vulnerability: Sensitive Data Exposure**

- If a flat-file database is stored in a publicly accessible location (like the root directory of a website), unauthorized users can download it. This poses a serious risk because the database may contain sensitive information (e.g., user names, passwords, credit card details).

### SQLite Example

1. **SQLite Database**

- SQLite is a popular format for flat-file databases. It’s lightweight and can be accessed through various programming languages.

2. **Interacting with SQLite**

- To interact with an SQLite database:

- Use the command `sqlite3 <database-name>` to open the database.

- Use commands like:

- `.tables` to see the available tables.

- `PRAGMA table_info(table_name);` to understand the structure (columns) of a table.

- `SELECT * FROM table_name;` to view all data in a table.

3. **Sample Commands**

- If you have a file named `example.db`, you would:

- Run `sqlite3 example.db` to open it.

- Run `.tables` to check for tables (e.g., `customers`).

- Run `PRAGMA table_info(customers);` to see the columns, which might include:

- custID (customer ID)

- custName (customer name)

- creditCard (credit card number)

- password (hashed password)

4. **Example Data**

- The output might show data like:

- `0|Joy Paulson|4916 9012 2231 7905|5f4dcc3b5aa765d61d8327deb882cf99`

- This represents a customer’s ID, name, credit card number, and a hashed version of their password.

### Cracking Password Hashes

- **Objective**

- Recover plaintext passwords from hashes

- **Hash Type**

- Weak MD5 hashes

- **Tool Used**

- **Crackstation**

- Online password cracking tool

- Utilizes a massive wordlist

- **Process**

1. Navigate to Crackstation

2. Paste the hash (e.g., `5f4dcc3b5aa765d61d8327deb882cf99`)

3. Solve Captcha

4. Click "Crack Hashes"

- Successfully recover password (e.g., "password")

- **Limitations**

- Passwords not in the wordlist cannot be cracked

### Injection

- **Definition**

- Flaws where user input is interpreted as commands or parameters

- **Common Types**

- **SQL Injection**

- User input affects SQL queries

- Potential to access, modify, or delete database information

- Risk of stealing sensitive data

- **Command Injection**

- User input passed to system commands

- Allows execution of arbitrary commands on servers

- **Main Defense Strategies**

- **Allow List**

- Compare input against a list of safe inputs

- Reject unsafe inputs with an error

- **Stripping Input**

- Remove dangerous characters from user input

- **Libraries and Tools**

- Utilize libraries that automate input validation and sanitization

### Command Injection

- **Definition**

- A vulnerability allowing attackers to execute arbitrary OS commands on a server via user input.

- **How It Works**

- Server-side code (e.g., PHP) calls console functions directly.

- Attackers manipulate these calls to run unauthorized commands.

- **Example Scenario**

- MooCorp’s web app uses the `cowsay` command for ASCII art.

- Code snippet is vulnerable to command injection:

```php

<?php

if (isset($_GET["mooing"])) {

$mooing = $_GET["mooing"];

$cow = 'default';

if(isset($_GET["cow"]))

$cow = $_GET["cow"];

passthru("perl /usr/bin/cowsay -f $cow $mooing");

}

?>

```

- **Vulnerability Details**

- User input directly used in command execution (`$cow` and `$mooing`).

- Allows injection of additional commands.

- **Exploiting the Vulnerability**

- Use bash inline commands: `$(your_command_here)`.

- Example payloads:

- `$(whoami)`

- `$(id)`

- `$(ifconfig)`

- `$(uname -a)`

- `$(ps -ef)`

- **Consequences**

- Attackers gain control over the server, allowing file listing, system reconnaissance, and more.

Main topic

### Insecure Design

1. **Definition**

- Insecure design refers to vulnerabilities that arise from the fundamental architecture or concept of an application. Unlike implementation flaws (like coding errors), these vulnerabilities are rooted in poor planning or flawed ideas during the design phase.

### Example: Insecure Password Resets

2. **Causes**

- **Improper Threat Modeling:** Failing to adequately assess potential threats and risks during the planning stages can lead to insecure design.

- **Developer Shortcuts:** Sometimes, developers might disable security features (e.g., one-time passwords) to simplify testing. If these shortcuts are not re-enabled in production, it creates vulnerabilities.

1. **Instagram Case Study**

- **Password Reset Mechanism:** Users can reset forgotten passwords by entering a 6-digit code sent via SMS.

- **Rate Limiting:** To prevent brute-forcing (guessing the code), Instagram implemented a rate limit—blocking further attempts after 250 failed tries from a single IP address.

2. **Vulnerability Exploitation**

- **Brute-Forcing Process:**

- Attackers can try different 6-digit codes (1,000,000 possible combinations).

- Rate limiting applies per IP address. An attacker could use multiple IP addresses to bypass the limit.

- With 4000 IPs, an attacker could theoretically test all codes, making the attack feasible using cloud services.

### Prevention Strategies

1. **Threat Modeling:**

- Conduct thorough threat assessments during the design phase to identify potential vulnerabilities early.

1. **Implementing SSDLC:**

- A Secure Software Development Lifecycle (SSDLC) integrates security at each phase of development, ensuring that vulnerabilities are considered throughout the process.

- **Difficulty of Fixing Insecure Design:**

- Addressing insecure design often requires a substantial redesign of the application, which can be complex and time-consuming compared to fixing a simple coding error.

Subtopic

### Security Misconfiguration

- **Definition**

- Vulnerabilities from improper security configurations, even in updated software.

- **Common Examples**

- Poorly configured cloud permissions (e.g., S3 buckets).

- Enabled unnecessary features.

- Default accounts with unchanged passwords.

- Detailed error messages exposing system info.

- Missing HTTP security headers.

- **Consequences**

- Can lead to further vulnerabilities, like unauthorized access and command injection.

### Debugging Interfaces

- **Risk**

- Exposed debugging features can be exploited by attackers.

- **Example: Patreon Hack (2015)**

- Open debug interface allowed arbitrary code execution.

### Prevention

- Use configuration management tools.

- Conduct regular audits.

- Disable debugging features in production.

### Vulnerable and Outdated Components

- **Definition**

- Use of software with well-known vulnerabilities due to lack of updates.

- **Example Scenario**

- A company uses an outdated version of WordPress (e.g., 4.6).

- This version is known to have an unauthenticated remote code execution (RCE) vulnerability.

- **Consequences**

- Attackers can exploit these vulnerabilities easily using existing exploits (e.g., from Exploit-DB).

- A single missed update can expose the system to multiple vulnerabilities.

### Prevention Strategies

- Regularly update all software components.

- Implement automated update mechanisms.

- Monitor for known vulnerabilities in used software.

Identification and Authentication Failures

- **Authentication**

- **Definition**: Process of verifying user identities.

- **Common Methods**:

- Username and Password

- Biometric (e.g., fingerprint, facial recognition)

- OAuth (third-party login)

- **Session Management**

Subtopic

- **Definition**: Mechanism for tracking user sessions.

- **Session Cookies**:

- Created upon successful authentication.

- Stored in the user's browser.

- Used to maintain state in stateless HTTP communication.

### 2. **Common Vulnerabilities**

- **Brute Force Attacks**

- **Description**: Automated attempts to guess passwords.

- **Tools Used**: Password cracking tools (e.g., Hydra, Burp Suite).

- **Weak Session Cookies**

- **Description**: Cookies with predictable values.

- **Consequences**: Attackers can forge session cookies.

- **Example**: Using simple sequences or predictable IDs.

- **Weak Credentials**

- **Description**: Users often choose weak passwords.

- **Examples**: "123456", "password", "qwerty".

- **Impact**: Easy for attackers to gain access.

### 3. **Potential Risks**

- **Unauthorized Account Access**

- Attackers can impersonate legitimate users.

- **Data Breaches**

- Exposure of sensitive information.

- **Identity Theft**

- Misuse of stolen credentials for malicious purposes.

### 4. **Mitigation Strategies**

- **Enforce Strong Password Policies**

- **Requirements**:

- Minimum length (e.g., 8-12 characters).

- Inclusion of uppercase, lowercase, numbers, and symbols.

- **Use Multi-Factor Authentication (MFA)**

- **Methods**:

- Something you know (password).

- Something you have (smartphone, hardware token).

- Something you are (biometric verification).

- **Secure Session Cookies**

- **Best Practices**:

- Use Secure and HttpOnly flags.

- Set short expiration times for session cookies.

- Regenerate session IDs upon login and logout.

- **Implement Account Lockout Mechanisms**

- **Approach**:

- Lock account after 3-5 failed login attempts.

- Notify users of lockout events.

Floating topic

Subtopic

r

em