CSRF আর cookie সুরক্ষা — SameSite, token আর clickjacking

১ · Cookie নিজে থেকেই যায়: CSRF-এর মূল কারণ

রহিমা একটি কাল্পনিক অনলাইন বাজার shop.example.com-এ login করলেন। Tab বন্ধ করেননি। তারপর আরেকটি tab-এ একটি অচেনা ব্লগ খুললেন। ব্লগটি দেখতে সাধারণ। অথচ পরদিন দেখলেন, তাঁর account-এর delivery ঠিকানা বদলে গেছে। তিনি নিজে কিছু করেননি। Password চুরি হয়নি, server-এও কেউ ঢোকেনি। তাহলে হলো কী?

এর নাম CSRF, পুরো নাম Cross-Site Request Forgery. বাংলায় বলা যায় “অন্য site থেকে জাল অনুরোধ”। এখানে অন্য একটি পাতা রহিমার browser-কে দিয়ে shop-এ একটি request পাঠিয়েছে। Browser সেই request-এ shop-এর cookie নিজে থেকে জুড়ে দিয়েছে। Server cookie দেখে ভেবেছে, রহিমা নিজেই চেয়েছেন।

নিরাপত্তার ভাষায় এই সুবিধার নাম ambient authority: অধিকার পরিবেশেই আছে, আলাদা করে দেখাতে হয় না। আর browser এখানে একজন confused deputy: নিজের অধিকার দিয়ে অন্যের নির্দেশ পালন করছে। Cookie-র মতো একই সমস্যা হয় HTTP Basic auth, TLS client certificate আর “অফিসের network থেকে এলেই বিশ্বাস” ধরনের নিয়মে। এগুলোও browser বা network নিজে থেকে যোগ করে।

আক্রমণকারী এখানে উত্তরটি সাধারণত পড়তে পারে না। Same-origin policy অন্য origin-এর response পড়া আটকায় (পর্ব ৩৬)। কিন্তু CSRF-এর উত্তর পড়ার দরকার নেই। কাজ হয়ে গেলেই ক্ষতি। তাই ক্ষতি নির্ভর করে কাজটির ওপর: ঠিকানা বা email বদল, টাকা পাঠানো, role বদল, এমনকি admin-এর নতুন user তৈরি। ব্যবহারকারী admin হলে পুরো system ঝুঁকিতে পড়ে।

আরেকটি রূপ আছে, login CSRF. এখানে ভুক্তভোগীকে আক্রমণকারীর নিজের account-এ login করিয়ে দেওয়া হয়। ভুক্তভোগী যা খোঁজেন বা যে কার্ড যোগ করেন, তা ওই account-এ জমে। তাই login form-ও CSRF প্রতিরক্ষার বাইরে নয়। Login-এর আগে একটি প্রাথমিক session-এ token বাঁধা যায়, আর login সফল হলে session বদলে নিতে হয় (পর্ব ১৭).

২ · প্রথম নিয়ম: GET কখনো কিছু বদলাবে না

HTTP method-গুলোর দুটি দল আছে। Safe method, যেমন GET, HEAD আর OPTIONS, শুধু পড়ার জন্য। POST, PUT, PATCH আর DELETE হলো state-changing request, অর্থাৎ এগুলো কিছু বদলায়। RFC 9110 এই অর্থই দেয়। প্রায় সব CSRF প্রতিরক্ষা এই বিভাজনের ওপর দাঁড়িয়ে।

এই নিয়ম ভাঙলে আরও একটি বিপদ আসে। SameSite=Lax বাইরের লিংকে ক্লিক করে আসা GET-এ cookie পাঠায়। তাই GET কিছু বদলালে Lax আর আপনাকে বাঁচাবে না। আরেকটি পরিচিত ফাঁদ হলো framework-এর method override. কিছু framework লুকানো field বা header দেখে request-এর method বদলে ধরে। আপনার route যে method-এ কাজ করে, প্রতিরক্ষাও সেই method-এ আছে কি না যাচাই করুন।

৩ · CSRF token: যা অন্য site জানতে পারে না

