মোবাইল ডেভেলপমেন্টে CSRF: এটি কী, আক্রমণের ধরন এবং সুরক্ষার পদ্ধতি

CSRF আক্রমণ কী?

CSRF (Cross-Site Request Forgery) — একটি আক্রমণ যেখানে আক্রমণকারী একটি জাল অনুরোধ তৈরি করে এবং শিকারের ব্রাউজারকে টার্গেট সার্ভারে পাঠাতে বাধ্য করে। সার্ভার অনুরোধটি সম্পাদন করে কারণ এটি ব্যবহারকারীর বর্তমান সেশন থেকে বৈধ কুকি ক্রেডেনশিয়াল পায়। আক্রমণটি সম্ভব কারণ ব্রাউজার স্বয়ংক্রিয়ভাবে টার্গেট ডোমেনের প্রতিটি অনুরোধে কুকি যুক্ত করে, অনুরোধটি কোন পেজ থেকে পাঠানো হয়েছে তা নির্বিশেষে। ব্যবহারকারী আক্রমণকারীর পেজ দেখতেও পারেন না — একটি লুকানো <img>, <form> বা <iframe> দূষিত URL সহ লোড করাই যথেষ্ট। CSRF সরাসরি ডেটা চুরি করে না — আক্রমণটি শিকারের পক্ষে কাজ করে (স্টেট-চেঞ্জিং অপারেশন), যেমন অর্থ স্থানান্তর, পাসওয়ার্ড পরিবর্তন বা অ্যাকাউন্ট মুছে ফেলা।

কোন অপারেশনগুলি সবচেয়ে ঝুঁকিপূর্ণ?

CSRF আক্রমণগুলি একচেটিয়াভাবে স্টেট-চেঞ্জিং অপারেশনগুলিকে লক্ষ্য করে — GET অনুরোধ সাইড ইফেক্ট সহ, POST, PUT এবং DELETE। উদাহরণস্বরূপ, ব্যক্তিগত অ্যাকাউন্টে ইমেল ঠিকানা পরিবর্তনের অনুরোধ: যদি সার্ভার উত্স যাচাই না করে অনুরোধ গ্রহণ করে, আক্রমণকারী তার নিজের ইমেল বসিয়ে পাসওয়ার্ড রিসেট শুরু করতে পারে। আক্রমণটি বিশেষ করে ব্যাংকিং সিস্টেম, অ্যাডমিন প্যানেল এবং সোশ্যাল নেটওয়ার্কগুলির জন্য বিপজ্জনক, যেখানে একটি কাজের গুরুতর পরিণতি হয়। মোবাইল অ্যাপ API যেগুলি প্রমাণীকরণের জন্য কুকি ব্যবহার করে, সেগুলিও CSRF-এর প্রতি সংবেদনশীল যদি অতিরিক্ত যাচাই না করে।

কে ঝুঁকিতে?

যেকোনো ওয়েব অ্যাপ্লিকেশন এবং API যেখানে প্রমাণীকরণ কুকির উপর ভিত্তি করে এবং সার্ভার অনুরোধের উত্স যাচাই করে না, ঝুঁকিপূর্ণ। মোবাইল অ্যাপ্লিকেশন যেগুলি ওয়েব ফর্মের মাধ্যমে প্রমাণীকরণের জন্য WebView ব্যবহার করে, সেগুলিও ঝুঁকিতে: ব্রাউজার উপাদান স্বয়ংক্রিয়ভাবে কুকি পাঠায়, এবং আক্রমণকারী ব্যাকগ্রাউন্ড লোডিংয়ের মাধ্যমে দূষিত অনুরোধ ইনজেক্ট করতে পারে। HackerOne (2025)-এর মতে, ওয়েব অ্যাপ্লিকেশনে সমস্ত দুর্বলতা রিপোর্টের প্রায় 12% CSRF সুরক্ষার অভাবের সাথে সম্পর্কিত।

