Input Validation و XSS؛ وقتی ورودی به نقطه ضعف تبدیل می‌شود
نویسنده: تیم آموزشی صفر و یک سایبر | SINISTER
سطح: متوسط تا پیشرفته
حوزه: Web Application Security
ابزارها: Burp Suite، مرورگر، DevTools
محیط تمرین: OWASP Juice Shop روی سیستم شخصی
۱. هر ورودی، یک مرز امنیتی است
هر بار که کاربر در یک فرم اطلاعات وارد می‌کند، یک جست‌وجو انجام می‌دهد، نظری ثبت می‌کند یا درخواستی به API می‌فرستد، داده‌ای وارد برنامه می‌شود.
این داده ممکن است از منابع مختلفی آمده باشد:
- فرم‌های HTML
- پارامترهای URL
- بدنه درخواست‌های JSON
- کوکی‌ها و هدرهای HTTP
- فایل‌های بارگذاری‌شده
- پاسخ سرویس‌های خارجی
نکته مهم این است که هیچ ورودی‌ای صرفاً به دلیل دریافت شدن از مرورگر قابل اعتماد نیست.
برنامه باید داده را بر اساس نوع، ساختار، محدودیت‌ها و محل استفاده آن اعتبارسنجی و پردازش کند.
۲. Input Validation چیست؟
اعتبارسنجی ورودی یعنی بررسی اینکه داده دریافتی با قواعد مورد انتظار برنامه مطابقت دارد یا خیر.
فرض کن یک فرم ثبت‌نام شامل این فیلدهاست:
| فیلد | قاعده مورد انتظار |
|---|---|
| نام کاربری | رشته با طول و قالب مشخص |
| ایمیل | قالب معتبر ایمیل |
| سن | عدد در محدوده تعریف‌شده |
| تعداد محصولات | عدد صحیح مثبت |
| شناسه سفارش | شناسه‌ای با قالب مورد انتظار |
برای مثال، اگر فیلد «تعداد محصولات» فقط باید عدد صحیح مثبت بپذیرد، ارسال یک متن دلخواه نباید باعث اختلال در منطق برنامه شود.
اعتبارسنجی سمت کاربر و سمت سرور
Client-Side Validation: در مرورگر اجرا می‌شود و برای تجربه کاربری مفید است.
Server-Side Validation: در سرور اجرا می‌شود و برای اعمال قواعد امنیتی ضروری است.
اعتبارسنجی مرورگر به‌تنهایی کافی نیست؛ چون کاربر می‌تواند درخواست HTTP را خارج از فرم معمولی مرورگر ارسال یا تغییر دهد.
همچنین اعتبارسنجی فقط بررسی قالب داده نیست. سرور باید محدودیت‌های تجاری، مالکیت منابع و مجاز بودن عملیات را نیز بررسی کند.
۳. تفاوت Validation، Sanitization و Output Encoding
این سه مفهوم اغلب با یکدیگر اشتباه گرفته می‌شوند.
Validation — اعتبارسنجی
بررسی می‌کند که داده با قواعد تعیین‌شده مطابقت داشته باشد.
مثال: فیلد تعداد باید عدد صحیح مثبت باشد.
Sanitization — پاک‌سازی
داده را مطابق یک سیاست مشخص تغییر می‌دهد تا بخش‌های نامطلوب حذف یا اصلاح شوند. استفاده از آن باید متناسب با نوع داده و کاربرد باشد؛ پاک‌سازی عمومی و بدون سیاست روشن می‌تواند مشکلات جدیدی ایجاد کند.
Output Encoding — کدگذاری خروجی
داده را هنگام نمایش، متناسب با بافت خروجی کدگذاری می‌کند تا مرورگر آن را به‌عنوان داده تفسیر کند، نه کد اجرایی.
برای جلوگیری از XSS، کدگذاری خروجی متناسب با محل درج داده، به‌همراه پرهیز از APIهای ناامن، اهمیت زیادی دارد.
۴. XSS چیست؟
Cross-Site Scripting (XSS) نوعی آسیب‌پذیری در برنامه‌های وب است که در آن محتوای کنترل‌شده توسط مهاجم، در مرورگر کاربر به‌عنوان کد اجرایی تفسیر می‌شود.
پیامدهای احتمالی به زمینه و شرایط آسیب‌پذیری بستگی دارند و می‌توانند شامل تغییر محتوای صفحه، اجرای عملیات در بستر نشست کاربر یا دست‌کاری تجربه کاربری باشند.
XSS به‌معنی «هک شدن خودکار سرور» نیست؛ مسئله اصلی، اجرای ناخواسته کد در مرورگر در بستر یک صفحه یا مبدأ مشخص است.
انواع اصلی XSS
۱. Reflected XSS
داده ارسالی در یک درخواست، بدون پردازش امن مناسب در پاسخ منعکس می‌شود و ممکن است در مرورگر اجرا شود.
۲. Stored XSS
محتوای کنترل‌شده در برنامه ذخیره می‌شود و هنگام مشاهده توسط کاربر یا کاربران دیگر، به شکل ناامن اجرا می‌شود.
۳. DOM-Based XSS
آسیب‌پذیری از نحوه پردازش داده در سمت مرورگر و تعامل آن با DOM ایجاد می‌شود؛ حتی ممکن است مشکل اصلی در کد سمت سرور نباشد.
این دسته‌ها از نظر مسیر ورود داده متفاوت‌اند، اما در هر سه مورد باید جریان داده تا محل استفاده نهایی بررسی شود.
۵. مرورگر چگونه یک ورودی را تفسیر می‌کند؟
مرورگر بر اساس محل قرارگیری داده، رفتار متفاوتی دارد.
برای مثال، یک رشته ممکن است در متن معمولی HTML فقط به‌صورت متن نمایش داده شود، اما اگر به‌صورت ناامن وارد یک محل اجرایی JavaScript شود، رفتار دیگری پیدا کند.
بنابراین یک رشته مشخص، در تمام بافت‌های HTML، ویژگی‌های HTML، JavaScript و URL الزاماً رفتار یکسانی ندارد.
اصل کلیدی: کدگذاری خروجی باید متناسب با بافت باشد؛ یک روش واحد برای همه محل‌های نمایش داده کافی نیست.
۶. آزمایشگاه عملی اول: بررسی ورودی‌ها
در این تمرین از نسخه محلی OWASP Juice Shop استفاده کن.
مرحله اول: انتخاب یک قابلیت
یک بخش مانند جست‌وجو یا فرم ثبت نظر را باز کن.
در مرورگر:
- DevTools را باز کن.
- به زبانه Network برو.
- یک ورودی آزمایشی معمولی وارد کن.
- درخواست مربوط به آن را پیدا کن.
- نوع درخواست، پارامترها و پاسخ را یادداشت کن.
هدف این مرحله، شناخت مسیر انتقال داده است.
مرحله دوم: ساخت نقشه جریان داده
برای ورودی انتخاب‌شده این مسیر را ثبت کن:
User Input → HTTP Request → Application Processing → Response → Browser Rendering
در هر مرحله بپرس:
- داده کجا دریافت می‌شود؟
- کجا اعتبارسنجی می‌شود؟
- آیا داده ذخیره می‌شود؟
- آیا داده در پاسخ بازمی‌گردد؟
- در کدام بخش صفحه نمایش داده می‌شود؟
- آیا نحوه نمایش بافت امنی دارد؟
ممکن است برای پاسخ به بعضی از این پرسش‌ها به مشاهده کد برنامه نیاز داشته باشی. اگر شواهد کافی در اختیار نداری، نتیجه را قطعی اعلام نکن.
۷. آزمایشگاه عملی دوم: مشاهده رفتار ورودی در مرورگر
در محیط محلی، یک رشته بی‌خطر و قابل تشخیص مانند زیر وارد فیلد جست‌وجو کن:
ZERO-ONE-TEST-09
سپس بررسی کن:
- آیا رشته در درخواست ارسال شده است؟
- آیا در پاسخ سرور دیده می‌شود؟
- آیا در DOM صفحه وجود دارد؟
- آیا به‌صورت متن عادی نمایش داده می‌شود؟
- آیا برنامه آن را در چند بخش مختلف نمایش می‌دهد؟
در DevTools می‌توانی بخش Elements را برای بررسی DOM و بخش Network را برای بررسی درخواست و پاسخ استفاده کنی.
در این مرحله هنوز قصد اجرای کد نداریم؛ هدف، شناخت جریان داده و محل نمایش آن است.
۸. آزمایشگاه عملی سوم: بررسی امن XSS
برای بررسی رفتار امنیتی، از یک نمونه آموزشی اختصاصی یا قابلیت آسیب‌پذیر مستندشده در آزمایشگاه محلی استفاده کن.
روش کار:
۱. قابلیت موردنظر را مشخص کن.
۲. ورودی و محل نمایش آن را ثبت کن.
۳. بررسی کن داده به‌صورت متن عادی نمایش داده می‌شود یا وارد یک بافت اجرایی می‌شود.
۴. رفتار برنامه را با قواعد امنیتی مورد انتظار مقایسه کن.
۵. در صورت استفاده از نمونه آزمایشی XSS، آن را فقط در محیط ایزوله و تحت کنترل خودت اجرا کن و نتیجه را مستند کن.
برای جلوگیری از اجرای ناخواسته اسکریپت، ورودی‌های اجرایی را در سامانه‌های عمومی، مرورگر دارای نشست واقعی یا حساب کاربران دیگر آزمایش نکن.
نکته: مشاهده یک رشته در پاسخ، به‌تنهایی آسیب‌پذیری XSS را اثبات نمی‌کند. باید مشخص شود که آیا مرورگر واقعاً آن را در یک بافت اجرایی ناامن تفسیر می‌کند یا خیر.
۹. Burp Suite در تحلیل ورودی‌ها
Burp Suite به تو کمک می‌کند درخواست‌ها و پاسخ‌های HTTP را بررسی کنی.
در آزمایشگاه:
- در Proxy / HTTP history درخواست مرتبط را پیدا کن.
- در Repeater درخواست مجاز و آزمایشی را برای بررسی رفتار تکرار کن.
- پارامترهای Query، بدنه JSON و هدرهای مرتبط را شناسایی کن.
- پاسخ را از نظر بازتاب ورودی، نوع محتوا و تغییرات مشاهده‌شده بررسی کن.
در گزارش خود تفاوت این موارد را حفظ کن:
- داده در درخواست ارسال شد.
- داده در پاسخ بازتاب یافت.
- داده در DOM قرار گرفت.
- داده به‌عنوان کد اجرا شد.
این‌ها چهار مشاهده متفاوت‌اند و نباید به‌جای یکدیگر استفاده شوند.
۱۰. روش‌های پیشگیری از XSS
الف) کدگذاری خروجی متناسب با بافت
داده‌های غیرقابل اعتماد باید پیش از نمایش، متناسب با محل استفاده کدگذاری شوند.
ب) استفاده از APIهای امن DOM
برای نمایش متن، APIهایی مانند textContent معمولاً از قرار دادن مستقیم داده در HTML با innerHTML ایمن‌ترند؛ البته امنیت نهایی به نحوه استفاده و بافت داده وابسته است.
ج) اعتبارسنجی سمت سرور
ورودی‌ها باید مطابق قواعد مورد انتظار برنامه بررسی شوند. با این حال، اعتبارسنجی جایگزین کدگذاری خروجی نیست.
د) استفاده از چارچوب‌های امن
از قابلیت‌های امن قالب‌سازی و نمایش داده در چارچوب‌های وب استفاده کن و از غیرفعال کردن محافظت‌های پیش‌فرض بدون دلیل مشخص بپرهیز.
هـ) Content Security Policy
سیاست CSP می‌تواند در کاهش اثر برخی حملات کمک کند، اما جایگزین اصلاح علت اصلی XSS نیست.
و) پرهیز از اعتماد به ورودی ذخیره‌شده
داده‌ای که در پایگاه داده ذخیره شده نیز ممکن است غیرقابل اعتماد باشد؛ ذخیره شدن، آن را امن نمی‌کند.
۱۱. چالش قسمت نهم
در آزمایشگاه محلی، سه قابلیت مختلف را بررسی کن و برای هرکدام یک گزارش کوتاه بساز.
گزارش باید شامل این موارد باشد:
- نام قابلیت
- نوع ورودی
- مسیر انتقال داده
- محل نمایش در مرورگر
- رفتار اعتبارسنجی مشاهده‌شده
- نحوه پردازش خروجی
- شواهد موجود
- نتیجه و میزان اطمینان
- پیشنهاد اصلاح
هدف چالش: بتوانی تفاوت میان یک ورودی معمولی، یک بازتاب ساده و یک آسیب‌پذیری XSS واقعی را بر اساس شواهد توضیح دهی.
۱۲. جمع‌بندی
در این قسمت یاد گرفتی که امنیت ورودی فقط به رد کردن داده‌های نامعتبر محدود نمی‌شود. باید جریان داده را از لحظه دریافت تا پردازش و نمایش دنبال کرد.
یک Pentester حرفه‌ای سه سؤال اساسی می‌پرسد:
۱. داده از کجا آمده است؟
۲. برنامه آن را چگونه پردازش می‌کند؟
۳. مرورگر در نهایت چگونه آن را تفسیر می‌کند؟
وقتی این مسیر را درست تحلیل کنی، شناسایی و گزارش نقص‌های مرتبط با ورودی بسیار دقیق‌تر می‌شود.
قسمت بعدی: SQL Injection؛ بررسی نحوه تعامل ورودی کاربر با پایگاه داده و روش‌های امن ارزیابی این سطح از برنامه.
صفر و یک سایبر | آموزش فارسی امنیت سایبری و هک قانونمند
یادگیری واقعی از مشاهده، فرضیه‌سازی، آزمایش کنترل‌شده و مستندسازی شواهد شکل می‌گیرد. تمرین‌ها را فقط روی آزمایشگاه محلی یا سامانه‌هایی انجام بده که مجوز صریح تست آن‌ها را داری.
دیدگاه شما