🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🍪 धडा 03 — Cookies, CSRF, CORS आणि SSRF: browser आणि server मधला जपून ठेवलेला विश्वास

📍 तुम्ही इथे आहात: 16 पैकी धडा 03 · मागे: lesson-02-xss-csp · पुढे: lesson-04-authentication

📦 या ब्रँचमध्ये काय आहे

धडे 01–02, आणि अर्ज खिडकीचा शेवटचा धडा. चार नियंत्रणे, एक कल्पना — कोण काय पाठवू शकतो, आणि कुठून:

session cookie ला scripts आणि इतर sites पासून दूर ठेवणारे cookie flags,
form शाळेच्याच page वरून आला हे सिद्ध करणारा CSRF token,
इतर कोणत्या sites तुमच्या API ची उत्तरे वाचू शकतात ते browsers ना सांगणारी CORS allow-list,
server URL fetch करण्याआधी तो तपासणारा SSRF पहारेकरी.

sec/demo.py मधले browser() चारही दाखवते.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

कतरिनाकडे शाळेचा एक visitor badge आहे (session cookie). Office त्या badge ला तीन नियम देते:

HttpOnly — badge तिच्या खिशातच राहतो; कोणत्याही अनोळखी व्यक्तीची चिठ्ठी तो वाचू शकत नाही.
Secure — badge फक्त शाळेच्या बंद corridors मध्येच दाखवला जातो (HTTPS).
SameSite — badge फक्त कतरिना स्वतः office मध्ये येते तेव्हाच दाखवला जातो, दुसऱ्या शाळेचे पत्र "तिच्या वतीने" काही मागते तेव्हा नाही.

प्रत्येक अधिकृत form वर कतरिनाच्या badge शी जुळणारा एक गुप्त शिक्का असतो (CSRF token). दुसऱ्या शाळेने बनवलेल्या खोट्या form वर जुळणारा शिक्का नसतो, म्हणून office तो नाकारते.

Office आपली उत्तरे वाचू शकणाऱ्या मैत्रीपूर्ण शाळांची यादी पण ठेवते (CORS). लक्षात ठेवा: ती यादी वाचकांचे browsers तपासतात — office नाही. त्यामुळे कोणी थेट office पर्यंत चालत येण्यापासून थांबत नाही.

शेवटी, office कधी कधी visitors साठी वस्तू आणते: "कृपया या पत्त्यावरून माझा photo आणा." अधिकारी आधी पत्ता तपासतो. फक्त शाळेचे photo दुकान चालते. इमारतीच्या आतले पत्ते — server room, staff ची किल्ल्यांची पेटी — नेहमी नाकारले जातात. ही तपासणी SSRF थांबवते.

🗺️ आकृती

flowchart LR
    b["🌐 Katrina's browser<br/>cookie: HttpOnly · Secure · SameSite=Lax"]
    ev["🏴 other site<br/>fake form, no token"]
    subgraph srv["🏫 school server"]
      csrf["🔏 CSRF check<br/>token matches session?"]
      cors["📜 CORS header<br/>allow-list of origins"]
      ssrf["🧭 SSRF guard<br/>https · allow-listed host · no private IPs"]
    end
    b -->|"form + token"| csrf
    ev -->|"no token"| csrf
    cors -.->|"browser enforces"| b
    ssrf -->|"allowed"| shop["🖼️ images.school.example"]
    ssrf -.->|"refused"| meta["🔒 169.254.169.254<br/>10.0.0.5"]

🗺️ काढलेली आवृत्ती + एक lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l03

❓ काय