সমাধানের মূল চিন্তা সহজ। Request-এ এমন একটি মান চাই যা browser নিজে থেকে দেয় না, আর অন্য site পড়তেও পারে না। এই মানের নাম CSRF token. Same-origin policy-র কারণে অন্য site আপনার পাতার ভেতরের token পড়তে পারে না।

Synchronizer token

Synchronizer token pattern-এ server একটি এলোমেলো মান বানিয়ে session-এর সঙ্গে রাখে। মানটি CSPRNG থেকে আসে। Form-এর ভেতরে লুকানো field-এ, বা SPA-তে একটি custom header-এ সেটি ফেরত আসে। Server দুটি মান মিলিয়ে দেখে। নিচের ডায়াগ্রামে একটি সৎ form submit ধাপে ধাপে দেখুন।

GET /transfer HTTP/1.1
Host: shop.example.com
Cookie: __Host-sid=sid-rahima

sid-rahima → { user: "rahima",
               csrf: "tok-a1" }
খেলনা মান; real token ২৫৬ bit এলোমেলো

<form method="post" action="/transfer">
  <input type="hidden" name="csrf" value="tok-a1">
  <input name="amount">
  <button>পাঠান</button>
</form>

POST /transfer HTTP/1.1
Host: shop.example.com
Origin: https://shop.example.com
Sec-Fetch-Site: same-origin
Cookie: __Host-sid=sid-rahima

amount=500&csrf=tok-a1

session("sid-rahima").csrf = tok-a1
request field              = tok-a1
মিলেছে → balance 5000 → 4500

কয়েকটি বাস্তব সিদ্ধান্ত মনে রাখুন। Session-প্রতি একটি token সাধারণত যথেষ্ট। Request-প্রতি নতুন token একটু বেশি শক্ত, কিন্তু browser-এর back বাটনে ব্যবহারকারী আটকে যেতে পারেন। Token তুলনা হবে constant-time পদ্ধতিতে। Token কখনো URL-এ রাখা চলবে না।

Signed double-submit cookie

Server-এ session store না থাকলে কী হবে? তখন double-submit cookie কাজে আসে। Token একবার cookie-তে যায়, আরেকবার form বা header-এ। Server দুটি মিলিয়ে দেখে। অন্য site cookie পড়তে পারে না, তাই সে দ্বিতীয় জায়গায় একই মান বসাতে পারে না।

কিন্তু সাধারণ (naive) রূপটিতে ফাঁক আছে। কেউ কোনোভাবে cookie বসাতে পারলে, যেমন একটি দখল হওয়া subdomain থেকে, সে দুই জায়গাতেই নিজের জানা মান বসাতে পারে। OWASP তাই naive রূপকে DISCOURAGED বলে। সমাধান signed double-submit: token-কে HMAC দিয়ে session-এর সঙ্গে বাঁধা। Key server ছাড়া কারও কাছে নেই, তাই বাইরে থেকে বৈধ token বানানো যায় না। HMAC-এর ভিত্তি পর্ব ৯-এ।

নিচে Python-এর আসল hmac module দিয়ে পুরোটি চালানো হয়েছে। Key নকল, session খেলনা। সূত্রে দৈর্ঘ্য বসানো হয়েছে যাতে দুই field-এর সীমানা গুলিয়ে না যায়।

import hashlib, hmac

KEY = b"example-key-not-real"      # নকল key; আসল key থাকে secret store-এ

def message(session_id, rand):
    s, r = session_id.encode(), rand.encode()
    return len(s).to_bytes(4, "big") + s + len(r).to_bytes(4, "big") + r

def tag_of(session_id, rand):
    return hmac.new(KEY, message(session_id, rand), hashlib.sha256).hexdigest()

def issue(session_id, rand):       # real কোডে rand = secrets.token_hex(32)
    return tag_of(session_id, rand) + "." + rand

def verify(session_id, cookie_tok, sent_tok):
    if not hmac.compare_digest(cookie_tok.encode(), sent_tok.encode()):
        return "DENY cookie and field differ"
    tag, dot, rand = sent_tok.partition(".")
    if not dot:
        return "DENY bad format"
    good = tag_of(session_id, rand)
    return "ALLOW" if hmac.compare_digest(tag.encode(), good.encode()) else "DENY bad HMAC"