CSRF-কে বিপজ্জনক কী করে?

CSRF-এর প্রধান বৈশিষ্ট্য হল শিকারের কাছে অদৃশ্যতা। ব্যবহারকারী বুঝতেও পারেন না যে আক্রমণ ঘটেছে: জাল অনুরোধটি ব্যাকগ্রাউন্ডে সম্পাদিত হয়, এবং অ্যাপ্লিকেশন ইন্টারফেস আপোসের কোনো লক্ষণ দেখায় না। CSRF সনাক্ত করার একমাত্র উপায় হল সার্ভার লগ মনিটর করা বা অ্যাকাউন্টে হঠাৎ পরিবর্তন লক্ষ্য করা। উপরন্তু, CSRF সহজেই অন্যান্য দুর্বলতার সাথে মিলিত হতে পারে যেমন XSS বা ওপেন রিডাইরেক্ট, যা ক্ষতি বহুগুণ বাড়িয়ে দেয়।

CSRF আক্রমণ কীভাবে কাজ করে?

CSRF আক্রমণের জন্য তিনটি শর্ত প্রয়োজন: শিকার টার্গেট সাইটে প্রত্যয়িত, সার্ভার কুকি প্রমাণীকরণ ব্যবহার করে, এবং আক্রমণকারীর অনুরোধ একটি অ্যাকশন URL-এ নির্দেশিত। আক্রমণকারী একটি HTML পেজ তৈরি করে যাতে একটি ফর্ম, স্ক্রিপ্ট বা ছবি থাকে যার src অ্যাট্রিবিউট টার্গেট URL-এর দিকে নির্দেশ করে। শিকারের ব্রাউজার এই পেজটি লোড করে এবং স্বয়ংক্রিয়ভাবে বর্তমান সেশন কুকি সহ সার্ভারে অনুরোধ পাঠায়। সার্ভার বৈধ কুকি পায়, অনুরোধের উত্স যাচাই করে না এবং অপারেশন সম্পাদন করে।

<!-- লুকানো ফর্মের মাধ্যমে CSRF আক্রমণের উদাহরণ -->
<form action="https://bank.example.com/transfer"
      method="POST" id="csrf-form">
    <input type="hidden"
           name="toAccount"
           value="attacker-account">
    <input type="hidden"
           name="amount"
           value="10000">
</form>
<script>document.getElementById("csrf-form").submit()</script>

পেজ লোড হওয়ার পর, স্ক্রিপ্ট অবিলম্বে ফর্ম জমা দেয়। ব্রাউজার bank.example.com-এ POST অনুরোধের সাথে ব্যবহারকারীর সেশন কুকি সংযুক্ত করে। ব্যাংকের সার্ভার কুকি যাচাই করে, নিশ্চিত করে যে ব্যবহারকারী প্রত্যয়িত, এবং আক্রমণকারীর অ্যাকাউন্টে স্থানান্তর সম্পাদন করে। শিকার একটি ফাঁকা বা বৈধ পেজ দেখে, কিন্তু টাকা ইতিমধ্যে চলে গেছে।

CSRF-এ ব্রাউজারের ভূমিকা

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

CSRF আক্রমণের প্রধান ধরন

CSRF আক্রমণগুলি দূষিত অনুরোধ সরবরাহের পদ্ধতি অনুসারে শ্রেণীবদ্ধ করা হয়। প্রতিটি ধরন অনুরোধ পাঠানোর জন্য একটি ভিন্ন HTML উপাদান ব্যবহার করে, কিন্তু সবই ব্রাউজার দ্বারা স্বয়ংক্রিয় কুকি পাঠানোর উপর নির্ভর করে। পদ্ধতির পছন্দ আক্রমণকারীর লক্ষ্যের উপর নির্ভর করে: GET-ভিত্তিক আক্রমণে কম কোড প্রয়োজন, POST-ভিত্তিক আক্রমণ কিছু সুরক্ষা আরও নির্ভরযোগ্যভাবে বাইপাস করে, এবং XMLHttpRequest-ভিত্তিক আক্রমণ হেডার ম্যানিপুলেশনের অনুমতি দেয়।

