A methodology for beginner CTF web challenges: source, robots.txt, cookies, and requests

Look before you poke

Many beginner web challenges are solved by reading: HTML comments, JavaScript files that contain client-side checks, robots.txt listing hidden paths, and response headers. Open developer tools, read the Sources and Network panels, and note every endpoint the page calls.

• View source and comments
• robots.txt, sitemap.xml
• JavaScript files and source maps
• Response headers
• Cookies, localStorage, sessionStorage

Change what the client sends

Anything the client controls can be changed: form fields, hidden inputs, cookies, headers, and query parameters. A cookie like admin=false or a client-side price check in JavaScript is a classic beginner lesson. Use the browser’s edit and resend feature, curl, or an intercepting proxy such as Burp Suite Community or OWASP ZAP to modify requests.

curl -s https://challenge.example/robots.txt
curl -s -i https://challenge.example/ | head -20
curl -s -b 'role=admin' https://challenge.example/dashboard
curl -s -H 'X-Forwarded-For: 127.0.0.1' https://challenge.example/internal
curl -s -X POST -d 'item=1&price=0' https://challenge.example/buy

Lab: practise on intentionally vulnerable apps

Run OWASP Juice Shop locally with Docker and complete the one-star and two-star challenges from its score board, which are designed to teach exactly these skills. Keep it on localhost. For each solved challenge, write one line about the root cause, such as “authorization checked only in the browser”.

docker run --rm -p 127.0.0.1:3000:3000 bkimminich/juice-shop
# then open http://127.0.0.1:3000 and find the score board

Scope

Only test the challenge host and only in the ways the rules allow. Avoid automated scanners against event infrastructure unless permitted; they often violate rules and slow the event for everyone. The same discipline applies to bug bounty programs and penetration tests.