Skip to content

Web App PenTest Checks Cheatsheet

1. Injection (A1)

What is it?

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.

How to test for Injection:
  • SQL Injection: Test form inputs and URLs with SQL syntax like ' OR 1=1 --, '; DROP TABLE users; --. Watch for database errors or unexpected behavior.
  • Command Injection: Try submitting OS commands in form fields, such as ; ls, | cat /etc/passwd.
  • LDAP Injection: Test for LDAP query manipulation, e.g., *))(&(|(user=admin)).
Mitigation
  • Use parameterized queries or prepared statements.
  • Validate and sanitize inputs.

Example: HHC2024 Drone Path where the website was vulnerable to a SQL injection and thus responded with more information than it should have.

2. Broken Authentication (A2)

What is it?

Broken authentication occurs when application authentication mechanisms are incorrectly implemented, allowing attackers to compromise user accounts or session tokens.

How to test for Broken Authentication:
  • Session Management: Test for weak session handling like predictable session IDs or lack of session expiration.
  • Brute Force: Try password spraying, credential stuffing, or dictionary attacks to test account lockout or rate-limiting.
  • Password Strength: Test if weak passwords like "12345" are allowed.
Mitigation
  • Implement multi-factor authentication (MFA).
  • Secure session management (e.g., use secure cookies, same-site cookie attributes).
  • Enforce strong password policies.

Example: HHC2023 Elf Hunt where the cookie storing the json web token could be modified to change the game parameters.

3. Sensitive Data Exposure (A3)

What is it?

Sensitive data exposure occurs when sensitive data (e.g., passwords, credit card numbers) is not properly protected, leading to leakage.

How to test for Sensitive Data Exposure:
  • Weak Encryption: Look for HTTPS being used instead of HTTP (check for SSL/TLS).
  • Storage of Sensitive Data: Check if sensitive data is stored in plain text or poorly protected (e.g., passwords not hashed or salted).
  • Weak Encryption Algorithms: Test for weak or outdated encryption algorithms like MD5 or SHA1.
Mitigation
  • Use strong encryption (AES-256, RSA).
  • Always use HTTPS for data in transit.
  • Hash passwords using bcrypt, PBKDF2, or Argon2.

Example: HHC2024 Santa Vision where the code had some credentials that were in the comments.

4. XML External Entities (XXE) (A4)

What is it?

XXE vulnerabilities occur when XML input containing a reference to an external entity is processed by an XML parser.

How to test for XXE:
  • Inject External Entities: Test by injecting <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> or similar payloads into XML data.
  • Check Error Responses: Look for file contents or unexpected errors revealing internal files.
Mitigation
  • Disable external entity processing in XML parsers.
  • Use JSON instead of XML where possible.

5. Broken Access Control (A5)

What is it?

Broken access control occurs when users can access resources or perform actions they should not be able to.

How to test for Broken Access Control:
  • URL Manipulation: Change the user ID or resource ID in the URL (e.g., /user/123 to /user/999).
  • Method Tampering: Test for access to unauthorized HTTP methods (e.g., PUT, DELETE).
  • Direct Object References: Try accessing resources that shouldn’t be accessible (e.g., /admin, /user/settings).
Mitigation
  • Implement role-based access control (RBAC).
  • Use access control lists (ACLs).
  • Always validate access control on the server-side.

Example: When the robots.txt file points right to pages that are accessible, but shouldn't be.

6. Security Misconfiguration (A6)

What is it?

Security misconfigurations occur when security settings are not properly configured, leaving the application vulnerable.

How to test for Security Misconfiguration:
  • Default Configurations: Check for default usernames and passwords (e.g., admin:admin).
  • Unnecessary Services: Test for exposed ports or unused services that shouldn’t be accessible.
  • HTTP Headers: Check for missing security headers like X-Content-Type-Options, Strict-Transport-Security.
Mitigation
  • Disable unnecessary services.
  • Harden server configurations and follow the principle of least privilege.
  • Use automated tools for regular security scans.

7. Cross-Site Scripting (XSS) (A7)

What is it?

XSS allows attackers to inject malicious scripts into pages viewed by other users.

How to test for XSS:
  • Reflected XSS: Test by injecting <script>alert('XSS');</script> into form fields, URL parameters, or headers.
  • Stored XSS: Inject XSS payload into forms and check if they persist (e.g., in comments, user profiles).
  • DOM-based XSS: Check if the page modifies the DOM based on untrusted inputs without sanitization.
Mitigation
  • Sanitize and escape user input before rendering it.
  • Use Content Security Policy (CSP).
  • Avoid inline JavaScript.

8. Insecure Deserialization (A8)

What is it?

Insecure deserialization occurs when untrusted data is deserialized, allowing attackers to execute arbitrary code or escalate privileges.

How to test for Insecure Deserialization:
  • Tampering with Serialized Objects: Modify serialized data (e.g., JSON or XML) and try to deserialize it to see if the application executes unintended code.
  • Check for Vulnerable Libraries: Use tools to check if common deserialization libraries (e.g., Java serialization) are in use.
Mitigation
  • Avoid deserialization of untrusted data.
  • Implement integrity checks (e.g., hashes) on serialized data.

9. Using Components with Known Vulnerabilities (A9)

What is it?

This occurs when an application uses libraries, frameworks, or components that have known security vulnerabilities.

How to test for Known Vulnerabilities:
  • Check for Outdated Components: Use tools like OWASP Dependency-Check to identify known vulnerable libraries.
  • Review Components: Manually check for known vulnerabilities in components (e.g., Java, Python packages).
Mitigation
  • Keep components up to date.
  • Use dependency scanning tools to check for known vulnerabilities.

10. Insufficient Logging & Monitoring (A10)

What is it?

Lack of logging and monitoring means that attacks may not be detected or responded to in time.

How to test for Insufficient Logging:
  • Test Logs for Sensitive Data: Check if logs are missing critical information such as user actions, failed login attempts, or system errors.
  • Attempt an Attack: Try simple attacks like login brute-forcing and see if they are logged.
Mitigation
  • Implement logging of all security-relevant events (e.g., logins, failed logins, privileged actions).
  • Regularly monitor logs and use a centralized logging system like ELK Stack or SIEM.