def naive(cookie_tok, sent_tok):   # শুধু দুই মান মেলায়, স্বাক্ষর দেখে না
    return "ALLOW" if cookie_tok == sent_tok else "DENY"

tok = issue("sid-rahima", "r-7f3a")
other = issue("sid-karim", "r-91bc")
bad = "0" * 64 + ".r-7f3a"
print("token:", tok[:20] + "..." + tok[-7:], "length", len(tok))
print("1 correct      :", verify("sid-rahima", tok, tok))
print("2 no field     :", verify("sid-rahima", tok, ""))
print("3 other session:", verify("sid-rahima", other, other))
print("4 planted value:", verify("sid-rahima", bad, bad))
print("5 naive, same  :", naive(bad, bad))

OWASP একটি কথা জোর দিয়ে বলে। Session-এর সঙ্গে না বেঁধে শুধু সই করলে লাভ সামান্য, কারণ আক্রমণকারী নিজের জন্য পাওয়া বৈধ token বসাতে পারে। Email বা user ID-র মতো স্থির মানও না, এমন মান নিন যা প্রতি login-এ বদলায়।

৪ · SameSite: browser-এর দরজায় বাছাই

পর্ব ১৭-এ cookie-র flag দেখেছেন। এখানে একটি flag-ই গভীরে দেখব। SameSite browser-কে বলে, অন্য site থেকে শুরু হওয়া request-এ cookie পাঠানো হবে কি না। এটি server-এ নয়, browser-এ কাজ করে।

এবার registrable domain নিয়ে একটি জরুরি কথা। Origin মানে scheme, host আর port, তিনটিই হুবহু এক। Site অনেক ঢিলা: scheme আর registrable domain এক হলেই চলে। Registrable domain ঠিক হয় Public Suffix List দেখে। ফলে shop.example.com আর blog.example.com আলাদা origin, কিন্তু একই site.

নিচের খেলনা টেবিলে একই request তিনটি মানে কেমন ফল দেয় দেখুন। এখানে সরলতার জন্য site মানে domain-এর শেষ দুই অংশ।

// খেলনা SameSite টেবিল: real cookie বা request নেই
// খেলনা site = শেষ দুই label; real browser Public Suffix List দেখে
const site = h => h.split(".").slice(-2).join(".");
const SAFE = ["GET", "HEAD"];

function sends(mode, q) {
  if (site(q.from) === site(q.to)) return true;
  if (mode === "None") return true;              // Secure-ও লাগবে
  if (mode === "Strict") return false;
  return q.kind === "navigate" && SAFE.includes(q.method);  // Lax
}

const TO = "shop.example.com";
const rows = [
  ["same page POST",  "shop.example.com",  "navigate", "POST"],
  ["sibling fetch",   "blog.example.com",  "fetch",    "POST"],
  ["link click",      "other.example.net", "navigate", "GET"],
  ["cross form POST", "other.example.net", "navigate", "POST"],
  ["cross image",     "other.example.net", "image",    "GET"],
  ["cross iframe",    "other.example.net", "iframe",   "GET"],
  ["cross fetch",     "other.example.net", "fetch",    "POST"],
];

const yn = b => (b ? "send" : "-").padEnd(8);
console.log("request".padEnd(17), "Strict  ", "Lax     ", "None");
for (const [name, from, kind, method] of rows) {
  const q = { from, to: TO, kind, method };
  console.log(name.padEnd(17), yn(sends("Strict", q)), yn(sends("Lax", q)),
              yn(sends("None", q)));
}

SameSite-এর সীমা

• Subdomain: পাশের subdomain same-site. সেখানে XSS বা দখল হলে SameSite কিছু করে না।
• Lax-এ GET: GET কিছু বদলালে বাইরের লিংকেই কাজ হয়ে যাবে।
• Default-এ ভরসা: Chromium-ভিত্তিক browser ২০২০ সাল থেকে ধাপে ধাপে flag না থাকলে Lax ধরে। সব browser তা করে না। MDN আরও বলে, এই default-এর অবস্থায় সদ্য বসানো cookie প্রায় দুই মিনিট POST-এও যেতে পারে। তাই flag নিজে লিখুন।
• Client-side CSRF: আপনার নিজের পাতার JavaScript যদি URL থেকে পাওয়া মান দিয়ে request পাঠায়, সেটি same-site. Cookie চলে যায়।
• পুরোনো বা embedded browser: সব জায়গায় এই নিয়ম মানা হয় না।

