CSRF Exploitation: ব্যবহারকারীর অজান্তে তার অ্যাকাউন্ট দিয়ে অননুমোদিত কাজ করানো!

CSRF হলো এমন একটি আক্রমণ যেখানে আক্রমণকারী ভিকটিমের ব্রাউজারকে এমন একটি অনুরোধ পাঠাতে বাধ্য করেন যেটি ভিকটিম পাঠাতে চাননি। এই আক্রমণের মূল ভিত্তি হলো ব্রাউজারের একটি বৈশিষ্ট্য - যখন ব্রাউজার কোনো ডোমেইনে রিকোয়েস্ট পাঠায়, তখন সেই ডোমেইনের জন্য সংরক্ষিত সমস্ত কুকি স্বয়ংক্রিয়ভাবে যুক্ত হয়। এই Ambient Authority বা পার্শ্ব অথোরিটিই CSRF-এর মূল কারণ।

আক্রমণের প্রক্রিয়াটি সহজভাবে ব্যাখ্যা করা যায়। প্রথমে ভিকটিম একটি ওয়েবসাইটে লগইন করেন এবং সেশন কুকি গ্রহণ করেন। তারপর তিনি একটি ম্যালিশাস ওয়েবসাইটে প্রবেশ করেন যা তাকে অন্য কোনো প্রলোভনে আকৃষ্ট করেছে। সেই সাইটে এমন HTML বা JavaScript থাকে যা গোপনে টার্গেট সাইটে একটি অনুরোধ পাঠায়। ব্রাউজার বৈধ সেশন কুকি সহকারে অনুরোধটি পাঠায় এবং সার্ভার এটিকে ভিকটিমের বৈধ অনুরোধ হিসেবে প্রক্রিয়া করে।

CSRF থেকে XSS-এর পার্থক্য বুঝতে হবে। XSS-এ আক্রমণকারী টার্গেট সাইটে কোড সম্পাদন করেন যা সেশন কুকি চুরি করতে পারে। CSRF-এ আক্রমণকারী টার্গেট সাইটে কোড সম্পাদন করতে পারেন না কিন্তু ভিকটিমের ব্রাউজারের মাধ্যমে অনুরোধ পাঠাতে পারেন। CSRF-এর মাধ্যমে আক্রমণকারী রেসপন্স পড়তে পারেন না কারণ Same-Origin Policy এতে বাধা দেয়, কিন্তু রাষ্ট্র পরিবর্তনকারী অপারেশন (state-changing operation) সম্পাদন করতে পারেন।

CSRF-এর সবচেয়ে বিপজ্জনক প্রভাব হলো অননুমোদিত অর্থ লেনদেন, পাসওয়ার্ড পরিবর্তন, ইমেইল ঠিকানা পরিবর্তন, প্রশাসনিক ক্রিয়াকলাপ সম্পাদন এবং অ্যাকাউন্ট সম্পূর্ণ দখল করা। ২০০৮ সালে Gmail-এ একটি CSRF দুর্বলতা পাওয়া গিয়েছিল যা আক্রমণকারীকে ভিকটিমের সমস্ত ইমেইল একটি বাহ্যিক ঠিকানায় ফরোয়ার্ড করার অনুমতি দিত।

প্রাথমিক CSRF আক্রমণ সাধারণত একটি স্বয়ংক্রিয়ভাবে সাবমিট হওয়া HTML ফর্মের মাধ্যমে সম্পন্ন হয়। আক্রমণকারী একটি ম্যালিশাস পেজে একটি hidden form স্থাপন করেন যা পেজ লোড হওয়ার সাথে সাথে JavaScript দ্বারা সাবমিট হয়ে যায়। যদি টার্গেট সাইট GET রিকোয়েস্টের মাধ্যমে রাষ্ট্র পরিবর্তন করে, তাহলে শুধুমাত্র একটি image ট্যাগ ব্যবহার করেই আক্রমণ সম্ভব।

আধুনিক ওয়েব অ্যাপ্লিকেশনে JSON রিকোয়েস্ট এবং REST API ব্যাপকভাবে ব্যবহৃত হয়। অনেক ডেভেলপার মনে করেন যে JSON রিকোয়েস্ট CSRF থেকে স্বয়ংক্রিয়ভাবে সুরক্ষিত কারণ HTML ফর্ম দিয়ে JSON পাঠানো যায় না। এটি একটি বিপজ্জনক ভুল ধারণা। যদি সার্ভার Content-Type যাচাই না করে, তাহলে text/plain Content-Type ব্যবহার করে JSON ডেটা পাঠানো সম্ভব। এছাড়া fetch API ব্যবহার করেও CORS অনুমতি থাকলে JSON রিকোয়েস্ট পাঠানো যায়।

