CSRF: কীভাবে কাজ করে ও কীভাবে ঠেকাবেন
Browser স্বয়ংক্রিয়ভাবে cookie পাঠায়, আর আক্রমণকারীরা তা অপব্যবহার করে। CSRF কীভাবে কাজ করে এবং আধুনিক প্রতিরক্ষা জানুন।
Cross-site request forgery (CSRF) logged-in user-এর browser-কে ভুলিয়ে এমন সাইটে অনাকাঙ্ক্ষিত request পাঠায়, যেখানে সে authenticated। সাইট আসল কাজ থেকে এটি আলাদা করতে পারে না, কারণ browser স্বয়ংক্রিয়ভাবে cookie পাঠায়।
আক্রমণ কীভাবে চলে
- আপনি
bank.example-এ login করেন। Browser একটি session cookie রাখে। - অন্য tab-এ
evil.exampleখোলেন, যেখানে একটি লুকানো ফর্ম আক্রমণকারীর অ্যাকাউন্টকে লক্ষ্য করেbank.example/transfer-এ জমা দেয়। - আপনার browser আপনার cookie সহ request পাঠায়। ব্যাংক বৈধ session দেখে এবং প্রক্রিয়া করে।
আক্রমণকারী response দেখে না ও cookie চুরি করে না। সে শুধু একটি কাজ ঘটায় (ইমেইল বদল, টাকা পাঠানো, পাসওয়ার্ড বদল, data মোছা)।
কেন কাজ করে
- কোন পেজ request শুরু করেছে তা নির্বিশেষে cookie তার সাইটের request-এ পাঠানো হয়।
- কে ডাকছে জানতে server শুধু cookie-র ওপর নির্ভর করে।
প্রতিরক্ষা
১. SameSite cookie। Session cookie-তে SameSite=Lax (বা Strict) দিন। তখন browser cross-site POST request-এ তা পাঠায় না। আধুনিক browser attribute না থাকলে Lax-কে ডিফল্ট ধরে, তবুও স্পষ্টভাবে দিন। শুধু এটিই বেশিরভাগ ক্লাসিক CSRF আটকায়।
২. CSRF token। প্রতিটি session (বা ফর্ম)-কে random, অনুমান-অযোগ্য token দিন। প্রতিটি state-বদলানো request-এ (লুকানো ফর্ম ফিল্ড বা header) তা দিন। বৈধ token ছাড়া server প্রত্যাখ্যান করে। অন্য সাইটের আক্রমণকারী তা পড়তে পারে না।
৩. Origin / Referer header যাচাই। State-বদলানো request-এ যাচাই করুন সেটি আপনার নিজের origin থেকে এসেছে।
৪. API-র জন্য custom header। X-Requested-With-এর মতো header বা bearer token আবশ্যিক করুন। Cross-site ফর্ম custom header দিতে পারে না, আর custom header-সহ cross-origin fetch-এ CORS অনুমোদন লাগে।
৫. GET দিয়ে কখনো state বদলাবেন না। লিংক ও ছবি GET request ঘটাতে পারে। বদলের জন্য POST, PUT বা DELETE ব্যবহার করুন।
৬. গুরুত্বপূর্ণ কাজে আবার authenticate। ইমেইল, পাসওয়ার্ড বা payment তথ্য বদলের আগে পাসওয়ার্ড বা এককালীন কোড চান।
যা সাহায্য করে না
- শুধু user logged in কি না যাচাই।
- Session cookie JavaScript থেকে গোপন রাখা (HttpOnly): XSS-এর বিরুদ্ধে কাজের, CSRF-এর নয়।
- GET-এর বদলে শুধু POST ব্যবহার। ফর্ম cross-site POST করতে পারে।
- গোপন URL।
Authorization header ব্যবহারকারী API
আপনার API cookie নয়, JavaScript-যোগ করা Authorization header-এর token ব্যবহার করলে browser তা স্বয়ংক্রিয়ভাবে যোগ করে না, তাই ক্লাসিক CSRF প্রযোজ্য নয়। কিন্তু এমন token script-এর নাগালে কোথাও রাখলে XSS বড় ঝুঁকি হয়।
CSRF ও XSS
সাইটে XSS থাকলে আক্রমণকারী CSRF token পড়ে তা এড়াতে পারে। আগে XSS ঠিক করুন।
মূল কথা: SameSite cookie দিন, প্রতিটি state-বদলানো request-এ CSRF token (বা Origin যাচাই) যোগ করুন, GET দিয়ে state বদলাবেন না, এবং সংবেদনশীল কাজে আবার authenticate করান।
ওয়েব সিকিউরিটি সিরিজ, পর্ব ১ (injection ও access control): 3 নম্বর (মোট 4)। আগের লেখা: Cross-site scripting (XSS): ধরন, প্রভাব ও প্রতিরোধ.