তাই OWASP SameSite-কে স্তর হিসেবে রাখে, একমাত্র প্রতিরক্ষা হিসেবে নয়। এটি defense in depth-এর একটি চমৎকার উদাহরণ।

৫ · Origin, Referer আর Fetch Metadata: browser-এর সাক্ষ্য

Browser request-এর সঙ্গে কিছু header যোগ করে, যা পাতার JavaScript ইচ্ছামতো বদলাতে পারে না। একে forbidden request header বলে। Server এগুলোকে সাক্ষী হিসেবে ব্যবহার করতে পারে। তবে এই সুরক্ষা browser-এর জন্যই। curl-এর মতো tool এসব যা খুশি পাঠাতে পারে, কিন্তু সেখানে ভুক্তভোগীর cookie থাকে না, তাই CSRF-এর প্রশ্নও ওঠে না।

Fetch Metadata হলো Sec-Fetch- দিয়ে শুরু হওয়া একদল header. Sec-Fetch-Site: none মানে ব্যবহারকারী নিজে address bar বা bookmark থেকে এসেছেন। OWASP-এর বর্তমান cheat sheet বলে, শুধু আধুনিক browser-এর জন্য বানানো software-এ এর ওপর নির্ভর করা যায়। শর্ত দুটি: পুরো সাইট HTTPS, আর header না এলে Origin বা Referer-এ fallback বাধ্যতামূলক।

Origin মেলানোর সময় পুরো মান তুলনা করুন। শুধু “শুরুটা মিলেছে কি না” দেখলে shop.example.com.other.example.net-এর মতো নামও পাস করতে পারে। আপনার নিজের origin আসবে config থেকে। Proxy-র header-এ অন্ধ বিশ্বাস নয়।

এবার সব মিলিয়ে একটি খেলনা server. সে cookie, Sec-Fetch-Site, Origin আর token দেখে সিদ্ধান্ত নেয়। নয়টি পরিস্থিতি চালানো হলো।

// খেলনা server: কোনো real request নয়, সব ডেটা memory-তে
const ME = "https://shop.example.com";
const SESSIONS = { "sid-rahima": { user: "rahima", csrf: "tok-a1" } };
const SAFE = ["GET", "HEAD", "OPTIONS"];

function decide(r) {
  if (SAFE.includes(r.method)) return "ALLOW safe method, no change";
  const s = SESSIONS[r.cookie];
  if (!s) return "DENY 401 no session";
  if (r.site) {                                // Fetch Metadata
    if (r.site !== "same-origin" && r.site !== "none")
      return "DENY 403 Sec-Fetch-Site=" + r.site;
  } else if (r.origin !== ME) {                // পুরোনো browser: fallback
    return "DENY 403 Origin=" + (r.origin || "missing");
  }
  if (r.token !== s.csrf) return "DENY 403 bad token"; // real কোডে constant-time
  return "ALLOW change as " + s.user;
}

const C = "sid-rahima", P = "POST";
const cases = [
  ["own form",         { method: P, cookie: C, site: "same-origin", token: "tok-a1" }],
  ["page view",        { method: "GET", cookie: C, site: "cross-site" }],
  ["no login",         { method: P, site: "same-origin", token: "tok-a1" }],
  ["other site",       { method: P, cookie: C, site: "cross-site" }],
  ["sibling subdomain",{ method: P, cookie: C, site: "same-site" }],
  ["old browser",      { method: P, cookie: C, origin: "https://other.example.net" }],
  ["no headers",       { method: P, cookie: C, token: "tok-a1" }],
  ["own page, no tok", { method: P, cookie: C, site: "same-origin" }],
  ["XSS on own page",  { method: P, cookie: C, site: "same-origin", token: "tok-a1" }],
];
for (const [name, req] of cases) console.log(name.padEnd(18), decide(req));

