Security Lab Notes · OWASP WebGoat

Web Application Security Lab

A controlled OWASP WebGoat exercise completed in an isolated training environment. The lab focused on how common web application weaknesses can expose sensitive data, undermine authentication, and allow unauthorized page changes when secure development practices are missing.

View Pentesting Lab Back to Projects

Overview

What I worked through

This lab used OWASP WebGoat, a deliberately vulnerable learning application, to examine several web-security failure modes from both attacker and defender perspectives. I used Burp Suite to inspect requests and responses, trace application behavior, and validate how server-side weaknesses can become user-facing security problems.

The work included identifying exposed application logic, analyzing weak trust boundaries in requests, demonstrating an SQL injection condition in the authorized lab, and confirming a controlled web-page modification. This page keeps the technical chain at a portfolio-safe level and does not publish exploit strings, secrets, or reusable attack instructions.

Learning Flow

How the lab developed

Inspect application traffic

Captured and reviewed HTTP requests in Burp Suite to understand how the application handled client input and session data.

Identify exposed logic

Located application behavior that exposed sensitive implementation details, showing why source-code and error handling matter.

Validate input handling weakness

Used the authorized lab to demonstrate how unsafe database input handling can expose protected records.

Confirm impact safely

Verified the effect through controlled application behavior and captured evidence for the written analysis.

Key Findings

Security concepts reinforced

Client-controlled data is untrusted. Cookies, URL parameters, and form values must be validated on the server.
Authentication secrets must never be embedded in accessible code. Exposure of credentials or sensitive logic can lead directly to account compromise.
Database queries must be parameterized. Concatenating user input into SQL statements creates preventable injection risk.
HTTP responses can reveal too much. Error messages, source endpoints, and verbose debugging output can help an attacker map an application.

Defender View

What to monitor and improve

Repeated malformed parameters, unusual cookie values, and abnormal request patterns.
Unexpected application changes or content modifications following suspicious requests.
Database errors, authentication failures, and server logs showing input-validation exceptions.
Use of secure code review, parameterized queries, secret management, least privilege, and web application firewall controls.

Why Burp Suite mattered

From browser behavior to evidence

Burp Suite made it possible to move beyond what the browser displayed and inspect the actual request and response flow. That mattered throughout the lab: it helped reveal how values were being passed, which server responses contained useful clues, and whether a test had actually changed the application state. The core habit I took from this work is to verify security claims with observable evidence rather than assumptions.

Evidence

Selected lab screenshots

Burp Suite request analysis in the WebGoat lab — Request and response inspection in Burp Suite after refreshing the WebGoat challenge page.

Controlled source discovery evidence in the WebGoat lab — Controlled source and application-logic discovery through the WebGoat source endpoint.

Controlled WebGoat input validation test evidence — Intercepted POST request used to examine how WebGoat processed submitted input during the controlled page-modification exercise.

Controlled web page modification evidence in the WebGoat lab — Controlled page-modification result in the isolated WebGoat lab.

Reflection

What this added to my security practice

This exercise made web application security feel much more concrete. It showed how several small weaknesses can connect: exposed information can make authentication easier to bypass, weak input handling can expose data, and a poorly protected administrative function can allow unauthorized changes. The lesson is not just how the flaws work; it is why secure defaults, careful server-side validation, and useful logging have to be built into the application from the start.

Responsible Use

Authorized training environment only

This work was completed only against OWASP WebGoat in an authorized lab environment. The page is presented as a learning case study and intentionally excludes reusable exploit details, credentials, and operational instructions.