নিরাপদ session ও cookie: HttpOnly, Secure, SameSite

HTTP স্টেটলেস: server request-এর মধ্যে আপনাকে মনে রাখে না। Login-এর পর অ্যাপ আপনার browser-কে একটি session identifier দেয়, সাধারণত cookie-তে, যা browser প্রতিটি request-এর সাথে পাঠায়। যে এই identifier ধরে রাখে তাকে আপনি ধরা হয়। তাই এটি সুরক্ষা করা পাসওয়ার্ড সুরক্ষার মতোই গুরুত্বপূর্ণ।

এটি নিরাপদে session ও cookie সেট করার প্রতিরক্ষামূলক নির্দেশিকা।

Session কীভাবে কাজ করে

১. আপনি বৈধ credential দিয়ে login করেন। ২. Server একটি session রেকর্ড (ব্যবহারকারী, তৈরির সময়, মেয়াদ) ও লম্বা, এলোমেলো session ID বানায়। ৩. Set-Cookie header-এ ID পাঠায়। ৪. Browser প্রতিটি request-এ cookie ফেরত পাঠায়, আর server session খুঁজে নেয়। ৫. Logout বা মেয়াদ শেষে server session ধ্বংস করে।

Set-Cookie: sid=9f3a...random...c21; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

Session ID নিজে

• ক্রিপ্টোগ্রাফিকভাবে নিরাপদ random generator দিয়ে যথেষ্ট entropy-সহ বানান (সাধারণ নির্দেশনায় অন্তত ১২৮ বিট)। counter, timestamp বা user ID-র মতো অনুমানযোগ্য মান কখনো নয়।
• এটিকে পাসওয়ার্ডের মতো দেখুন। URL-এ রাখবেন না (এগুলো log, ইতিহাস ও referrer header-এ যায়)।
• Session data server-এ (database বা Redis-এর মতো cache) রাখুন এবং cookie-তে শুধু ID রাখুন, বা পরিণত framework-এর দেওয়া সঠিকভাবে সুরক্ষিত, স্বাক্ষরিত ও এনক্রিপ্ট করা cookie session ব্যবহার করুন।
• নিজের বানানোর বদলে আপনার framework-এর বিল্ট-ইন session ব্যবস্থাপনা ব্যবহার করুন।

গুরুত্বপূর্ণ cookie attribute

Secure: browser cookie শুধু HTTPS-এ পাঠায়। production-এ সবসময় সেট করুন, যাতে সাধারণ HTTP সংযোগে প্রকাশ না পায়।

HttpOnly: JavaScript document.cookie দিয়ে cookie পড়তে পারে না। এটি cross-site scripting (XSS)-এর ক্ষতি সীমিত করে, কারণ ক্ষতিকর script সহজে session ID চুরি করতে পারে না। (XSS তবুও পেজের ভেতরে ব্যবহারকারী হিসেবে কাজ করতে পারে, তাই XSS-ও ঠিক করুন।)

SameSite: cross-site request-এ cookie যাবে কি না নিয়ন্ত্রণ করে, যা CSRF ঝুঁকি কমায়।

• Strict: শুধু same-site request-এ যায়। সবচেয়ে শক্ত, কিন্তু অন্য সাইটের লিংক cookie ছাড়া আসে, তাই প্রথম click-এ ব্যবহারকারী logout দেখতে পারে।
• Lax: same-site request এবং নিরাপদ method-সহ top-level navigation-এ (যেমন লিংকে click) যায়। ভালো ডিফল্ট, এবং নির্দিষ্ট না করলে বর্তমান প্রধান browser-এর ডিফল্ট।
• None: সব cross-site request-এ যায় এবং Secure লাগে। শুধু সত্যিই cross-site cookie দরকার হলে ব্যবহার করুন, যেমন embed করা তৃতীয় পক্ষের কনটেন্টে।

Domain ও Path: যতটা সম্ভব সংকীর্ণ রাখুন। Domain বাদ দিলে cookie হুবহু host-এ বাঁধা থাকে, subdomain-এ নয়।

Max-Age / Expires: আয়ুষ্কাল সীমিত করে (নিচে মেয়াদ দেখুন)। এগুলো ছাড়া এটি session cookie যা browser বন্ধে শেষ হয়, যদিও কিছু browser session ফিরিয়ে আনে।

Cookie prefix: __Host- (Secure, Path=/ এবং Domain ছাড়া লাগে) ও __Secure- কিছু overwrite আক্রমণের বিরুদ্ধে বাড়তি সুরক্ষা দেয়। যেমন: __Host-sid।

গুরুত্বপূর্ণ: SameSite CSRF-এ সাহায্য করে কিন্তু পূর্ণ প্রতিরক্ষা নয়। অবস্থা-বদলানো request-এ CSRF token বা সমতুল্য সুরক্ষা রাখুন।

Session fixation

Session fixation ঘটে যখন আক্রমণকারী শিকারকে এমন session ID ব্যবহার করায় যা আক্রমণকারী আগে থেকে জানে (যেমন login-এর আগে বসিয়ে দিয়ে)। Login-এর পরও অ্যাপ একই ID রাখলে আক্রমণকারী এখন শিকার হিসেবে logged in।

প্রতিরক্ষা: privilege স্তর বদলালেই নতুন session ID দিন, বিশেষত login-এ, এবং পাসওয়ার্ড বা role বদলেও। পুরোনো ID অকার্যকর করুন।

মেয়াদ ও logout