XHR Pre-flight Bypass একটি উন্নত কৌশল। যদি লক্ষ্য endpoint Simple Request-এর শর্ত পূরণ করে - অর্থাৎ GET, POST বা HEAD মেথড এবং সীমিত হেডার - তাহলে ব্রাউজার preflight OPTIONS রিকোয়েস্ট পাঠায় না। এই ক্ষেত্রে CSRF আক্রমণ সরাসরি কার্যকর হতে পারে।

Login CSRF একটি বিশেষ ধরনের আক্রমণ যেখানে আক্রমণকারী ভিকটিমকে তার নিজস্ব অ্যাকাউন্টে লগইন করিয়ে দেন। উদাহরণস্বরূপ, ভিকটিম যদি অজান্তে আক্রমণকারীর Google অ্যাকাউন্টে লগইন হয়ে যান এবং কোনো ডকুমেন্ট সেভ করেন বা ব্রাউজিং হিস্টরি তৈরি করেন, তাহলে আক্রমণকারী পরবর্তীতে সেই তথ্য দেখতে পাবেন। ২০০৮ সালের Yahoo এবং Google-এ এই ধরনের দুর্বলতা পাওয়া গিয়েছিল।

CSRF Token Bypass কৌশলও অনেক রকম। প্রথম পদ্ধতি হলো Token Validation Bypass যেখানে সার্ভার শুধু token-এর উপস্থিতি যাচাই করে কিন্তু মান যাচাই করে না। দ্বিতীয় পদ্ধতি হলো Token Reuse যেখানে একই টোকেন একাধিক সেশনে ব্যবহারযোগ্য। তৃতীয় পদ্ধতি হলো Subdomain Cookie Setting যেখানে আক্রমণকারী একটি কম্প্রোমাইজড সাবডোমেইন থেকে কুকি সেট করে token-এর জায়গায় বসিয়ে দেন।

২০১৬ সালে SameSite cookie attribute চালু হওয়ার পর CSRF-এর বিরুদ্ধে একটি শক্তিশালী ব্রাউজার-স্তরের প্রতিরক্ষা পাওয়া গেছে। SameSite-এর তিনটি মান রয়েছে: Strict, Lax এবং None। Strict মানে কোনো cross-site context-এ cookie পাঠানো হবে না। Lax মানে শুধুমাত্র top-level navigation-এর GET রিকোয়েস্টে cookie পাঠানো হবে। None মানে সব cross-site রিকোয়েস্টে cookie পাঠানো হবে কিন্তু Secure attribute অবশ্যই থাকতে হবে।

Chrome ২০২০ সাল থেকে SameSite=Lax-কে ডিফল্ট হিসেবে ব্যবহার করছে যা অনেক ক্ষেত্রে CSRF আক্রমণকে অকার্যকর করে দিয়েছে। তবে এটি সম্পূর্ণ সমাধান নয়। GET-ভিত্তিক রাষ্ট্র পরিবর্তনকারী endpoint, ১২০ সেকেন্ডের লেক্সিকাল window-এ POST রিকোয়েস্ট, এবং SameSite=None কনফিগারেশন - এই সব ক্ষেত্রে এখনও CSRF সম্ভব।

ব্রাউজারের আরেকটি গুরুত্বপূর্ণ সুরক্ষা হলো Origin এবং Referer হেডার। যখন কোনো রিকোয়েস্ট পাঠানো হয়, ব্রাউজার সাধারণত Origin বা Referer হেডারে রিকোয়েস্টের উৎস উল্লেখ করে। সার্ভার এই হেডার যাচাই করে cross-origin রিকোয়েস্ট প্রত্যাখ্যান করতে পারে। তবে কিছু পুরনো ব্রাউজার বা গোপনীয়তা-বর্ধিত মোডে এই হেডার অনুপস্থিত থাকতে পারে যা একটি জটিলতা তৈরি করে।