এবার একই যুক্তি একটি cross-site request-এর ওপর ধাপে ধাপে দেখুন। সব স্তর দেখাতে ধরে নিচ্ছি cookie-টি SameSite=None, তাই cookie পৌঁছেছে। Lax হলে শুরুতেই cookie বাদ পড়ত।

API আর custom header

AJAX বা API-তে form নেই। তাই token যায় X-CSRF-Token ধরনের custom header-এ। Cross-origin পাতা custom header পাঠাতে চাইলে browser আগে একটি preflight (OPTIONS) পাঠিয়ে অনুমতি চায়। Server অনুমতি না দিলে আসল request যায় না। মান খালি হলেও কিছুটা কাজ দেয়, কিন্তু সেটি এই একটি শর্তের ওপরই দাঁড়িয়ে। তাই token-সহ header ভালো। API-র বিস্তারিত পর্ব ৪৩-এ।

৬ · যেখানে প্রতিরক্ষা ভাঙে: XSS, CORS আর subdomain

XSS থাকলে CSRF প্রতিরক্ষা শেষ

OWASP-এর সতর্কবার্তা সরাসরি: XSS সব CSRF প্রতিরক্ষা হারাতে পারে। CSRF প্রতিরক্ষার ভিত্তি হলো “অন্য site আপনার পাতার ভেতরটা পড়তে পারে না”। XSS মানে আক্রমণকারীর script আপনার origin-এর ভেতরেই চলছে। সে পাতা থেকে token পড়তে পারে, same-origin request পাঠাতে পারে। Browser-এর সাক্ষ্যও বলবে same-origin, কারণ সেটি সত্য। তাই আগে XSS বন্ধ করুন (পর্ব ৪০)। HttpOnly শুধু cookie পড়া আটকায়, cookie-র ব্যবহার আটকায় না।

CORS CSRF প্রতিরক্ষা নয়

CORS নিয়ে সবচেয়ে প্রচলিত ভুল ধারণা এটি। CORS ঠিক করে অন্য origin-এর পাতা উত্তর পড়তে পারবে কি না। সে request পাঠানো সবসময় থামায় না। সাধারণ form-ধরনের POST-এ preflight হয়ই না, request server-এ পৌঁছে কাজও হয়ে যেতে পারে। Browser শুধু উত্তরটি পাতাকে দেখায় না। CSRF-এ উত্তরের দরকার নেই।

উল্টো ঢিলা CORS ক্ষতি বাড়ায়। Credential-সহ যেকোনো origin ফিরিয়ে দিলে অন্য site token-ও পড়তে পারে, preflight-ও পার হয়। তাই শুধু নির্দিষ্ট, নিজের origin-এর তালিকা রাখুন। JSON API-তে Content-Type: application/json বাধ্য করুন, ঢিলা parser সরিয়ে দিন। না হলে preflight ছাড়া যে content type যায়, সেগুলো JSON হিসেবে পড়া হতে পারে। CORS-এর ভিত্তি পর্ব ৩৬-এ।

Token-ভিত্তিক API বনাম cookie

কোন পরিচয়-ব্যবস্থা CSRF-এর ঝুঁকিতে পড়ে? উত্তর একটি প্রশ্নে: browser কি পরিচয়টি নিজে থেকে পাঠায়?

লক্ষ করুন তৃতীয় সারি। “JWT ব্যবহার করি, তাই CSRF নেই” ভুল। CSRF token-এর ধরনে নয়, পরিবহনে। কোথায় token রাখবেন, সেই আলোচনা পর্ব ১৭-এ।

Cookie prefix আর scoping

Cookie যত কম জায়গায় যায়, ঝুঁকি তত কম। Cookie prefix নামের ভেতরেই নিয়ম বসায়, আর browser সেটি মানে।

একটি ভালো শুরু, শুধু আপনার নিজের app-এর জন্য:

Set-Cookie: __Host-sid=example-token; Path=/; Secure; HttpOnly; SameSite=Lax

