Back to all work

Web Attack-Log & Hardening Investigation

Live loopback request analysis paired with a controlled before-and-after hardening assessment.

HTTP · Python · Access logs · Localhost fixture

Five live requests produced three review signals; four hardening checks moved to zero.

Web attack-log summary showing five loopback requests, two controls and three findings
Reproducible lab result. Generated from requests actually sent to the isolated loopback service and the committed access log.

The live request investigation

I sent five predeclared GET requests to an ephemeral service bound to 127.0.0.1. Two were benign controls. Three carried an encoded traversal pattern, an encoded injection pattern or a scanner-like training user agent. The resulting access.log is the exact record analyzed here.

From request to finding

The analyzer decoded request paths only for matching, preserved safe encoded indicators in its report, and produced three review signals. The suspicious endpoints returned 404, so the result establishes observable attack patterns—not successful exploitation.

The problem

The local fixture deliberately omits protective headers, weakens cookie attributes, and exposes debug information. The question is whether the same checks stop matching after targeted changes.

What I changed

Added the sample headers and cookie attributes and removed the debug detail. Re-ran the identical assessment against the hardened localhost fixture.

What I found

The four scoped conditions changed from matching to nonmatching. LAB-WEB-001 documents the source responses and exact rule IDs. A zero-finding result applies only to these checks.

Why the retest matters

A remediation claim should use the same checks and scope as the original assessment. This exercise compares the intentionally weak localhost response with the remediated response and keeps the control predicates visible. Four matching omissions become zero matches under those predicates.

What remains outside the assessment

Passing these response checks does not assess authentication, application logic, browser behavior or transport security. A useful handoff names the fixed controls and the remaining assessment surface rather than declaring the application secure.

Inspect the evidence

Academic foundation

Completed coursework: IST 5930 Web System Security seminar (Spring 2023), IST 4620 Penetration Testing & Ethical Hacking and IST 5250 Incident Handling & Cyber Investigation (Fall 2024).

See the transcript-supported academic background ↗

Scope

Completed loopback-only lab. It does not establish successful exploitation, deployed application security, HTTPS behavior, browser CSP enforcement, or a real vulnerability scan.

Read the full analyst report on GitHub ↗

Data, source code, and reproduction

Choose another case study ↗