CSRF Basics

Cross-site request forgery defense — tokens and SameSite on YOUR lab forms.

CSRF Basics• Audio Walkthrough

00:00/02:40

Visual · t17_csrf_basics

CSRF = browser sends authenticated request user did not intend. Original Cyberlium.

Your browser will happily POST a transfer if the session cookie still works — CSRF defenses say prove intent.

CSRF tricks a logged-in browser into submitting state-changing requests to YOUR app using the victim's existing session. Defenses: unpredictable anti-CSRF tokens validated server-side, SameSite cookies, double-submit or custom headers for AJAX, and re-auth for sensitive actions. Learn to spot missing CSRF on forms in $REPO — never deploy CSRF PoCs against classmate, employer, or public production apps without written scope.

1. Attack shape

Attacker page triggers POST/PUT/DELETE while victim session is active — browser attaches cookies automatically.

Safe methods (GET) should not change state — defense starts with HTTP semantics.

Command guide

Try these commands — Attack shape

═══ LINUX / BASH (Network & Reconnaissance Audit) ═══

Scan target host for open ports and service version signatures

Command — copy this

nmap -sS -sV -p 80,443,8080 -Pn ${LAB_HOST:-127.0.0.1}

DNS and WHOIS reconnaissance on authorized domain

Command — copy this

dig +short A target.local
dig +short MX target.local
whois target.local 2>/dev/null | grep -iE "(Registrar|Creation Date|Name Server)" | head -6

Inspect HTTP headers for technology stack fingerprinting

Command — copy this

curl -s -I "http://${LAB_HOST:-127.0.0.1}:8080" | grep -iE "(Server|X-Powered-By|Set-Cookie|Content-Security-Policy)"

Primary tools to practice this lesson: python3, grep. Reference sites: CSRF (https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html); SameSite (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.