CSRF প্রতিরোধের সবচেয়ে শক্তিশালী এবং সর্বজনীন পদ্ধতি হলো Anti-CSRF Token। এই পদ্ধতিতে সার্ভার প্রতিটি সেশনের জন্য একটি ক্রিপ্টোগ্রাফিকভাবে র‍্যান্ডম টোকেন তৈরি করে এবং প্রতিটি রাষ্ট্র পরিবর্তনকারী রিকোয়েস্টে সেটি অন্তর্ভুক্ত করার দাবি করে। আক্রমণকারী যেহেতু রেসপন্স পড়তে পারেন না, তাই তিনি বৈধ টোকেন জানতে পারেন না এবং অনুরোধ পাঠাতে পারেন না।

Synchronizer Token Pattern হলো সর্বাধিক ব্যবহৃত পদ্ধতি। প্রতিটি ফর্মে একটি hidden field হিসেবে টোকেন থাকে এবং সার্ভার সেশনে সংরক্ষিত টোকেনের সাথে মিলিয়ে দেখে। এই পদ্ধতির সঠিক বাস্তবায়নের জন্য টোকেন অবশ্যই ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী র‍্যান্ডম জেনারেটর দ্বারা তৈরি হতে হবে। কমপক্ষে ১২৮ বিট এনট্রপি প্রয়োজন।

Double Submit Cookie একটি স্টেটলেস বিকল্প। এখানে টোকেন একই সাথে কুকিতে এবং রিকোয়েস্ট পেলোডে পাঠানো হয়। সার্ভার দুটি মান মিলিয়ে দেখে। যেহেতু আক্রমণকারী cross-origin context-এ কুকি পড়তে পারেন না, তাই তিনি সঠিক টোকেন পেলোডে যুক্ত করতে পারবেন না। এই পদ্ধতির ত্রুটি হলো subdomain কম্প্রোমাইজ হলে এটি বাইপাস করা যায়।

Encrypted Token Pattern আরেকটি উন্নত পদ্ধতি যেখানে সার্ভার একটি এনক্রিপ্ট করা টোকেন তৈরি করে যাতে সেশন তথ্য এবং টাইমস্ট্যাম্প থাকে। প্রতিটি রিকোয়েস্টে এই টোকেন পাঠানো হয় এবং সার্ভার এটি ডিক্রিপ্ট করে যাচাই করে। এই পদ্ধতি স্টেটলেস এবং বিশেষত মাইক্রোসারভিস আর্কিটেকচারের জন্য উপযুক্ত।

Custom Request Header পদ্ধতিতে AJAX রিকোয়েস্টে একটি কাস্টম হেডার যেমন X-Requested-With যুক্ত করা হয়। যেহেতু কাস্টম হেডার যুক্ত করতে preflight OPTIONS রিকোয়েস্ট প্রয়োজন এবং সার্ভার সেটি প্রত্যাখ্যান করবে, তাই এটি একটি কার্যকর প্রতিরক্ষা। তবে JSONP বা পুরনো ব্রাউজার ব্যবহার করা হলে এই পদ্ধতির সীমাবদ্ধতা রয়েছে।

বাস্তব জগতে CSRF আক্রমণের বহু উদাহরণ রয়েছে। ২০০৮ সালে Netflix-এ একটি দুর্বলতা পাওয়া গিয়েছিল যা আক্রমণকারীদের ভিকটিমের অ্যাকাউন্ট থেকে ডিভিডি ভাড়া দেওয়ার তালিকা পরিবর্তন করার অনুমতি দিত। ২০১২ সালে eBay-তে একটি CSRF দুর্বলতা পাওয়া গিয়েছিল যা অ্যাকাউন্ট সেটিংস পরিবর্তন করতে দিত। ২০১৭ সালে WordPress-এ একটি বড় CSRF সমস্যা পাওয়া যায় যা লক্ষ লক্ষ ওয়েবসাইট প্রভাবিত করেছিল।

ব্যাংকিং সেক্টরে CSRF-এর প্রভাব সবচেয়ে গুরুতর। কল্পনা করুন একটি ব্যাংকিং অ্যাপ্লিকেশন যেখানে ট্রান্সফার রিকোয়েস্ট একটি সাধারণ POST ফর্মের মাধ্যমে পাঠানো হয় এবং কোনো CSRF সুরক্ষা নেই। একজন ভিকটিম যদি অনলাইন ব্যাংকিং ব্যবহার করার সময় অন্য ট্যাবে একটি ম্যালিশাস সাইট খোলেন, তাহলে সেই সাইট ব্যাকগ্রাউন্ডে একটি ট্রান্সফার রিকোয়েস্ট পাঠাতে পারে এবং বৈধ সেশন কুকির কারণে ব্যাংক সেটি প্রক্রিয়া করবে।

