کد مخرب چیست کدهای مخرب چیست رمزهای عبور قوی را روی نرم افزار سرور قرار دهید

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

ویدیوهای بیشتر در کانال ما - بازاریابی اینترنتی را با SEMANTICA یاد بگیرید

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

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

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

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

چگونه کدهای مخرب در سایت قرار می گیرند

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

1. دانلود فایل ها و افزونه ها از منابع مشکوک و غیر قابل اعتماد. اغلب، لینک های رمزگذاری شده به این روش ها به سایت نفوذ می کنند. کد واضح به ندرت از این طریق وارد سایت می شود.

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

از بین بردن چنین کدی بسیار سخت است، زیرا. پس از حذف قابل بازیابی است.

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

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

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

پیدا کردن / دایرکتوری فعلی صفحه -type f -iname "*" -exek -"eval" () \; > ./eval.log

پیدا کردن / دایرکتوری فعلی صفحه -type f -iname "*" -exek-"base64" () \; > ./base64.log

پیدا کردن / دایرکتوری صفحه فعلی -type f -iname "*" -exek -"file_get_contents" () \; > ./file_get_contents.log

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

• بررسی یک سایت برای کدهای مخرب با استفاده از تابع eval. این تابع php هر کدی حتی رمزگذاری شده را اجرا می کند. به عنوان یکی از آرگومان ها، نوع رمزگذاری به عنوان ورودی این تابع داده می شود (معمولا base64_decode یا str_rot13). به لطف استفاده از رمزگذاری های محبوب است که کد مخرب مانند مجموعه ای بی معنی از کاراکترهای لاتین به نظر می رسد.

ویرایشگر صفحه را باز کنید.

محتویات فایل functions.php را در کلیپ بورد کپی کنید.

آن را در هر کدام بچسبانید ویرایشگر متن(نوت بوک).

دستور eval را پیدا کنید.

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

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

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

حفاظت از کدهای مخرب

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

فقط از نرم افزارهای اثبات شده استفاده کنید:

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

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

• ساختاری 12 کاراکتری بیابید که شامل اعداد و حروف با حروف مختلف است.
• رمز عبور منحصر به فرد خود را برای هر سرویس ایجاد کنید.
• رمزهای عبور خود را هر 3 ماه یکبار تغییر دهید.

کنترل ورودی کاربر را در دست بگیرید:

• فیلترهای نشانه گذاری HTML را در فیلدهای ورودی تنظیم کنید که محتوای آنها در کد صفحه گنجانده می شود.
• یک اعتبارسنجی سمت سرور داده های ورودی را برای انطباق با فاصله مجاز سازماندهی کنید.
• از WAF استفاده کنید. Web Application Firewall ابزاری قدرتمند برای محافظت از سایت شما در برابر حملات هکرها است.

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

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

چنین نفوذی از کدهای مخرب بیشتر در معرض آن دسته از سایت هایی است که قابلیت دانلود فایل های کاربر در آنها پیاده سازی شده است.

1. سازماندهی حفاظت در برابر ربات ها. برای این منظور، بسیاری از CMS ها به پلاگین های ویژه مجهز شده اند.

2. تنظیم اعتبار ورودی کاربر:

• از درج کد جاوا اسکریپت در ساختار t> جلوگیری کنید.
• فهرستی از تگ های HTML ایمن را حفظ کنید و ساختارهایی را که در این لیست گنجانده نشده اند فیلتر کنید.
• پیوندهای ارسال شده توسط کاربران را تجزیه و تحلیل کنید.
• برای این وجود دارد خدمات ویژه، مانند Safe Browsing API. این به شما امکان می دهد امنیت یک سند را با URL بررسی کنید.

چگونه از قرار دادن تصادفی کدهای مخرب جلوگیری کنیم.

• نرم افزاری را که استفاده می کنید به دقت کنترل کنید:

