CSRF ও ক্লিকজ্যাকিং

CSRF & clickjacking

৮ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এক নজরে · TL;DR

CSRF আক্রমণকারীকে ভিকটিমের ব্রাউজার ও ভিকটিমের নিজস্ব লগইন সেশন কুকি ব্যবহার করে, ভিকটিমের অজান্তেই একটি অনুমোদিত-দেখতে অনুরোধ পাঠাতে দেয়।
মূল প্রতিরক্ষা: প্রতিটি স্পর্শকাতর ফর্মে একটি অননুমানযোগ্য CSRF টোকেন যাচাই করা, এবং কুকিতে SameSite অ্যাট্রিবিউট সেট করা।
ক্লিকজ্যাকিং একটি বৈধ পেজের উপর অদৃশ্য iframe বসিয়ে ব্যবহারকারীকে ভিন্ন একটি বাটনে ক্লিক করতে বিভ্রান্ত করে।
ক্লিকজ্যাকিং প্রতিরোধ: X-Frame-Options বা CSP-এর frame-ancestors হেডার — পেজটি অন্য সাইটের iframe-এ লোড হওয়াই আটকে দেয়।

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

CSRF আক্রমণ ঠিক কীভাবে কাজ করে, এবং কেন ভিকটিমের লগইন করা থাকাই এর পূর্বশর্ত
CSRF টোকেন ও SameSite cookie কীভাবে এই আক্রমণ ঠেকিয়ে দেয়
ক্লিকজ্যাকিং আক্রমণের কৌশল — অদৃশ্য iframe দিয়ে ব্যবহারকারীকে বিভ্রান্ত করা
X-Frame-Options ও CSP frame-ancestors হেডার দিয়ে ক্লিকজ্যাকিং প্রতিরোধ

১ · CSRF কী এবং কীভাবে এটি কাজ করে

CSRFCross-Site Request Forgeryএকটি আক্রমণ যেখানে ভিকটিমের ব্রাউজারকে প্রতারিত করে, ভিকটিমের নিজের বৈধ সেশন ব্যবহার করে, তার অজান্তেই একটি অনুমোদিত-দেখতে অনুরোধ টার্গেট সাইটে পাঠানো হয়। -এর মূল কারণ ব্রাউজারের একটি স্বাভাবিক আচরণ — যখনই আপনি কোনো সাইটে লগইন থাকেন, ব্রাউজার সেই সাইটের প্রতিটি অনুরোধের সাথে স্বয়ংক্রিয়ভাবে আপনার সেশন কুকি জুড়ে দেয়, অনুরোধটি আসলে কোথা থেকে এসেছে তা বিবেচনা না করেই।

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

মূল বিষয়টি লক্ষ করুন

CSRF আক্রমণকারী কখনোই আপনার সেশন কুকি চুরি করে না বা দেখতেও পায় না (Same-Origin Policy তা আটকায়)। সে শুধু আপনাকে দিয়ে একটি অনুরোধ পাঠাতে বাধ্য করে, এবং আপনার ব্রাউজার নিজেই সেই অনুরোধের সাথে আপনার কুকি জুড়ে দেয়। এই কারণেই CSRF শুধুমাত্র সেইসব অনুরোধের বিরুদ্ধে কাজ করে যেগুলো শুধু কুকির উপর ভিত্তি করে অথেন্টিকেট করে — কোনো অতিরিক্ত, অননুমেয় প্রমাণ ছাড়াই।

২ · CSRF-এর প্রতিরক্ষা — CSRF Token ও SameSite Cookie

সমাধানটি সহজ কিন্তু কার্যকর — প্রতিটি স্পর্শকাতর অনুরোধের সাথে এমন কিছু যোগ করা যা শুধু কুকি ছাড়াও যাচাই করা যায়, এবং যা আক্রমণকারীর জাল পেজ জানতে বা অনুমান করতে পারবে না।