Session cookie flags (cookie_ok() तिन्ही तपासते):
- HttpOnly — JavaScript cookie वाचू शकत नाही, त्यामुळे XSS bug ती copy करू शकत नाही.
- Secure — फक्त HTTPS वरूनच पाठवली जाते.
- SameSite — दुसऱ्या site वर सुरू झालेल्या requests सोबत browser cookie कधी पाठवतो: Strict (कधीच नाही), Lax (फक्त link click सारख्या safe methods असलेल्या top-level navigations वर — Chrome आणि Edge SameSite नसलेल्या cookie ला Lax मानतात), None (नेहमी — आणि मग Secure आवश्यक).
CSRF (cross-site request forgery) — दुसरी site पीडिताच्या browser कडून तुमच्या site ला request पाठवायला लावते, आणि browser पीडिताची cookie जोडतो. उपाय: session शी जोडलेला CSRF token, state बदलणाऱ्या प्रत्येक request वर तपासलेला. csrf_token() हा session id चा HMAC आहे; csrf_ok() constant time मध्ये तुलना करते. SameSite=Lax किंवा Strict हा मजबूत दुसरा थर आहे. OWASP Top 10 (2021) CSRF ला A01:2021 – Broken Access Control शी जोडते.
CORS (cross-origin resource sharing) — default ने evil.example वरचे page तुमच्या API ची उत्तरे वाचू शकत नाही (same-origin policy). CORS headers origins च्या allow-list साठी ही बंदी सैल करतात. CORS browsers enforce करतात, तुमचा server नाही. Script, curl किंवा दुसरा server त्याकडे दुर्लक्ष करतो. हे authentication किंवा authorization नियंत्रण नाही — प्रत्येक endpoint अजूनही session आणि permissions तपासतो.
SSRF (server-side request forgery) — user ने दिलेला URL server fetch करतो (photo, webhook, PDF preview). Crafted URL त्याला तुमच्या network च्या आत वळवतो: http://10.0.0.5/admin, किंवा 169.254.169.254 वरची cloud instance metadata service, जी credentials देऊ शकते. A10:2021 – SSRF. ssrf_ok() फक्त https, फक्त allow-list मधले hosts चालू देते, आणि private, loopback किंवा link-local addresses कधीच नाहीत.
IMDSv2 — AWS EC2 वर metadata service साठी session tokens आवश्यक करा (HttpTokens=required). Token साठी आधी PUT request लागते, जी बहुतेक SSRF bugs पाठवू शकत नाहीत. 1 चा hop limit token चे उत्तर instance च्या पलीकडे जाण्यापासून थांबवतो.

🤔 का

कारण browser मदत करणारा आहे: तो तुमच्या site वरच्या प्रत्येक request ला cookies जोडतो, अगदी दुसऱ्या site ने सुरू केलेल्या requests ला सुद्धा. आणि servers मदत करणारे आहेत: त्यांना जे सांगितले ते ते fetch करतात. इथले प्रत्येक नियंत्रण ती मदत अटीवर देते — फक्त ही site, फक्त हा form, फक्त हा host. ती नसतील तर, login केलेले पालक चुकीचे page उघडून नकळत स्वतःचा password बदलू शकतात, आणि photo preview तुमची cloud credentials वाचू शकतो.

🔧 कसे (या repo मध्ये)

