Example Web Application Security Assessment

Note: This is a demonstration write-up using a fictional, intentionally vulnerable practice application. No real system, company, or individual is represented. It exists to show the format used for real lab and CTF write-ups on this site.

Overview

This engagement targeted a fictional demo application, "DemoShop", running in a local lab environment. The goal was to practice a structured web application assessment: reconnaissance, enumeration, vulnerability discovery, controlled exploitation, and reporting.

Scope

• Target: demoshop.lab (local lab VM, private network only)
• Type: Black-box web application assessment
• Out of scope: Underlying host OS, any real third-party service

Reconnaissance

Started with basic reconnaissance to understand the application's attack surface.

nmap -sV -p- demoshop.lab

This identified an HTTP service and a login portal. Manually browsing the site revealed a product catalog, a login page, and a user account area.

Enumeration

Used Burp Suite to intercept and review requests while browsing the application as a normal user.

GET /api/orders/1042 HTTP/1.1
Host: demoshop.lab
Cookie: session=demo-session-token

The order lookup endpoint accepted a numeric ID directly from the URL, which stood out as worth testing further.

Vulnerability Discovery

Incrementing the order ID in the request above returned order data belonging to a different (fictional) account, without any additional authorization check. This is a classic Insecure Direct Object Reference (IDOR).

Exploitation

Using Burp Suite's Repeater, the order ID was changed to sequential values to confirm the behavior was consistent and not a one-off:

GET /api/orders/1041 HTTP/1.1
GET /api/orders/1043 HTTP/1.1

Both requests returned order details for accounts other than the logged-in demo user, confirming the access control gap.

Impact

In a real deployment, this class of vulnerability could allow any authenticated user to read (and potentially modify) other users' order data simply by changing an ID in the request — no credential theft required.

Remediation

• Enforce server-side authorization checks on every object access, not just authentication
• Prefer non-sequential, non-guessable identifiers (e.g., UUIDs) for sensitive resources
• Add logging/alerting for abnormal sequential access patterns

Lessons Learned

• Authorization bugs are often simpler than they sound — always test "can I access someone else's data," not just "can I log in"
• An intercepting proxy makes this class of testing fast and repeatable
• Documenting requests and responses as you go makes writing the report afterward much easier