CSRF TokenCSRF Tokenপ্রতিটি ব্যবহারকারী সেশন (বা প্রতিটি ফর্ম) এর জন্য সার্ভার-জেনারেটেড একটি র‍্যান্ডম, অননুমানযোগ্য মান, যা ফর্মের একটি হিডেন ফিল্ডে বসানো থাকে এবং সাবমিটের সময় সার্ভার-সাইডে যাচাই করা হয়। — সাইটের নিজস্ব পেজ থেকে ফর্ম সাবমিট করলে সঠিক টোকেন যায়, কিন্তু আক্রমণকারীর জাল পেজ Same-Origin Policy-এর কারণে সঠিক টোকেনটি কখনোই পড়তে পারে না — তাই তার জাল অনুরোধ প্রত্যাখ্যাত হয়।
SameSite cookie attribute — কুকিতে SameSite=Strict বা SameSite=Lax সেট করলে ব্রাউজার নিজেই ক্রস-সাইট অনুরোধের সাথে সেই কুকি পাঠানো বন্ধ করে দেয়, ফলে আক্রমণকারীর সাইট থেকে আসা অনুরোধে ভিকটিমের সেশন কুকিই যায় না।

বাস্তব প্রোডাকশন সিস্টেমে দুটোই একসাথে ব্যবহার করা হয় — defense-in-depth: SameSite cookie প্রথম স্তর, CSRF token দ্বিতীয় স্তর, যাতে কোনো একটি ব্যর্থ হলেও (যেমন কোনো পুরনো ব্রাউজার SameSite সমর্থন না করলে) অন্যটি রক্ষা করে।

৩ · ক্লিকজ্যাকিং কী

ক্লিকজ্যাকিংClickjackingএকটি বৈধ ওয়েবসাইটকে একটি ক্ষতিকর পেজের উপর প্রায় স্বচ্ছ (opacity প্রায় শূন্য) iframe হিসেবে বসিয়ে, ব্যবহারকারীকে একটি ভিন্ন, দৃশ্যমান বাটনে ক্লিক করতে দেখিয়ে আসলে অদৃশ্য বৈধ সাইটের বাটনে ক্লিক করিয়ে ফেলা। -এ আক্রমণকারী একটি আকর্ষণীয় দেখতে পেজ (যেমন "এখানে ক্লিক করে পুরস্কার জিতুন") তৈরি করে, এবং তার ঠিক উপরে টার্গেট সাইটের একটি স্পর্শকাতর বাটন (যেমন "অ্যাকাউন্ট ডিলিট করুন" বা "ফলো করুন") ধারণকারী একটি অদৃশ্য iframe পিক্সেল-পারফেক্টভাবে বসিয়ে দেয়। ব্যবহারকারী যখন দৃশ্যমান বাটনে ক্লিক করে মনে করে সে পুরস্কার জিতছে, আসলে সে অদৃশ্য iframe-এর ভেতরের বাটনে ক্লিক করে ফেলছে — সম্পূর্ণ ভিন্ন একটি সাইটে, ভিন্ন একটি অ্যাকশন সম্পন্ন করছে।

৪ · ক্লিকজ্যাকিং প্রতিরোধ — X-Frame-Options ও CSP frame-ancestors

একটি সাইট নিজেকে অন্য কোনো সাইটের iframe-এর ভেতর লোড হওয়া থেকে সম্পূর্ণভাবে আটকে দিতে পারে একটি HTTP রেসপন্স হেডার সেট করে —

X-Frame-Options: DENY / SAMEORIGIN
পুরনো কিন্তু ব্যাপকভাবে সমর্থিত হেডার। DENY মানে কোনো iframe-এই লোড হবে না, SAMEORIGIN মানে শুধু নিজের ডোমেইনের iframe-এ লোড হবে।

Content-Security-Policy: frame-ancestors
আধুনিক, আরও নমনীয় বিকল্প — নির্দিষ্ট কোন ডোমেইনগুলো এই পেজকে iframe করতে পারবে তার একটি allowlist দেওয়া যায় (ties to L23-এর security-header লিস্ট)।