sec/web.py मध्ये: cookie_ok(header) Set-Cookie header वाचते आणि नसलेले flags यादीत देते. csrf_token(session_id) म्हणजे HMAC-SHA256(SECRET, session_id), 16 hex अक्षरांपर्यंत कापलेले; csrf_ok() hmac.compare_digest ने तुलना करते. cors_ok(origin) अचूक allow-list (https://school.example) तपासते. ssrf_ok(url) URL parse करते, https नसलेले सगळे नाकारते, private, loopback किंवा link-local IP addresses नाकारते, मग host allow-list (images.school.example) मध्ये असणे आवश्यक करते.

🧪 करून पाहा

python3 sec/demo.py browser
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from web import cookie_ok, csrf_token, csrf_ok, cors_ok, ssrf_ok
for h in ("sid=1; Secure", "sid=1; HttpOnly; Secure; SameSite=Strict"):
    print(f"{h:<42} → {cookie_ok(h)}")
print("Katrina's token works for Dipika's session →", csrf_ok("sess-dipika", csrf_token("sess-katrina")))
print("http://school.example (not https)          →", cors_ok("http://school.example"))
for u in ("https://127.0.0.1/", "https://192.168.1.1/router", "file:///etc/passwd", "https://images.school.example.evil.example/x"):
    print(f"{u:<45} → {ssrf_ok(u)}")
EOF

✅ तपासा — तुम्हाला काय दिसायला हवे

browser हे print करते:

── Set-Cookie: session=abc123                                   → missing httponly, secure, samesite
── Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax   → ok
── CSRF: the form carries a token tied to the session → valid True · forged False · missing False
── CORS allow-list: https://school.example → True · https://evil.example → False
── SSRF: the server fetches a photo URL a user typed — check it first
   https://images.school.example/p/7.jpg      → (True, 'allowed')
   http://images.school.example/p/7.jpg       → (False, 'only https')
   https://169.254.169.254/latest/            → (False, 'private / internal address')
   https://10.0.0.5/admin                     → (False, 'private / internal address')
   https://evil.example/x                     → (False, 'host not on the allow-list')

तुमचा snippet हे print करतो:

sid=1; Secure                              → (False, ['httponly', 'samesite'])
sid=1; HttpOnly; Secure; SameSite=Strict   → (True, [])
Katrina's token works for Dipika's session → False
http://school.example (not https)          → False
https://127.0.0.1/                            → (False, 'private / internal address')
https://192.168.1.1/router                    → (False, 'private / internal address')
file:///etc/passwd                            → (False, 'only https')
https://images.school.example.evil.example/x  → (False, 'host not on the allow-list')

🏁 तुम्ही आत्ताच काय सिद्ध केले

एका session साठी बनवलेला token दुसऱ्या session साठी निरुपयोगी असतो. CORS यादी अचूक जुळणी मागते — https:// ऐवजी http:// सुद्धा नाकारले जाते. आणि SSRF पहारेकरी असा host नाकारतो जो परवानगी असलेल्या नावाने फक्त सुरू होतो: तपासणी पूर्ण host ची तुलना करते, prefix ची नाही. मुख्य काम allow-list करते; private-address नियम हे दुसरे कुलूप आहे.

⚠️ नेहमीच्या चुका

HttpOnly नसलेल्या session cookies (मग XSS त्या copy करते) किंवा Secure नसलेल्या
फक्त SameSite वर अवलंबून राहणे — subdomains एकच site मानले जातात, आणि जुने browsers वेगळे वागतात
Access-Control-Allow-Credentials: true सह कोणताही Origin परत दाखवणारा CORS
CORS ला API ची security मानणे ("फक्त आमचीच site call करू शकते") — ते तसे नाही
फक्त block-list असलेली SSRF तपासणी, किंवा DNS resolution आणि redirects नंतर पुन्हा न केलेली नावाची तपासणी
IMDSv1 चालू ठेवणे, त्यामुळे फक्त GET करणारा SSRF bug instance credentials वाचू शकतो

🏭 प्रत्यक्ष वापरात

खऱ्या account वर — Flask आणि Express मधले cookie flags:

app.config.update(SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SECURE=True, SESSION_COOKIE_SAMESITE="Lax")

app.use(session({ secret: process.env.SESSION_SECRET, resave: false, saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'lax', maxAge: 30 * 60 * 1000 } }));

CSRF middleware — Django मध्ये ते default ने चालू असते (MIDDLEWARE मध्ये CsrfViewMiddleware आणि प्रत्येक form मध्ये {% csrf_token %} ठेवा); Flask Flask-WTF वापरते:

from flask_wtf.csrf import CSRFProtect
CSRFProtect(app)          # every POST/PUT/PATCH/DELETE must carry the token

अचूक allow-list सह CORS (Express cors package). लक्षात ठेवा: हे फक्त browsers ना ते काय वाचू शकतात ते सांगते; route अजूनही session आणि permissions तपासतो:

