Final Chapters

1. race condition

1.1. definition: vulnerability related to code logic flow. occurs when an application process multiple requests at the same time. causes collision and result in unintentional bahaviour.

1.2. Impact: cause unintentional behaviour that can be malicious to bypass code logic of the application.

1.3. tools to inspect: burp suite script with multiple requests

1.4. how it happens: Example: A website offers a one-time redeem code. An attacker submits multiple requests at the same time, allowing the code to be used twice due to timing issues. money transfer- bypass anti-brute force rate limit - email based operations. time period to have a successful race condition exploit is called race window.

1.5. Types: Single-End Point: Exploit happens on a single service (e.g., multiple requests to claim a redeem code). Multi-End Point: Exploits different services (e.g., simultaneous login and signup). Time-Sensitive: Exploits timestamp-based mechanisms (e.g., password resets).

1.6. mitigation: Avoid mixing data from different storage places. (1 db is enough) Use database concurrency features. Ensure database integrity and consistency. Avoid using one data storage layer to secure another.

2. file upload vulnerabilities

2.1. Definition: Vulnerabilities affecting the file upload process, potentially leading to various attacks.

2.2. Impact: No Size Validation: Denial of Service (DoS). No Type Validation: malicious code execution. No Name Validation: Overwriting existing files. Path Choice: Directory traversal attack. Web Shell Example: PHP script executing commands via HTTP GET.

2.3. Detection Tools: Static analysis (code review). Dynamic analysis (fuzzing).

2.4. How They Work: Attacker uploads a malicious file. Attacker executes the file via HTTP GET or POST request.

2.5. Examples: Bypassing content type validation. Bypassing MAX_FILE size validation. Bypassing mime validation.

2.6. Mitigation: Proper validation of file type, size, name, and location. Validate files before saving them in the server. Use frameworks for validation. Blacklisting dangerous file types.

3. file path/directory traversal

3.1. Definition: Vulnerability allowing attackers to access files beyond what the system was designed for.

3.2. Impact: Accessing source code, secret keys, and sensitive data.

3.3. Detection Tools: Static analysis. URL fuzzing (e.g., DirBuster).

3.4. How It Works: Attacker inspects HTML or GET request parameters. Uses file paths to access unauthorized files.

3.5. Examples: Accessing sensitive files via HTTP requests. Incorrect validation allowing access to files.

3.6. Mitigation: Proper validation of user input. Access control checks. File name validation. Whitelisting readable files. Checking canonicalized absolute paths.

4. cryptography & threat model

4.1. Cryptography Terminology:

4.1.1. Encoding/decoding changing the representation to another (reversible + no key) provide confidentiality work with binary data - integrity

4.1.2. encryption/decryption encrypt and decrypt data using a single key or different keys.

4.1.3. Where to perform encryption? application level: PHP app DB level: MySql, MariaDB Filesystem level: BitLocker HW level: encrypted RAID, SSDs

4.1.4. digital signature 2 keys, data signed with private key. verified with public key provide integrity

4.1.5. hashing one way function. ensure integrity

4.1.6. hmac hash with key. ensure integrity

4.2. Security Properties:

4.2.1. confidentiality data is protected from being read

4.2.2. integrity data not tampered

4.2.3. authentication data accessed by authenticated user.

4.2.4. authorization data accessed by users with authorized permission.

4.3. System Design and Threat Model: Threat modeling involves analyzing a system from an attacker’s perspective. 1.modelling 2.find 3.response

4.3.1. Threat Model (STRIDE): Spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privileges.

4.4. Where to perform encryption? application level: PHP, mobile app DB level: MySql, MariaDB Filesystem level: BitLocker HW level: encrypted RAID, SSDs

4.5. Recommended Algorithms: -Symmetric: AES (key size at least 128 bits, preferably 256 bits). -Asymmetric: ECC with Curve25519 or RSA (key size 2048 bits). Cipher Modes: -Use authenticated modes like GCM or CCM for integrity, authenticity, and confidentiality. -If not available, use CTR or CBC, and add MAC for authenticity. Padding: Use schemes like PKCS#1 for RSA to prevent plaintext attacks by adding randomness.