کتابخانه‌ها و برنامه‌های افزودنی CMS را فقط از منابع قابل اعتماد و بهتر از همه از سایت‌های رسمی دانلود کنید.

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

• تبلیغات را با دقت زیاد قرار دهید:

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

سعی کنید محتوای ثابت را در صفحه خود قرار دهید.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

آمار

در سه سال گذشته، ما وب‌سایت‌های به اصطلاح پاک (بین 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، پخش کننده ها و غیره.
• یک محصول آنتی ویروس را نصب کنید و همیشه از آن استفاده کنید اینترنت کسپرسکیامنیت 2010
• به عنوان یک قانون از کارمندان خود بخواهید هر ماه چند ساعت را در وب سایت های امنیتی مانند www.viruslist.com بگذرانند، جایی که می توانند در مورد تهدیدات آنلاین و نحوه محافظت از خود بیاموزند.

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

دسته بندی: .

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

این کد مخرب چیست، از کجا می آید و چقدر خطرناک است؟

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

1) یک پیوند مخرب منجر به یک سیستم توزیع ترافیک (TDS) می شود. سیستم توزیع ترافیک به شما این امکان را می دهد که بازدید کننده را بسته به کشور تغییر مسیر دهید. سیستم عامل، مرورگر، زبان مورد استفاده و جزئیات دیگر در مورد منابع مختلف. این منابع به نوبه خود حاوی بدافزار مخصوص این مخاطبان یا این نرم افزار آسیب پذیر هستند. علاوه بر این، اگر روی یک لینک مخرب از یک مرورگر یا نسخه سیستم عاملی که توسط مهاجم مورد نظر نیست کلیک کنید، فقط یک صفحه خالی یا مثلاً یک موتور جستجو خواهید دید. صفحه گوگل. این امر تشخیص بدافزار را کمی دشوارتر می کند. با این حال، با تجزیه و تحلیل دقیق، می توانید منطق سیستم را درک کنید و از خود در برابر عفونت محافظت کنید.
2) یک پیوند مخرب منجر به "اسپویل" برای مرورگرها و محصولات نرم افزاری محبوب می شود. «Sploits» کدهایی هستند که به‌طور ویژه ساخته شده‌اند که از آسیب‌پذیری‌های نرم‌افزاری برای دانلود بی‌صدا و اجرای بدافزار در رایانه کاربر استفاده می‌کنند. در این صورت نرم افزار کاربر مشخص می شود و در صورت آسیب پذیری آن، آلودگی ایجاد می شود.

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

نمونه ای از پیوند مخرب رمزگذاری شده:

بیایید تجزیه و تحلیل کوچکی از ساختار یک پیوند مخرب انجام دهیم:
نام دامنه- bestlotron.cn
اسکریپت- in.cgi (سیستم توزیع ترافیک SUTRA)
طرح- کوکاکولا51

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

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

پس از رمزگشایی، کد زیر را دریافت می کنیم:

اکنون می‌توانیم آدرس سایت و اسکریپت سیستم توزیع ترافیک را که از اولین مثال با طرح 3 برای ما آشنا است، مشاهده کنیم.

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

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

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

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

1) نرم افزار ضد ویروس را بر روی رایانه ای که وب سایت از آن مدیریت می شود، ترجیحا دارای مجوز با پایگاه های اطلاعاتی به روز شده روزانه نصب کنید.
2) نصب و پیکربندی کنید دیواره آتشبه طوری که تمامی ترافیک هنگام کار با شبکه بررسی شده و در صورت دسترسی به هاست های مشکوک، امکان مسدود شدن آن وجود دارد.
3) از رمزهای عبور پیچیده برای رابط های مدیریتی و دسترسی به سرویس های ftp و ssh استفاده کنید.
4) رمزهای عبور را در Total Commander، Far و دیگران ذخیره نکنید فایل منیجرها. به عنوان یک قاعده، تقریبا همه تروجان هاقبلاً می‌دانید چگونه این داده‌ها را جمع‌آوری کرده و به مهاجم ارسال کنید.
5) فایل های دریافتی از طریق ایمیل یا دانلود شده از اینترنت را بدون بررسی اولیه با نرم افزار آنتی ویروس باز و اجرا نکنید.
6) نرم افزار نصب شده روی کامپیوتر را به روز کنید. نصب به موقع وصله ها برای سیستم عامل ها و به روز رسانی نرم افزارهای کاربردی. گاهی اوقات برنامه هایی که به صورت روزانه استفاده می کنید می توانند به عنوان سوراخی در سیستم برای ورود بدافزار عمل کنند. به خصوص Adobe Acrobatخواننده، فلش پلیر، برنامه های بسته MS Office و غیره

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