import cors from 'cors';
app.use('/api', cors({ origin: ['https://school.example'], credentials: true }));

Resolved addresses सुद्धा तपासणारा SSRF पहारेकरी (Python), जो redirects नाकारतो:

import ipaddress, socket
from urllib.parse import urlparse
ALLOWED = {"images.school.example"}
def safe_to_fetch(url):
    u = urlparse(url)
    if u.scheme != "https" or u.hostname not in ALLOWED: return False
    for info in socket.getaddrinfo(u.hostname, 443):
        ip = ipaddress.ip_address(info[4][0])
        if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved: return False
    return True
# then fetch with redirects off, e.g. requests.get(url, allow_redirects=False, timeout=5)

EC2 instance वर 1 च्या hop limit सह IMDSv2 आवश्यक करा:

aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
    --http-tokens required --http-put-response-hop-limit 1 --http-endpoint enabled

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: cookie flags एकदाच, framework config मध्ये set करा. स्वतःचे लिहिण्याऐवजी framework चे CSRF संरक्षण चालू करा. बाहेर जाणारे fetches allow-list असलेल्या एकाच function मागे ठेवा — किंवा फक्त internet पर्यंत पोहोचू शकणाऱ्या proxy मागे — आणि तुमच्या launch templates मध्ये IMDSv2 default करा.

⏭️ पुढे

अर्ज खिडकी पूर्ण झाली. आता ओळखपत्र खिडकी: शाळेला कसे कळते की ही खरोखर कतरिनाच आहे — चोराला वापरता येणार नाहीत असे साठवलेले passwords, MFA आणि passkeys, sessions आणि tokens.

git checkout lesson-04-authentication

🍪 Lesson 03 — Cookies, CSRF, CORS and SSRF: careful trust between browser and server

📍 You are here: Lesson 03 of 16 · Previous: lesson-02-xss-csp · Next: lesson-04-authentication

📦 What's in this branch

Lessons 01–02, plus the last lesson of the forms desk. Four controls, one idea — who may send what, and from where:

cookie flags that keep the session cookie away from scripts and other sites,
a CSRF token that proves a form came from the school's own page,
a CORS allow-list that tells browsers which other sites may read your API's answers,
an SSRF guard that checks a URL before the server fetches it.

browser() in sec/demo.py shows all four.

🧒 Explain like I'm 5

Katrina has a visitor badge for the school (the session cookie). The office gives the badge three rules:

HttpOnly — the badge stays in her pocket; no stranger's note can read it.
Secure — the badge is only shown inside the school's closed corridors (HTTPS).
SameSite — the badge is only shown when Katrina herself walks into the office, not when a letter from another school asks for something "on her behalf".

Every official form also has a secret stamp that matches Katrina's badge (the CSRF token). A fake form made by another school has no matching stamp, so the office refuses it.

The office also keeps a list of friendly schools that may read its replies (CORS). Note: the readers' browsers check that list — not the office. It does not stop anyone from walking up to the office directly.

Last, the office sometimes fetches things for visitors: "please collect my photo from this address". The officer checks the address first. Only the school photo shop is allowed. Addresses inside the building — the server room, the staff key box — are always refused. That check stops SSRF.

🗺️ Diagram

flowchart LR
    b["🌐 Katrina's browser<br/>cookie: HttpOnly · Secure · SameSite=Lax"]
    ev["🏴 other site<br/>fake form, no token"]
    subgraph srv["🏫 school server"]
      csrf["🔏 CSRF check<br/>token matches session?"]
      cors["📜 CORS header<br/>allow-list of origins"]
      ssrf["🧭 SSRF guard<br/>https · allow-listed host · no private IPs"]
    end
    b -->|"form + token"| csrf
    ev -->|"no token"| csrf
    cors -.->|"browser enforces"| b
    ssrf -->|"allowed"| shop["🖼️ images.school.example"]
    ssrf -.->|"refused"| meta["🔒 169.254.169.254<br/>10.0.0.5"]

