Lab 3.3 - Web App Exploitation

1. Lab environment startup

Started the lab stack. Initial errors from stale containers, then three services came up: lab-33-php-nginx, lab-33-database, and lab-33-php-fpm. That's a classic PHP/MySQL storefront topology.

cd /sec401/labs/3.3/ && ./start_3.3.sh

2. Inspect the target app

Loaded store.alphainc.ca:8080/Catalog.php. The page exposes a category picker (attire, energy, exercise, lighting, toys, training) and a free-text search bar. The search bar is the obvious attack surface.

3. Leaking the query via error

Submitted an empty search. The page printed both Array () (an empty result set) and a full PHP exception with the rendered SQL: SELECT * FROM Merchandise WHERE name LIKE '%'%'. That single line reveals: it's a LIKE query, the input is wrapped in single quotes, and stack traces are leaking to users — three serious issues before any payload.

4. Confirm injection with a single quote

Submitted ' as the search term to confirm the injection context.

5. Baseline: a legitimate search result

Ran a normal search to confirm the app returns product records with fields: Product Number, Item, Description, Price, Picture. The target table is clearly Merchandise.

6. Probe the LIKE boundary with ';--

Submitted ';-- to close the string and try to comment out the trailing %'. The error message confirmed the resulting query: SELECT * FROM Merchandise WHERE name LIKE '%':--%', meaning MySQL didn't treat -- as a comment because it wasn't followed by whitespace.

7. Observed error response

The server echoed the unsafe query directly back in the stack trace — a defender's nightmare because it tells the attacker exactly how to refine the payload.

8. Fix the payload: '; -- with trailing space

MySQL's -- comment syntax requires a trailing space. Retried with '; -- (single quote, semicolon, dash-dash, space).

9. Full table dump via broken WHERE clause

The payload produced SELECT * FROM Merchandise WHERE name LIKE '%'; -- %'. The first statement returned everything (LIKE '%' matches all rows), the rest got commented out. Result: all 17 products returned, confirming full data exfiltration from the table.

10. Stacked query: enumerate databases

Graduated from data theft to server reconnaissance. Payload: qq'; show databases; -- . The mysqli driver in this app supports multiple statements, so the second statement executed.

11. Database enumeration success

The page printed Array ( [0] => Database [1] => information_schema [2] => OnlineShop ). Confirmed the app's database is OnlineShop and stacked queries are fully allowed. From here an attacker can drop tables, write files, or escalate — the worst-case SQLi scenario.

12. Deploy the WAF

Ran the lab's WAF enable script to put a filtering proxy in front of the app.

scripts/enable_waf.sh

13. Re-test the same payload

Replayed the stacked-query payload: qq'; show tables; -- . Same request, same target.

14. WAF blocks the request (HTTP 418)

The WAF returned HTTP 418 ('I'm a teapot', a common non-standard block response). Identical payload, defeated. The app is still vulnerable at the code level, but the WAF gives the team time to fix it without leaving the front door open.