পাঠ্যক্রম খুলুন
অগ্রসর পর্যায়

Session, Cookie ও JWT: login state ও CSRF

Sessions, Cookies, JWT, and CSRF

এই পাঠের কুইজ ↓৫ মিনিট পড়াPHP 8.3+ · Laravel 12
এই পাঠের সূচিপত্র

এই পাঠে যা শিখবেন

  • Session cookie ও bearer token-এর trade-off বোঝা
  • Login-এ session regeneration করা
  • CSRF ও XSS-এর আলাদা ভূমিকা বোঝা

সমস্যা দিয়ে শুরু

একটি dashboard login-এর পরে পুরোনো session ID রেখেছে। অন্য API JWT local storage-এ রেখে মনে করছে CSRF আর XSS দুটোই শেষ। দুই নকশাতেই threat model অসম্পূর্ণ। Browser কোন credential নিজে পাঠায়, JavaScript কোনটি পড়তে পারে এবং logout কীভাবে কার্যকর হয়—এই প্রশ্নগুলো দিয়ে session design শুরু করতে হবে। Token format বেছে নেওয়া একা security design নয়।

সহজ করে বুঝি

Session cookie সাধারণত opaque identifier; server session store থেকে state পড়ে। JWT signed claims বহন করে; signature integrity দেয়, confidentiality নয়। Browser cookie স্বয়ংক্রিয়ভাবে পাঠাতে পারে, তাই state-changing cookie-authenticated request-এ CSRF defense দরকার। HttpOnly cookie JavaScript পড়া কমায়; XSS থাকলে attacker user-এর context-এ action করতেও পারে। Secure, SameSite, expiry এবং session invalidation একসঙ্গে বিবেচনা করুন।

পরিচিত একটি উপমা

Session হলো cloakroom-এর token: আসল তথ্য counter-এ থাকে। Signed JWT হলো যাচাইযোগ্য লেখা pass; লেখা দেখা যেতে পারে, শুধু বদলালে ধরা পড়ে। Pass চুরি হলে expiry বা revocation ব্যবস্থা না থাকা পর্যন্ত অপব্যবহার সম্ভব।

নকশাটি দেখুন

Diagram লোড হচ্ছে…

Session বা JWT যাই নিন, credential theft, CSRF, expiry ও revocation-এর সম্পূর্ণ lifecycle design করুন।
Diagram-এর text flow দেখুন
flowchart TD
 B[Browser] --> L[Login and rotate session]
 L --> S[(Shared session store)]
 B --> C[Cookie and CSRF token]
 C --> M[Web middleware]
 M --> P[Policy and action]

Login credential যাচাই করে নতুন session identifier দেয়। পরের request cookie বহন করে; state-changing request CSRF check পেরোয়। Middleware identity স্থাপন করার পরে policy resource action নিয়ন্ত্রণ করে। Multiple replica হলে shared session store দরকার হতে পারে। Logout-এ server session invalidate এবং CSRF token regenerate করুন।

PHP ও Laravel-এ প্রয়োগ

Login controller-এর method-body fragment। $request validated LoginRequest, failed attempt limiter configured, HTTPS enabled ধরে নেওয়া হয়েছে। Example validation failure generic message দেয়, account existence প্রকাশ করে না। web middleware group-এর CSRF protection বাদ দেবেন না।

php
use Illuminate\Support\Facades\Auth;
use Illuminate\Validation\ValidationException;
if (! Auth::attempt($request->only('email', 'password'))) {
    throw ValidationException::withMessages([
        'email' => 'পরিচয় যাচাই করা যায়নি।',
    ]);
}
$request->session()->regenerate();
return redirect()->intended('/account');

সুবিধা, সীমাবদ্ধতা ও trade-off

Server sessions central revocation সহজ করে কিন্তু shared store dependency যোগ করে। Self-contained token কিছু service verification সহজ করে, কিন্তু immediate revocation, key rotation ও stale claims জটিল হয়। Short expiry stolen token-এর window কমায়; refresh token storage ও rotation আবার আলাদা design। JWT ব্যবহার করলেই system সম্পূর্ণ stateless হয় না।

সাধারণ ভুল

  • JWT payload encrypted ধরে secret রাখা।
  • Cookie-authenticated JSON API বলে CSRF বাদ দেওয়া।
  • Login-এর পরে session ID না বদলানো।

আরও একটু গভীরে

CSRF attacker-এর site থেকে browser credential ব্যবহার করে unwanted request করায়; XSS নিজের origin-এ malicious script চালায়। Defense দুটির উদ্দেশ্য আলাদা। Laravel Sanctum first-party SPA-তে cookie-based authentication সমর্থন করে; সব frontend-এর জন্য custom JWT দরকার নেই। Deployment-এর পরে cookie domain, trusted proxy, HTTPS detection ও session driver পরীক্ষা করুন। Sensitive operation-এ recent password confirmation যুক্ত করা যায়।

মনে রাখুন

Session বা JWT যাই নিন, credential theft, CSRF, expiry ও revocation-এর সম্পূর্ণ lifecycle design করুন।

নিজে চেষ্টা করুন

Login এবং logout-এর feature test লিখুন। Session ID rotation এবং unauthenticated action rejection যাচাই করুন। Browser developer tools-এ cookie flags দেখুন; JWT decode করে payload confidential কি না নিজের ভাষায় ব্যাখ্যা করুন।

নিজের বোঝা যাচাই করুন

1. JWT signature কি encryption?

না। Signature পরিবর্তন ধরা ও issuer verify করতে সাহায্য করে; payload সাধারণত পড়া যায়। Secret সেখানে দেবেন না।

2. HttpOnly কি XSS সমাধান?

Cookie পড়া ঠেকাতে সাহায্য করে, কিন্তু malicious same-origin action সব বন্ধ করে না। Output escaping ও CSPসহ defense দরকার।

3. Login-এ regenerate কেন?

Session fixation risk কমাতে identifier বদলায়। Logout-এ invalidate ও token regeneration আলাদা ধাপ।

4. CSRF কোথায় প্রাসঙ্গিক?

Browser স্বয়ংক্রিয়ভাবে পাঠানো credential-সহ state-changing request-এ। Transport JSON হলেই ঝুঁকি দূর হয় না।

5. Logout JWT বাতিল করে?

Client copy মুছলেই stolen copy বাতিল হয় না। Expiry, revocation বা token version strategy নির্ধারণ করতে হবে।

আরও পড়ুন

এই পাঠের কুইজ

এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।

এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।

জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।

সব বিষয় মিলিয়ে অনুশীলন করুন →

অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।