🗺️ Drawn version + a lab: https://school-edh.pages.dev/security/lesson-diagrams.html#l03

❓ What

Session cookie flags (cookie_ok() checks all three):
- HttpOnly — JavaScript cannot read the cookie, so an XSS bug cannot copy it.
- Secure — sent only over HTTPS.
- SameSite — when the browser sends the cookie on requests that start on another site: Strict (never), Lax (only on top-level navigations with safe methods such as a link click — Chrome and Edge treat a cookie with no SameSite as Lax), None (always — and then Secure is required).
CSRF (cross-site request forgery) — another site makes the victim's browser send a request to your site, and the browser adds the victim's cookie. The fix: a CSRF token tied to the session, checked on every state-changing request. csrf_token() is an HMAC of the session id; csrf_ok() compares in constant time. SameSite=Lax or Strict is a strong second layer. OWASP Top 10 (2021) maps CSRF to A01:2021 – Broken Access Control.
CORS (cross-origin resource sharing) — by default a page from evil.example cannot read answers from your API (the same-origin policy). CORS headers relax that for an allow-list of origins. CORS is enforced by browsers, not by your server. A script, curl or another server ignores it. It is not an authentication or authorization control — every endpoint still checks the session and the permissions.
SSRF (server-side request forgery) — the server fetches a URL that a user supplied (a photo, a webhook, a PDF preview). A crafted URL points it inside your network: http://10.0.0.5/admin, or the cloud instance metadata service at 169.254.169.254, which can hand out credentials. A10:2021 – SSRF. ssrf_ok() allows only https, only allow-listed hosts, and never private, loopback or link-local addresses.
IMDSv2 — on AWS EC2, require session tokens for the metadata service (HttpTokens=required). A token needs a PUT request first, which most SSRF bugs cannot send. A hop limit of 1 stops the token reply from travelling beyond the instance itself.

🤔 Why

Because the browser is helpful: it adds cookies to every request to your site, even requests that another site started. And because servers are helpful: they fetch what they are asked to. Each control here makes that help conditional — only this site, only this form, only this host. Without them, a logged-in parent who opens the wrong page can change their own password without knowing, and a photo preview can read your cloud credentials.

🔧 How (in this repo)