GET-ভিত্তিক CSRF

সবচেয়ে সহজ পদ্ধতি: আক্রমণকারী একটি পেজে <img> রাখে যার URL-এ অনুরোধ প্যারামিটার থাকে। ব্রাউজার ছবিটি লোড করে এবং সার্ভারে একটি GET অনুরোধ পাঠায়। উদাহরণস্বরূপ, <img src="https://api.example.com/delete?postId=123" /> একটি রেকর্ড মুছে ফেলে যদি সার্ভার GET-এর মাধ্যমে DELETE হ্যান্ডেল করে। স্পষ্ট বিপদ সত্ত্বেও, কিছু API এখনও মুছে ফেলা বা আপডেট করার অপারেশনের জন্য GET ব্যবহার করে।

POST-ভিত্তিক CSRF

যদি সার্ভার শুধুমাত্র POST অনুরোধ গ্রহণ করে, আক্রমণকারী POST পদ্ধতি সহ একটি লুকানো ফর্ম তৈরি করে এবং JavaScript-এর মাধ্যমে স্বয়ংক্রিয়ভাবে জমা দেয়। ফর্মটি স্ক্রিনে প্রদর্শিত হয় না (সব <input>-এ type="hidden" থাকে), এবং autofocus + .submit() ব্যবহারকারীর ক্লিক ছাড়াই ট্রিগার হয়। POST-ভিত্তিক আক্রমণ কাজ করে না যদি সার্ভার Content-Type হেডার যাচাই করে, কিন্তু বেশিরভাগ API স্ট্যান্ডার্ড application/x-www-form-urlencoded গ্রহণ করে।

XHR-ভিত্তিক CSRF (CORS সহ)

XMLHttpRequest বা Fetch API নির্বিচারে হেডার সহ অনুরোধ পাঠাতে দেয়। যদি সার্ভার CORS খুব বিস্তৃতভাবে কনফিগার করে থাকে (Access-Control-Allow-Origin: *), আক্রমণকারী যেকোনো অনুরোধ পাঠাতে এবং প্রতিক্রিয়া পড়তে পারে। তবে, CSRF আক্রমণের জন্য প্রতিক্রিয়া পড়া প্রয়োজনীয় নয় — কাজটি সম্পাদন করাই যথেষ্ট। আধুনিক ব্রাউজারগুলি অ-মানক অনুরোধের আগে একটি preflight অনুরোধ OPTIONS পাঠায়, যা XHR-ভিত্তিক CSRF ব্লক করতে পারে যদি সার্ভার সঠিকভাবে কনফিগার করা থাকে।

মোবাইল অ্যাপ্লিকেশনে CSRF

মোবাইল অ্যাপ্লিকেশনগুলি ওয়েবসাইটের তুলনায় CSRF-এর প্রতি কম সংবেদনশীল কারণ নেটিভ অ্যাপগুলি খুব কমই কুকি প্রমাণীকরণ ব্যবহার করে। পরিবর্তে, মোবাইল APIগুলি প্রায়শই Authorization হেডারে (Bearer টোকেন, JWT) টোকেন ব্যবহার করে। তবে, এমন কিছু পরিস্থিতি রয়েছে যেখানে CSRF আক্রমণ সম্ভব: ওয়েব লগইন সহ WebView, হাইব্রিড অ্যাপ্লিকেশন এবং কুকি-ভিত্তিক সেশন সহ API। TechCrunch (2025)-এর মতে, প্রায় 18% পাবলিক মোবাইল অ্যাপ API এখনও সেশন কুকি সমর্থন করে।

WebView-এর মাধ্যমে CSRF