MDN এখন __Http- আর __Host-Http- prefix-ও তালিকায় রেখেছে। এগুলো নতুন, সমর্থন ভিন্ন হতে পারে। আর পুরোনো browser prefix না বুঝলে নিয়ম ছাড়াই cookie নিয়ে নেয়, তাই prefix বাড়তি স্তর, একমাত্র ভরসা নয়।

Subdomain মানেই বিশ্বাসের সীমা

একই registrable domain-এর যেকোনো subdomain সাধারণত parent domain-এ cookie বসাতে পারে। একে cookie injection বা cookie tossing বলে। একটি ভুলে যাওয়া marketing পাতা, একটি পুরোনো test server, বা subdomain takeover-এর শিকার কোনো নাম তখন মূল app-এর দুর্বলতা হয়ে ওঠে। Django-র ডকুমেন্টেশনও সরাসরি বলে, parent domain-এ cookie বসাতে পারে এমন subdomain তার CSRF সুরক্ষা পাশ কাটাতে পারে।

• ব্যবহারকারীর লেখা HTML বা অন্যের কোড চললে সেটি আলাদা registrable domain-এ রাখুন।
• অচল DNS record নিয়মিত সরান (পর্ব ২৬)।
• Session আর CSRF cookie-তে __Host- ব্যবহার করুন।
• Token-কে session-এর সঙ্গে বাঁধুন, যাতে বসানো মান কাজে না লাগে।

৭ · Clickjacking: ক্লিক আপনার, লক্ষ্য অন্যের

Clickjacking-এ request জাল করা হয় না। ব্যবহারকারী নিজেই আসল পাতায় আসল ক্লিক করেন, শুধু জানেন না কোথায় করছেন। অন্য একটি পাতা আপনার পাতাকে iframe-এ লুকিয়ে রাখে আর ওপরে একটি ভিন্ন ছবি দেখায়। Token এখানে কোনো কাজ করে না, কারণ ক্লিক আসল পাতা থেকেই হচ্ছে।

প্রতিরক্ষা সহজ: পাতাটি জানিয়ে দেবে কে তাকে ফ্রেমে রাখতে পারবে। Content Security Policy-র frame-ancestors এই কাজ করে। পুরোনো পথ হলো X-Frame-Options.

# নিজের server-এর জন্য উদাহরণ: শুধু নিজের site ফ্রেম করতে পারবে
add_header Content-Security-Policy "frame-ancestors 'self'" always;
add_header X-Frame-Options "SAMEORIGIN" always;

দুটি header একসঙ্গে থাকলে CSP-র নিয়মে frame-ancestors জেতে, X-Frame-Options উপেক্ষিত হয়। আর frame-ancestors HTTP header হিসেবেই পাঠাতে হবে, <meta> tag-এ এটি কাজ করে না। JavaScript দিয়ে ফ্রেম ভাঙার পুরোনো কৌশল, যাকে frame busting বলে, নির্ভরযোগ্য নয়।

ব্যবহারকারী লগইন আছেন: shop.example.com
খোলা পাতা: other.example.net
লক্ষ্য: তাঁর ক্লিক অন্য পাতায় ফেলা

GET /settings HTTP/1.1
Host: shop.example.com
Sec-Fetch-Dest: iframe
Sec-Fetch-Site: cross-site

HTTP/1.1 200 OK
Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

অনুমোদিত : https://shop.example.com
ancestor  : https://other.example.net
তালিকায় নেই

ফ্রেমে shop-এর পাতা আসেনি
ক্লিক করার মতো কিছু নেই
settings অপরিবর্তিত

নিচের খেলনা ফাংশনটি browser-এর এই সিদ্ধান্ত সরলভাবে অনুকরণ করে। chain মানে বাইরের সব পাতার origin.

// খেলনা framing নীতি: browser-এর সিদ্ধান্তের সরল রূপ
const ME = "https://shop.example.com", PARTNER = "https://partner.example.org";
const OTHER = "https://other.example.net";