4.6. Secure Random Number Generation Types: 1.Pseudo-Random Number Generators (PRNGs): Fast but not suitable for security-critical tasks. Example: PHP rand(). 2.Cryptographically Secure PRNGs (CSPRNGs): High-quality randomness, safe for sensitive tasks like key generation. Examples: PHP random_int(), openssl_random_bytes(). Use Cases: Generating encryption keys, session IDs, CSRF tokens, or password reset tokens.

4.7. Key Management Processes: Generate, store, rotate, and decommission keys securely. Keys should be independent for different tasks. Key Storage: Store keys securely using: Hardware Security Modules (HSMs). Cloud key vaults (e.g., AWS KMS). APIs like ProtectedData in .NET. Avoid storing keys in source code, environment variables, or with encrypted data.

4.8. Key Rotation Triggers for Rotation: Suspected compromise. End of cryptoperiod. Large data volumes encrypted with the key. Handling Old Data: Re-encrypt with a new key or store multiple keys with unique IDs.

4.9. Encrypting Stored Keys Process: Use a Key Encryption Key (KEK) to encrypt the Data Encryption Key (DEK). Store KEK separately from DEK. Example: Derive KEK from a user-supplied password using a Key Derivation Function (KDF). Encrypt DEK with KEK to secure database records.

5. authentication & authorization

5.1. Authentication: Process of verifying user identity. Authorization: Process of granting permissions to users.

5.2. Authentication Factors: Knowledge (passwords), possession (tokens), inherence (biometrics).

5.3. Vulnerabilities: Brute force attacks, session stealing, information leakage.

5.4. Two-Factor Authentication (2FA): Uses two methods to verify identity, such as password and OTP. Poor implementation may allow bypassing the second factor. Tokens with low entropy (e.g., short numeric codes) are easier to guess.

5.5. Mitigation Strategies: Enforcing secure connections, strong password policies, generic error messages, CAPTCHA.

5.6. Authenticator Apps: Generate OTPs using shared secret keys (HOTP and TOTP). HOTP (Counter-Based): OTP changes when a counter is incremented. TOTP (Time-Based): OTP changes based on a time interval (e.g., every 30 seconds).

6. network security

6.1. Transport Layer Security (TLS): Protocol for securing client-server communication. Provides confidentiality, integrity, and authentication.

6.2. TLS Configuration: Only support strong protocols and ciphers. Disable compression to prevent CRIME attacks. Patch cryptographic libraries. Test server configuration using tools like SSL Labs.

6.3. TLS Protocol and Cipher Suites Cipher Suite Example: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDHE: Key exchange. RSA: Public key cryptography. AES: Symmetric encryption. GCM: Galois Counter Mode (for integrity and confidentiality). SHA256: Hashing algorithm.

6.4. TLS Versions SSL 2 & 3: Weak and deprecated. TLS 1.0 & 1.1: Outdated. TLS 1.2: Secure and widely supported. TLS 1.3: Modern, highly secure. TLS Server Configuration Support Strong Protocols: Prefer TLS 1.3 and TLS 1.2; disable older versions. Strong Ciphers: Disable weak ciphers (e.g., NULL, EXPORT). Disable Compression: Prevent CRIME attacks. Patch Cryptographic Libraries: Regular updates to avoid vulnerabilities like Heartbleed. Test Server Configuration: Use tools like SSL Labs.

6.5. Certificates: Use strong keys (2048-bit minimum for RSA), and cryptographic algorithms (SHA-256 for hashing). Correct domain names, avoid wildcard certificates, use trusted CAs.

6.6. TLS Best Practices for Applications Use TLS for all pages. Avoid mixed TLS and non-TLS content. Set the "Secure" flag for cookies. Prevent caching of sensitive data. Enable HTTP Strict Transport Security (HSTS).

6.7. HTTPS Inspection: Man-in-the-middle technique used by firewalls to inspect encrypted traffic. Benefits and drawbacks.

6.8. Public Key Pinning: Ensures the server's certificate matches the expected certificate.