রাউটার এবং IoT ডিভাইসগুলোতে CSRF বিশেষত বিপজ্জনক। অনেক হোম রাউটারের অ্যাডমিন প্যানেলে CSRF সুরক্ষা থাকে না এবং ডিফল্ট ক্রেডেনশিয়াল ব্যবহার করা হয়। আক্রমণকারীরা ম্যালিশাস সাইটের মাধ্যমে রাউটারের DNS সেটিংস পরিবর্তন করে ভিকটিমকে ফিশিং সাইটে রিডাইরেক্ট করতে পারেন। ২০১৪ সালে এই ধরনের আক্রমণে ৩ লক্ষ ৩০ হাজার রাউটার কম্প্রোমাইজ হয়েছিল।

OAuth এবং SSO প্রবাহেও CSRF গুরুতর সমস্যা তৈরি করতে পারে। যদি OAuth state parameter সঠিকভাবে যাচাই না করা হয়, তাহলে আক্রমণকারী ভিকটিমকে আক্রমণকারীর অ্যাকাউন্টের সাথে সংযুক্ত করিয়ে দিতে পারেন। এর ফলে ভিকটিম যা কিছু করেন তা আক্রমণকারীর অ্যাকাউন্টে রেকর্ড হয়।

CSRF প্রতিরোধের জন্য একটি বহুস্তরীয় পদ্ধতি গ্রহণ করা উচিত। প্রথমত, SameSite=Lax অথবা Strict cookie attribute ব্যবহার করুন। বিশেষত সেশন কুকিগুলোর জন্য এটি অত্যাবশ্যক। দ্বিতীয়ত, প্রতিটি রাষ্ট্র পরিবর্তনকারী endpoint-এ Anti-CSRF Token বাস্তবায়ন করুন। token অবশ্যই ক্রিপ্টোগ্রাফিকভাবে র‍্যান্ডম, সেশন-নির্দিষ্ট এবং প্রতিটি রিকোয়েস্টে পরিবর্তিত হতে পারে।

তৃতীয়ত, Origin এবং Referer হেডার যাচাই করুন। যদিও এটি একমাত্র প্রতিরক্ষা হিসেবে যথেষ্ট নয়, এটি একটি কার্যকর অতিরিক্ত স্তর। চতুর্থত, GET রিকোয়েস্ট কখনই রাষ্ট্র পরিবর্তনের জন্য ব্যবহার করবেন না। RESTful নীতি অনুসরণ করে শুধুমাত্র POST, PUT, PATCH এবং DELETE রিকোয়েস্টে রাষ্ট্র পরিবর্তন করুন।

পঞ্চমত, সংবেদনশীল অপারেশনের জন্য re-authentication বা step-up authentication বাস্তবায়ন করুন। পাসওয়ার্ড পরিবর্তন, ইমেইল পরিবর্তন বা বড় অর্থ লেনদেনের আগে ব্যবহারকারীর পাসওয়ার্ড পুনরায় চান বা MFA চ্যালেঞ্জ পাঠান।

ষষ্ঠত, Content Security Policy ব্যবহার করুন। যদিও এটি সরাসরি CSRF প্রতিরোধ করে না, এটি অন্যান্য আক্রমণ যেমন XSS প্রতিরোধ করে যা CSRF-এর সাথে মিলিত হলে আরও বিপজ্জনক হতে পারে।

সপ্তমত, ব্যবহৃত ফ্রেমওয়ার্কের built-in CSRF সুরক্ষা ব্যবহার করুন। Django, Ruby on Rails, ASP.NET, Spring Security - সবগুলোতেই CSRF প্রতিরক্ষা ফিচার রয়েছে। তবে শুধু সক্রিয় করলেই হবে না, সঠিকভাবে কনফিগার করা প্রয়োজন।

অষ্টমত, নিয়মিত নিরাপত্তা পরীক্ষা পরিচালনা করুন। OWASP ZAP, Burp Suite এবং অন্যান্য সরঞ্জাম CSRF দুর্বলতা শনাক্ত করতে সাহায্য করে। CI/CD পাইপলাইনে স্বয়ংক্রিয় নিরাপত্তা টেস্ট অন্তর্ভুক্ত করুন।