In sec/web.py: cookie_ok(header) reads a Set-Cookie header and lists the missing flags. csrf_token(session_id) is HMAC-SHA256(SECRET, session_id), cut to 16 hex characters; csrf_ok() compares with hmac.compare_digest. cors_ok(origin) checks an exact allow-list (https://school.example). ssrf_ok(url) parses the URL, refuses anything that is not https, refuses IP addresses that are private, loopback or link-local, then requires the host to be on the allow-list (images.school.example).

🧪 Try it

python3 sec/demo.py browser
python3 - <<'EOF'
import sys; sys.path.insert(0, "sec"); from web import cookie_ok, csrf_token, csrf_ok, cors_ok, ssrf_ok
for h in ("sid=1; Secure", "sid=1; HttpOnly; Secure; SameSite=Strict"):
    print(f"{h:<42} → {cookie_ok(h)}")
print("Katrina's token works for Dipika's session →", csrf_ok("sess-dipika", csrf_token("sess-katrina")))
print("http://school.example (not https)          →", cors_ok("http://school.example"))
for u in ("https://127.0.0.1/", "https://192.168.1.1/router", "file:///etc/passwd", "https://images.school.example.evil.example/x"):
    print(f"{u:<45} → {ssrf_ok(u)}")
EOF

✅ Verify — what you should see

browser prints:

── Set-Cookie: session=abc123                                   → missing httponly, secure, samesite
── Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax   → ok
── CSRF: the form carries a token tied to the session → valid True · forged False · missing False
── CORS allow-list: https://school.example → True · https://evil.example → False
── SSRF: the server fetches a photo URL a user typed — check it first
   https://images.school.example/p/7.jpg      → (True, 'allowed')
   http://images.school.example/p/7.jpg       → (False, 'only https')
   https://169.254.169.254/latest/            → (False, 'private / internal address')
   https://10.0.0.5/admin                     → (False, 'private / internal address')
   https://evil.example/x                     → (False, 'host not on the allow-list')

Your snippet prints:

sid=1; Secure                              → (False, ['httponly', 'samesite'])
sid=1; HttpOnly; Secure; SameSite=Strict   → (True, [])
Katrina's token works for Dipika's session → False
http://school.example (not https)          → False
https://127.0.0.1/                            → (False, 'private / internal address')
https://192.168.1.1/router                    → (False, 'private / internal address')
file:///etc/passwd                            → (False, 'only https')
https://images.school.example.evil.example/x  → (False, 'host not on the allow-list')

🏁 What you just proved

A token made for one session is useless for another session. The CORS list is an exact match — even http:// instead of https:// is refused. And the SSRF guard refuses a host that only starts with the allowed name: the check compares the whole host, not a prefix. The allow-list does the heavy work; the private-address rule is the second lock.

⚠️ Common mistakes

session cookies without HttpOnly (XSS then copies them) or without Secure
relying on SameSite alone — subdomains count as the same site, and old browsers differ
CORS that reflects any Origin with Access-Control-Allow-Credentials: true
treating CORS as security for the API ("only our site can call it") — it is not
an SSRF check with a block-list only, or a check on the name that is not repeated after DNS resolution and redirects
leaving IMDSv1 on, so a GET-only SSRF bug can read instance credentials

🏭 In production

On a real account — cookie flags in Flask and in Express:

app.config.update(SESSION_COOKIE_HTTPONLY=True, SESSION_COOKIE_SECURE=True, SESSION_COOKIE_SAMESITE="Lax")

app.use(session({ secret: process.env.SESSION_SECRET, resave: false, saveUninitialized: false,
  cookie: { httpOnly: true, secure: true, sameSite: 'lax', maxAge: 30 * 60 * 1000 } }));

CSRF middleware — Django has it on by default (keep CsrfViewMiddleware in MIDDLEWARE and {% csrf_token %} in every form); Flask uses Flask-WTF:

from flask_wtf.csrf import CSRFProtect
CSRFProtect(app)          # every POST/PUT/PATCH/DELETE must carry the token

CORS with an exact allow-list (Express cors package). Remember: this only tells browsers what they may read; the route still checks the session and permissions:

import cors from 'cors';
app.use('/api', cors({ origin: ['https://school.example'], credentials: true }));

An SSRF guard that checks the resolved addresses too (Python), and refuses redirects:

import ipaddress, socket
from urllib.parse import urlparse
ALLOWED = {"images.school.example"}
def safe_to_fetch(url):
    u = urlparse(url)
    if u.scheme != "https" or u.hostname not in ALLOWED: return False
    for info in socket.getaddrinfo(u.hostname, 443):
        ip = ipaddress.ip_address(info[4][0])
        if ip.is_private or ip.is_loopback or ip.is_link_local or ip.is_reserved: return False
    return True
# then fetch with redirects off, e.g. requests.get(url, allow_redirects=False, timeout=5)

Require IMDSv2 with a hop limit of 1 on an EC2 instance:

aws ec2 modify-instance-metadata-options --instance-id i-0123456789abcdef0 \
    --http-tokens required --http-put-response-hop-limit 1 --http-endpoint enabled

🏭 Why this matters in production: set cookie flags once, in the framework config. Turn on the framework's CSRF protection instead of writing your own. Put outbound fetches behind one function with an allow-list — or a proxy that can only reach the internet — and make IMDSv2 the default in your launch templates.

⏭️ Next

The forms desk is done. Now the ID desk: how the school knows it is really Katrina — passwords stored so a thief cannot use them, MFA and passkeys, sessions and tokens.

git checkout lesson-04-authentication

← Previousxss csp Next →authentication

This page is the lesson's README from the lesson-03-browser-server branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.