ব্রাউজার এই হেডার দেখে যদি পেজটিকে কোনো iframe-এ (অথবা অননুমোদিত অরিজিনের iframe-এ) রেন্ডার করতে বলা হয়, তাহলে রেন্ডারিং সম্পূর্ণ বন্ধ করে দেয় — ফলে আক্রমণকারীর পেজে সেই স্পর্শকাতর বাটন আর অদৃশ্যভাবে বসানো সম্ভব হয় না।

৫ · কোড ডেমো — CSRF টোকেন ভ্যালিডেশন সিমুলেশন

নিচের কোড সেলটি সম্পূর্ণ নিরাপদ ও ইন-মেমরি — এটি একটি টাকা-ট্রান্সফার ফাংশনের CSRF-টোকেন যাচাইয়ের যুক্তি সিমুলেট করছে, কোনো বাস্তব নেটওয়ার্ক বা সার্ভারকে স্পর্শ না করেই।

Python

def submit_transfer(session_user, csrf_token, expected_token, amount):
    if csrf_token != expected_token:
        return f"প্রত্যাখ্যাত — {session_user}-এর অনুরোধে ভুল/অনুপস্থিত CSRF token (সম্ভবত জাল ক্রস-সাইট রিকোয়েস্ট)"
    return f"সফল — {session_user}-এর অ্যাকাউন্ট থেকে {amount} টাকা ট্রান্সফার সম্পন্ন হলো"

# সার্ভার এই সেশনের জন্য যে অননুমানযোগ্য টোকেন ইস্যু করেছিল
expected_token = "a1f9c3e7d2b8"

# আক্রমণকারীর জাল ক্রস-সাইট পেজ থেকে আসা অনুরোধ — সঠিক টোকেন জানে না তাই ফাঁকা/ভুল পাঠায়
forged_result = submit_transfer("rahim", csrf_token="", expected_token=expected_token, amount=50000)

# ব্যবহারকারী নিজেই ব্যাংকের সাইটের নিজস্ব ফর্ম থেকে সাবমিট করা অনুরোধ — সঠিক টোকেনসহ
legit_result = submit_transfer("rahim", csrf_token=expected_token, expected_token=expected_token, amount=500)

print("জাল ক্রস-সাইট অনুরোধের ফলাফল:", forged_result)
print("বৈধ, নিজস্ব ফর্মের অনুরোধের ফলাফল:", legit_result)

লক্ষ করুন — forged_result প্রত্যাখ্যাত হয়েছে শুধু এই কারণে যে আক্রমণকারীর পেজ সঠিক expected_token জানত না এবং জানতেও পারত না (Same-Origin Policy তা আটকায়)। এটিই CSRF টোকেনের পুরো নিরাপত্তা-যুক্তি — শুধু কুকির উপর নির্ভর না করে, এমন একটি মান যাচাই করা যা শুধুমাত্র বৈধ, একই-অরিজিন পেজই জানে।

গুরুত্বপূর্ণ সতর্কতা · আইনি বাস্তবতা

L01-এ শেখা নীতিটি এখানেও প্রযোজ্য — নিজের বা অনুমোদিত ল্যাব/CTF পরিবেশ ছাড়া কোনো বাস্তব সাইটে CSRF বা ক্লিকজ্যাকিং কৌশল প্রয়োগ করা লিখিত অনুমতি ছাড়া বেআইনি। একজন এথিক্যাল হ্যাকার এই কৌশলগুলো ব্যবহার করেন শুধু RoE-অনুমোদিত পেনিট্রেশন টেস্টে, দুর্বলতা খুঁজে রিপোর্ট করার জন্য — কখনো প্রকৃত ক্ষতির উদ্দেশ্যে নয়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ কেন CSRF আক্রমণ কাজ করার জন্য ভিকটিমকে অবশ্যই টার্গেট সাইটে ইতিমধ্যে লগইন থাকতে হবে?

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