function mayFrame(h, chain) {               // chain = বাইরের সব page
  if (h.csp) {                              // CSP থাকলে XFO উপেক্ষিত
    if (h.csp.includes("'none'")) return "BLOCK (csp none)";
    const list = h.csp.map(s => (s === "'self'" ? ME : s));
    return chain.every(a => list.includes(a)) ? "ALLOW (csp)" : "BLOCK (csp)";
  }
  if (h.xfo === "DENY") return "BLOCK (xfo)";
  if (h.xfo === "SAMEORIGIN")
    return chain.every(a => a === ME) ? "ALLOW (xfo)" : "BLOCK (xfo)";
  return "ALLOW (no valid policy)";
}

const tests = [
  ["no header",        {},                               [OTHER]],
  ["XFO DENY, self",   { xfo: "DENY" },                  [ME]],
  ["XFO SAMEORIGIN",   { xfo: "SAMEORIGIN" },            [ME]],
  ["XFO ALLOW-FROM",   { xfo: "ALLOW-FROM " + PARTNER }, [OTHER]],
  ["csp none",         { csp: ["'none'"] },              [ME]],
  ["csp self+partner", { csp: ["'self'", PARTNER] },     [PARTNER]],
  ["same, other site", { csp: ["'self'", PARTNER] },     [OTHER]],
  ["double framing",   { csp: ["'self'"] },              [ME, OTHER]],
  ["csp beats xfo",    { csp: ["'self'"], xfo: "DENY" }, [ME]],
];
for (const [name, headers, chain] of tests)
  console.log(name.padEnd(18), mayFrame(headers, chain));

SameSite=Lax বা Strict এখানেও সাহায্য করে। Cross-site iframe-এ cookie না গেলে পাতা লগইন-করা অবস্থায় আসে না। তবে পাশের subdomain ফ্রেম করতে পারে, আর login ছাড়াই যে কাজ হয় সেখানে এটি কিছু করে না। তাই header-ই মূল প্রতিরক্ষা।

UI confirmation আর re-authentication

“আপনি কি নিশ্চিত?” বাক্সটি ভুল ক্লিক থামায়। কিন্তু এটি নিরাপত্তার সীমা নয়। একই পাতা ফ্রেমে থাকলে দ্বিতীয় ক্লিকও ফাঁদে ফেলা যায়, আর XSS হলে script নিজেই সেটি পার হতে পারে। ভালো confirmation-এ কী হচ্ছে তা স্পষ্ট লেখা থাকে: কত টাকা, কাকে, কোন account. Confirmation পাতাটিও ফ্রেমে আসতে পারবে না।

বড় কাজে এক ধাপ এগোন। Password বা email বদল, টাকা পাঠানো, payout বদল আর MFA সরানোর আগে re-authentication চান। মোবাইল ব্যাংকিংয়ে প্রতিবার PIN চাওয়া ঠিক এই কাজই করে। PIN cookie-র মতো নিজে থেকে যায় না, আর অন্য site সেটি জানে না। এজন্য CSRF, clickjacking, এমনকি অনেক ক্ষেত্রে XSS-এর ক্ষতিও কমে। Passkey হলে phishing-ও কঠিন হয় (পর্ব ১৬)। OWASP CSRF-এর জন্য CAPTCHA-র ওপর ভরসা না করতে বলে।

৮ · Framework, নিজের app পরীক্ষা আর detection

OWASP-এর প্রথম পরামর্শ হলো নিজে না বানিয়ে framework-এর ব্যবস্থা ব্যবহার করা। নিচের তথ্য লেখার সময়ের ডকুমেন্টেশন থেকে নেওয়া। Version-ভেদে বদলাতে পারে, তাই নিজের version-এর মূল পাতা দেখুন। এগুলো উদাহরণ, কোনো পণ্যের সুপারিশ নয়।

নিজের app পরীক্ষা

“Framework আছে” মানে “সুরক্ষিত” নয়। একটি route বাদ পড়তে পারে, একটি middleware বন্ধ থাকতে পারে। তাই নিজের staging পরিবেশে নিচের তালিকা ধরে যাচাই করুন। কাজটি শুধু নিজের app-এ, অথবা লিখিত অনুমতিতে। পদ্ধতিগত পরীক্ষা পর্ব ৪৯-এ, আর অনুমোদিত penetration test পর্ব ৫০-এ।