• Idle timeout: নিষ্ক্রিয়তার সময়ের পর session শেষ করুন (ব্যাংকিংয়ের মতো সংবেদনশীল অ্যাপে ছোট)।
• Absolute timeout: সক্রিয় থাকলেও সর্বোচ্চ আয়ুষ্কালের পর session শেষ করুন।
• "Remember me": আলাদা, দীর্ঘস্থায়ী, revoke করা যায় এমন token ব্যবহার করুন এবং সংবেদনশীল কাজে আবার authentication চান।
• Logout: server-এ session ধ্বংস করুন এবং cookie মুছুন। Server পুরোনো ID এখনো গ্রহণ করলে শুধু browser cookie মোছা যথেষ্ট নয়।
• পাসওয়ার্ড বদল বা reset: অন্য সব session অকার্যকর করুন।
• উপযুক্ত হলে ব্যবহারকারীকে অন্য device-এর সক্রিয় session দেখতে ও শেষ করতে দিন।

সংবেদনশীল কাজে পুনরায় authentication

Email বা পাসওয়ার্ড বদল, পেমেন্ট পদ্ধতি যোগ বা অ্যাকাউন্ট মোছার জন্য আবার পাসওয়ার্ড (বা দ্বিতীয় factor) চান। এটি ছিনতাই করা session কী করতে পারে তা সীমিত করে।

অপব্যবহার শনাক্ত ও সীমিত করা

• Session রেকর্ড কিছু প্রসঙ্গে বাঁধুন, তবে সাবধান: session কড়াভাবে IP ঠিকানায় বাঁধলে মোবাইল ব্যবহারকারীর ক্ষেত্রে ভাঙতে পারে। এটিকে কড়া নিয়মের বদলে ঝুঁকির সংকেত (alert বা step-up যাচাই) হিসেবে ব্যবহার করুন।
• Login, logout ও সন্দেহজনক বদল log করুন এবং অস্বাভাবিক ধরনে alert দিন।
• Authentication endpoint-এ rate limit দিন।
• চুরি যাওয়া পাসওয়ার্ড যথেষ্ট না করতে multi-factor authentication ব্যবহার করুন।

Browser-এ server-side session বনাম JWT

অনেক tutorial localStorage-এ JWT রাখে। এর নিরাপত্তা-সংক্রান্ত লাভ-ক্ষতি আছে:

• localStorage-এর সবকিছু আপনার পেজের যেকোনো script পড়তে পারে, তাই XSS bug তা চুরি করতে পারে।
• Stateless JWT মেয়াদের আগে revoke করা কঠিন।

সাধারণ ওয়েব অ্যাপে server-side session বা HttpOnly Secure SameSite cookie সাধারণত নিরাপদ ডিফল্ট। JWT ব্যবহার করলে স্বল্পস্থায়ী রাখুন, refresh token সাবধানে (HttpOnly cookie-তে) সংরক্ষণ করুন, প্রতিটি claim যাচাই করুন এবং revocation পরিকল্পনা রাখুন।

Session সমর্থনকারী অন্যান্য সুরক্ষা

• সর্বত্র HTTPS, সাথে Strict-Transport-Security header।
• XSS কমাতে শক্ত Content Security Policy ও output encoding।
• অবস্থা-বদলানো request-এ Anti-CSRF token।
• Client পড়তে বা সম্পাদনা করতে পারে এমন cookie-তে সংবেদনশীল তথ্য রাখবেন না। Cookie-তে data রাখতেই হলে স্বাক্ষর ও এনক্রিপ্ট করুন।
• Framework ও তার session library হালনাগাদ রাখুন।

দ্রুত checklist

১. নিরাপদ generator থেকে এলোমেলো, লম্বা session ID। ২. Cookie flag: Secure, HttpOnly, SameSite=Lax (বা Strict), সংকীর্ণ scope, সম্ভব হলে __Host- prefix। ৩. Login ও privilege বদলে নতুন session ID। ৪. Idle ও absolute timeout এবং server-side logout। ৫. পাসওয়ার্ড বদলের পর session অকার্যকর। ৬. সংবেদনশীল কাজে পুনরায় authentication। ৭. Cookie flag-এর পাশাপাশি CSRF সুরক্ষা ও XSS প্রতিরক্ষা। ৮. Session ID কখনো URL বা log-এ নয়।

নিজের সাইট পরীক্ষা করুন

Browser developer tools-এ (Application বা Storage ট্যাব) আপনার cookie দেখে flag যাচাই করুন। এছাড়া logout-এর পর পুরোনো session ID আর কাজ করে না নিশ্চিত করুন। শুধু নিজের বা পরীক্ষার অনুমতি থাকা অ্যাপ্লিকেশন পরীক্ষা করুন।

মূল কথা: session cookie-কে পাসওয়ার্ডের মতো দেখুন। এলোমেলো ID ব্যবহার করুন, Secure, HttpOnly ও SameSite সেট করুন, login-এ ID বদলান, server-এ session মেয়াদ শেষ ও ধ্বংস করুন, এবং CSRF ও XSS সুরক্ষার সাথে মেলান।

---

ওয়েব নিরাপত্তা সিরিজ, পর্ব ৩ (অ্যাকাউন্ট ও প্রতিরক্ষা): 3 নম্বর (মোট 5)। আগের লেখা: OAuth 2.0 ও OpenID Connect সহজ ভাষায় এবং নিরাপদ বাস্তবায়ন.