অনেক অ্যাপ WebView-এ ওয়েব পেজ খোলে — OAuth অনুমোদন, পেমেন্ট ফর্ম, বিষয়বস্তু দেখা। WebView হল অ্যাপের ভিতরে একটি পূর্ণাঙ্গ ব্রাউজার যা সেশন কুকি সংরক্ষণ করে। যদি আক্রমণকারী WebView-এ তার URL লোড করার উপায় খুঁজে পায় (ওপেন রিডাইরেক্ট বা ডিপ লিংকের মাধ্যমে), সে সাধারণ ব্রাউজারের মতোই CSRF আক্রমণ চালাতে পারে। সুরক্ষা — গুরুত্বপূর্ণ অপারেশনের জন্য WebView-এর পরিবর্তে Chrome Custom Tabs বা SFSafariViewController ব্যবহার করুন।

JWT প্রমাণীকরণ সহ API-তে CSRF

JWT টোকেন সাধারণত localStorage বা অ্যাপের মেমোরিতে সংরক্ষিত থাকে এবং স্বয়ংক্রিয়ভাবে পাঠানো হয় না — ডেভেলপার স্পষ্টভাবে প্রতিটি অনুরোধে Authorization হেডার যোগ করে। এটি ক্লাসিক CSRF আক্রমণকে অসম্ভব করে তোলে। তবে, যদি অ্যাপ JWT কুকিতে সংরক্ষণ করে (বিরল কিন্তু সম্ভব), ঝুঁকি ফিরে আসে। অতিরিক্ত সুরক্ষা — azp বা aud claim-এর মাধ্যমে JWT-কে একটি নির্দিষ্ট অনুরোধ উত্সের সাথে বাঁধা, যা ভিন্ন ডোমেনে টোকেন ব্যবহার প্রতিরোধ করে।

// Express-এ সার্ভার-সাইড CSRF টোকেন যাচাইয়ের উদাহরণ
const csrfProtection = (req, res, next) => {
    const token = req.headers['x-csrf-token'];
    if (!token || token !== req.session.csrfToken) {
        return res.status(403).json({ error: 'CSRF validation failed' });
    }
    next();
};

// লগইনে CSRF টোকেন জেনারেট করা
app.post('/api/login', (req, res) => {
    const csrfToken = crypto.randomBytes(32).toString('hex');
    req.session.csrfToken = csrfToken;
    res.json({ csrfToken: csrfToken });
});

CSRF থেকে সুরক্ষার পদ্ধতি

আধুনিক CSRF সুরক্ষা তিনটি স্তরে নির্মিত: সার্ভার-সাইড CSRF টোকেন, কুকিজের জন্য SameSite অ্যাট্রিবিউট এবং Origin হেডার যাচাই। এই পদ্ধতিগুলির সংমিশ্রণ UX-কে উল্লেখযোগ্যভাবে প্রভাবিত না করে 99% CSRF আক্রমণ থেকে সুরক্ষা প্রদান করে। পদ্ধতির পছন্দ অ্যাপ্লিকেশন আর্কিটেকচারের উপর নির্ভর করে: একটি ওয়েবসাইটের শুধুমাত্র SameSite=Lax প্রয়োজন হতে পারে, যখন একটি মোবাইল অ্যাপ API-তে হেডারে টোকেন প্রয়োজন।

CSRF টোকেন (সিঙ্ক্রোনাইজার)

স্ট্যান্ডার্ড পদ্ধতি: সার্ভার একটি অনন্য টোকেন তৈরি করে, এটি ব্যবহারকারীর সেশনের সাথে আবদ্ধ করে এবং ক্লায়েন্টকে পাঠায়। ক্লায়েন্ট প্রতিটি স্টেট-চেঞ্জিং অনুরোধে টোকেন অন্তর্ভুক্ত করে (একটি লুকানো ফর্ম ফিল্ড বা X-CSRF-Token হেডারে)। সার্ভার প্রাপ্ত টোকেন সেশনে সংরক্ষিত টোকেনের সাথে তুলনা করে। টোকেন ক্রিপ্টোগ্রাফিকভাবে শক্তিশালী, এলোমেলো, কমপক্ষে 32 বাইট লম্বা হতে হবে এবং প্রতিটি সেশন বা অপারেশনের সাথে পরিবর্তন হতে হবে। টোকেনের জীবনকাল কয়েক ঘণ্টার বেশি হওয়া উচিত নয়।