প্র ০২ SameSite=Strict cookie ব্যবহার করলে কি CSRF টোকেনের আর প্রয়োজনই থাকে না?

বাস্তবে দুটোই একসাথে ব্যবহার করা হয় — defense-in-depth নীতি অনুযায়ী। SameSite সব ব্রাউজারে সম্পূর্ণভাবে বা সঠিকভাবে কনফিগার করা নাও থাকতে পারে, এবং কিছু বৈধ ব্যবহারের ক্ষেত্রে (যেমন এক সাইট থেকে অন্য সাইটে লিংক করা কনটেন্ট) SameSite নীতি শিথিল রাখতে হতে পারে। একটি স্তর ব্যর্থ হলে অন্যটি যেন এখনও রক্ষা করে — এটাই একাধিক স্বাধীন প্রতিরক্ষা স্তর রাখার মূল কারণ।

প্র ০৩ CSRF ও ক্লিকজ্যাকিং — দুটোই ভিকটিমকে "না জেনে" কিছু করানোর আক্রমণ, কিন্তু এদের প্রতিরক্ষা সম্পূর্ণ ভিন্ন কেন?

CSRF সমস্যাটা অনুরোধের উৎস যাচাই নিয়ে (এই অনুরোধ কি সত্যিই আমার সাইটের নিজস্ব ফর্ম থেকে এসেছে?), তাই এর সমাধান টোকেন/কুকি-নীতিতে। ক্লিকজ্যাকিং সমস্যাটা ভিজ্যুয়াল প্রতারণা নিয়ে (ব্যবহারকারী আসলে কী দেখছে এবং কীসে ক্লিক করছে), তাই এর সমাধান পেজটিকে iframe হওয়া থেকেই আটকে দেওয়া। দুটো আক্রমণ একই "না জেনে কিছু করানো" লক্ষ্য শেয়ার করলেও, আক্রমণের কৌশল ভিন্ন বলে প্রতিরক্ষার স্তরও ভিন্ন।

অনুশীলন

পরীক্ষা করুন: উপরের কোড সেলে forged_result-এর csrf_token ফাঁকা স্ট্রিং-এর বদলে ভুল কিন্তু নন-এম্পটি একটি মান (যেমন "wrong123") দিয়ে চালান — ফলাফল কি বদলায়?

না, ফলাফল একই থাকবে — এখনও প্রত্যাখ্যাত হবে। যাচাইটি শুধু "টোকেন খালি কি না" তা দেখে না, বরং csrf_token != expected_token — যেকোনো ভুল মান, খালি হোক বা না হোক, প্রত্যাখ্যাত হবে। শুধুমাত্র হুবহু সঠিক, সার্ভার-ইস্যুকৃত টোকেনই গ্রহণযোগ্য।
চিন্তা করুন: একটি ওয়েব অ্যাপ যদি অ্যাকাউন্ট-ডিলিট করার মতো state পরিবর্তনকারী অ্যাকশন GET request দিয়ে করে (যেমন /delete-account?confirm=yes লিংকে ক্লিক করলেই কাজ হয়ে যায়), তাহলে CSRF আক্রমণ কেন আরও সহজ হয়ে যায়?

কারণ GET request পাঠাতে কোনো ফর্ম সাবমিট বা জাভাস্ক্রিপ্টের প্রয়োজন নেই — শুধু একটি সাধারণ <img src="..."> ট্যাগ বা লিংক দিয়েই ব্রাউজার স্বয়ংক্রিয়ভাবে সেই URL-এ অনুরোধ পাঠিয়ে দেয়, ভিকটিমের কোনো ক্লিকেরও প্রয়োজন হয় না। এই কারণেই ভালো ওয়েব ডিজাইন নীতি অনুযায়ী, state পরিবর্তনকারী যেকোনো অ্যাকশন সবসময় POST/PUT/DELETE-এর মতো মেথডে হওয়া উচিত, কখনো সাদামাটা GET-এ নয়।