همانطور که می دانید در سپتامبر 2005 با فرمان رئیس جمهور کشور، سرویس پاسخگویی به حوادث رایانه ای UZ-CERT در ازبکستان راه اندازی شد. متخصصان سرویس علاوه بر وظایف اصلی خود، کار شناسایی کدهای مخرب را در سایت های منطقه دامنه ملی نیز انجام می دهند. برای این منظور، تعدادی برنامه کاربردی برای خودکارسازی نکات اصلی نوشته شده است، اما البته مشاهده دستی وب سایت هایی که مشکوک به آلودگی هستند نیز نقش مهمی دارد. گاهی اوقات کد مخرب با موفقیت پنهان شده است که تحت "تحریک" قرار گرفته است - تغییر در ساختار کد، نمی تواند با ابزارهای خودکار شناسایی شود. اطلاعات مربوط به تمام وب سایت های آلوده شناسایی شده در وب سایت سرویس و همچنین در بخش UZ-CERT در uForum.uz منتشر می شود. صاحبان منابع آلوده هشدارها، توصیه‌ها و کمک‌هایی را برای از بین بردن تهدیدها و محافظت بیشتر از سیستم‌های خود دریافت می‌کنند. ما صمیمانه امیدواریم که این کار برای کاربران اینترنت مفید باشد و به جلوگیری از آلوده شدن انبوه رایانه های شخصی به بدافزار کمک کند.

در Odnoklassniki

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

بخش اول: بررسی اجمالی

XSS چیست؟

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

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

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

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

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

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

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

آخرین نظر:

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

قسمت دوم: حمله XSS

شرکت کنندگان در حمله XSS

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

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

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

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

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

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

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

1. مهاجم از یکی از فرم های وب سایت برای درج یک رشته مخرب در پایگاه داده وب سایت استفاده می کند.
2. قربانی درخواست صفحه ای از یک وب سایت می کند.
3. این سایت شامل یک رشته مخرب از پایگاه داده در پاسخ است و آن را برای قربانی ارسال می کند.
4. مرورگر قربانی یک اسکریپت مخرب را در پاسخ اجرا می کند و کوکی قربانی را به سرور مهاجم ارسال می کند.

انواع XSS

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

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

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

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

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

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

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

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

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

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

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

XSS در DOM

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

1. مهاجم یک URL حاوی یک رشته مخرب ایجاد می کند و آن را برای قربانی ارسال می کند.
2. قربانی مهاجم را فریب می دهد تا یک درخواست URL به یک وب سایت ارسال کند.
3. سایت درخواست را می پذیرد اما رشته مخرب را در پاسخ شامل نمی شود.
4. مرورگر قربانی اسکریپت قانونی موجود در پاسخ را اجرا می کند و باعث می شود اسکریپت مخرب در صفحه درج شود.
5. مرورگر قربانی اسکریپت مخرب درج شده در صفحه را اجرا می کند و کوکی قربانی را به سرور مهاجم ارسال می کند.

تفاوت 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

روش های پیشگیری XSS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

کد نویسی

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

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

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

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

آخرین نظر:

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

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

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

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

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

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

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

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

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

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

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

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

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

اعتبار سنجی

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