SameSite কুকি

কুকিজের জন্য SameSite অ্যাট্রিবিউট ক্রস-ডোমেন অনুরোধে কুকি পাঠানো সীমাবদ্ধ করে। Lax মান শুধুমাত্র শীর্ষ-স্তরের নেভিগেশন GET অনুরোধের জন্য কুকি অনুমতি দেয় — বেশিরভাগ ওয়েবসাইটের জন্য যথেষ্ট। Strict সব ক্রস-ডোমেন অনুরোধের জন্য কুকি ব্লক করে, নেভিগেশন সহ: অন্য সাইট থেকে আসলে ব্যবহারকারীকে পুনরায় প্রমাণীকরণ করতে হবে। Chrome Platform Status (2026)-এর মতে, SameSite=Lax সব আধুনিক ব্রাউজারে ডিফল্টরূপে সক্রিয়, যা CSRF আক্রমণের সংখ্যা 67% কমিয়েছে।

Origin এবং Referer যাচাই

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

// Spring Boot-এ CSRF টোকেন যাচাইয়ের উদাহরণ
@Configuration
@EnableWebSecurity
class SecurityConfig {
    @Bean
    fun securityFilterChain(
        @Autowired http: HttpSecurity
    ): SecurityFilterChain {
        return http
            .csrf { it.csrfTokenRepository(
                CookieCsrfTokenRepository.withHttpOnlyFalse()
            ) }
            .sessionManagement {
                it.sessionCreationPolicy(SessionCreationPolicy.IF_REQUIRED)
            }
            .build()
    }
}

Double Submit কুকি

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

• CSRF টোকেন — সোনার মান: নির্ভরযোগ্য, সময়-পরীক্ষিত, সব ফ্রেমওয়ার্ক দ্বারা সমর্থিত
• SameSite=Lax — ওয়েব অ্যাপের জন্য ন্যূনতম সুরক্ষা: বিনামূল্যে, স্বয়ংক্রিয়, কোনো কোড প্রয়োজন নেই
• Origin যাচাই — একটি অতিরিক্ত স্তর: টোকেন যাচাইয়ের আগে আক্রমণ ব্লক করে
• Double Submit — সার্ভার-সাইড সেশন ছাড়া REST API-র জন্য: HTTPS-এ কার্যকর
• কাস্টম হেডার — X-Requested-With: XMLHttpRequest সাধারণ CSRF ফর্ম ব্লক করে

CSRF এবং XSS-এর মধ্যে পার্থক্য

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

CSRF এবং XSS-এর মধ্যে পার্থক্য বোঝা বহু-স্তরের সুরক্ষা তৈরির জন্য গুরুত্বপূর্ণ। CSRF টোকেন XSS থেকে রক্ষা করে না, এবং CSP (Content Security Policy) CSRF থেকে রক্ষা করে না। শুধুমাত্র পদ্ধতিগুলির সংমিশ্রণ উভয় ধরনের আক্রমণ থেকে অ্যাপ্লিকেশন সুরক্ষা নিশ্চিত করে। WebView সহ মোবাইল অ্যাপে, ঝুঁকি দ্বিগুণ হয়, তাই ডেভেলপারদের API অনুরোধের জন্য কমপক্ষে CSRF টোকেন এবং ওয়েব বিষয়বস্তুর জন্য Content Security Policy প্রয়োগ করার পরামর্শ দেওয়া হয়।