• সব state-changing route-এর তালিকা বানিয়েছি, কোনোটিই GET-এ নয়
• Token ছাড়া, ভুল token আর অন্য session-এর token: প্রতিটিতে 403 পেয়েছি
• ভিন্ন Origin আর ভিন্ন Sec-Fetch-Site সহ test request-এ 403 পেয়েছি
• DevTools-এ session cookie-র Secure, HttpOnly, SameSite দেখেছি
• Login, payment আর settings পাতায় frame-ancestors দেখেছি, আর ফ্রেমে আনা যায় না নিজের test পাতায় যাচাই করেছি
• CORS-এ নির্দিষ্ট origin ছাড়া কিছু নেই

স্বয়ংক্রিয় test-এ একটি ফাঁদ আছে। অনেক framework test-এ CSRF যাচাই নিজে থেকে বন্ধ রাখে। Django-র test client-এ সেটি স্পষ্ট করে চালু করতে হয়। নিচের উদাহরণে self.user setUp-এ তৈরি, আর /transfer/ আপনার নিজের route.

from django.test import Client, TestCase

class TransferCsrfTests(TestCase):
    def test_post_without_token_is_refused(self):
        client = Client(enforce_csrf_checks=True)
        client.force_login(self.user)
        resp = client.post("/transfer/", {"amount": "100"})
        self.assertEqual(resp.status_code, 403)

Detection আর সাড়া

CSRF ব্যর্থতা log করুন, তবে token বা cookie-র মান নয়। Route, user ID, Origin, Sec-Fetch-Site আর কারণ রাখুন। Deploy-এর পরে হঠাৎ অনেক ব্যর্থতা সাধারণত কোডের ভুল। একই route-এ অনেক user-এর, একই বাইরের origin থেকে ব্যর্থতা সন্দেহজনক। নিচের নিয়মটি একটি Sigma-ধরনের উদাহরণ, field-এর নাম আপনার নিজের log অনুযায়ী বদলাবেন। ধারণাটি পর্ব ৫৬-এ বিস্তারিত।

title: Cross-site request refused on a sensitive route
status: experimental
logsource:
  product: example-web-app
  category: application
detection:
  selection:
    event_action: csrf_denied
    fetch_site: cross-site
    route|startswith:
      - /transfer
      - /account/email
  condition: selection
level: medium

CSRF-এর একটি কঠিন দিক হলো, সফল হলে log-এ সব স্বাভাবিক দেখায়। বৈধ session, বৈধ route. তাই সংবেদনশীল কাজের পরে ব্যবহারকারীকে email বা SMS-এ জানান। অভিযোগ এলে Origin আর Sec-Fetch-Site log থেকে দেখা যাবে কাজটি কোথা থেকে শুরু। সাড়ার ধাপ: প্রতিরক্ষা-হীন route বন্ধ বা ঠিক করা, ক্ষতিগ্রস্ত account-এর বদল ফেরানো, session বাতিল, আর একই ধরনের route খোঁজা (পর্ব ৬১)।

৯ · AI-এর যুগে CSRF আর cookie যাচাই

AI-কে “এই CORS বা 403 error ঠিক করে দিন” বললে সে প্রায়ই error সরিয়ে দেয়, সমস্যা নয়। CSRF token-এর 403 দেখলে সবচেয়ে সহজ উত্তর হলো যাচাই বন্ধ করা। সেই কোড চলবে, আর আপনি দরজা খোলা রেখে দেবেন।

AI-এর পরামর্শ হাতে পেলে

• আসল token, cookie বা key prompt-এ দিইনি
• কোনো CSRF, CORS বা cookie যাচাই বন্ধ করার পরামর্শ মানিনি
• Diff পড়েছি, শুধু “এখন চলছে” দেখে merge করিনি
• নিজের test পরিবেশে token ছাড়া request-এ 403 দেখেছি
• নাম-উল্লেখ করা setting আর library মূল ডকুমেন্টেশনে খুঁজে পেয়েছি
• যে সিদ্ধান্ত ব্যবহারকারীর টাকা বা ডেটায় প্রভাব ফেলে, সেটি একজন মানুষ পর্যালোচনা করেছেন