Skip to main content
🧠Educationalintermediate5 min read

THM: OWASP Top 10 Box Review

A comprehensive review of TryHackMe's OWASP Top 10 room, covering each vulnerability category with practical examples.

TryHackMeOWASPweb securityCTFinjection
Share:𝕏in
🔗TryHackMe Series
Part 1 of 3

THM: OWASP Top 10 Box Review

The TryHackMe OWASP Top 10 room provides hands-on experience with each vulnerability category from the OWASP Top 10. This review covers key concepts and exploitation techniques.

Room Overview

The OWASP Top 10 represents the most critical security risks to web applications. This room walks through each category with practical exercises.

1. Injection

The Vulnerability

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most common example.

Example Attack

' OR 1=1--

Injected into a login form:

SELECT * FROM users WHERE username='' OR 1=1--' AND password='anything'

Hands-On Exercise

The room provides a login form vulnerable to SQL injection:

Username: ' or 1=1-- Password: anything

This bypasses authentication and logs in as the first user.

Defense

  • Parameterized queries
  • Input validation
  • Least privilege database accounts

2. Broken Authentication

The Vulnerability

Authentication flaws allow attackers to compromise passwords, session tokens, or exploit implementation flaws.

Common Issues

  • Weak passwords permitted
  • Credential stuffing possible
  • Session IDs in URLs
  • Sessions don't expire

Hands-On Exercise

The room demonstrates session fixation and weak password policies.

Defense

  • Multi-factor authentication
  • Strong password requirements
  • Secure session management

3. Sensitive Data Exposure

The Vulnerability

Sensitive data transmitted or stored without adequate protection.

Examples

  • Passwords in plain text
  • Unencrypted transmission
  • Weak cryptography
  • Data in client-side storage

Hands-On Exercise

Finding credentials in:

  • HTML comments
  • JavaScript files
  • Local storage
  • Network traffic

Defense

  • Encrypt data at rest and in transit
  • Don't store unnecessary sensitive data
  • Use strong cryptographic algorithms

4. XML External Entities (XXE)

The Vulnerability

Poorly configured XML parsers process external entity references in XML documents.

Example Payload

<?xml version="1.0"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

Hands-On Exercise

Exploiting an XML file upload to read system files.

Defense

  • Disable external entity processing
  • Use less complex data formats (JSON)
  • Input validation

5. Broken Access Control

The Vulnerability

Restrictions on what authenticated users can do are not properly enforced.

Examples

  • IDOR (Insecure Direct Object Reference)
  • Forced browsing
  • Missing function-level access control
  • Metadata manipulation

Hands-On Exercise

Accessing other users' data by manipulating:

/user/profile?id=1
/user/profile?id=2  # Another user's profile!

Defense

  • Deny by default
  • Implement access control once, reuse everywhere
  • Log access control failures

6. Security Misconfiguration

The Vulnerability

Missing or incorrect security settings throughout the application stack.

Examples

  • Default credentials
  • Unnecessary features enabled
  • Verbose error messages
  • Missing security headers
  • Outdated software

Hands-On Exercise

Finding exposed admin panels and default credentials.

Defense

  • Hardening guides
  • Minimal installation
  • Regular audits
  • Automated verification

7. Cross-Site Scripting (XSS)

The Vulnerability

Application includes untrusted data without proper validation or escaping.

Types

  • Stored XSS: Persisted in database
  • Reflected XSS: Reflected from request
  • DOM-based XSS: Client-side execution

Example Payload

<script>alert('XSS')</script>

Hands-On Exercise

Injecting JavaScript through input fields:

<img src=x onerror="alert('XSS')">

Defense

  • Output encoding
  • Content Security Policy
  • Input validation

8. Insecure Deserialization

The Vulnerability

Applications deserialize hostile data, leading to code execution, injection, or privilege escalation.

Concept

When applications serialize data (convert to a format for storage/transmission), the reverse process (deserialization) can be exploited.

Languages Affected

  • PHP
  • Java
  • Python
  • .NET

Defense

  • Don't accept serialized objects from untrusted sources
  • Integrity checks
  • Type constraints

9. Using Components with Known Vulnerabilities

The Vulnerability

Using libraries, frameworks, or software with known security flaws.

Examples

  • Outdated WordPress plugins
  • Vulnerable JavaScript libraries
  • Unpatched servers

Hands-On Exercise

Identifying vulnerable software versions and finding exploits.

Tools

  • retire.js
  • OWASP Dependency-Check
  • Snyk
  • npm audit

Defense

  • Inventory components
  • Monitor for vulnerabilities
  • Patch management process

10. Insufficient Logging & Monitoring

The Vulnerability

Insufficient logging, detection, monitoring, and response allows attacks to persist.

Problems

  • Auditable events not logged
  • Logs not monitored
  • No alerting thresholds
  • Logs stored only locally

Impact

Most successful attacks start with vulnerability probing. Without monitoring, these attempts go unnoticed.

Defense

  • Log authentication, access control, input validation failures
  • Centralized log management
  • Alerting and response procedures
  • Regular log review

OWASP Top 10 2021 Updates

The 2021 version includes some changes:

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

Key Takeaways

For Testers

  • The OWASP Top 10 is a starting point, not a comprehensive list
  • Understand the vulnerability, not just the exploit
  • Context matters for severity

For Developers

  • Security should be built in, not bolted on
  • Use security frameworks and libraries
  • Follow secure coding guidelines

For Organizations

  • Regular security testing
  • Developer security training
  • Security in the SDLC

Resources


Want to learn web application security? Contact us: m1k3@msquarellc.net

Found this helpful? Share it:

Share:𝕏in

Need Help With This?

Have questions about implementing these security practices? Let's discuss your specific needs.

Get in Touch

More in Educational

Explore more articles in this category.

Browse 🧠 Educational

Related Articles