تست نفوذپذیری روی قالب وب‌سایت

سلام

مقاله ای در این زمینه برای Hiva.ir نوشتم که گفتم خوبه توی وبلاگ خودم هم منتشرش کنم.

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

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

website-audit-kit-landing

استفاده از فایل‌های محلی

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

اما علت این کار چیست؟
علتش این است که ممکن است سازندگان این قالب افراد خبیثی باشند که بعد از مدتی سورس فایل‌های جاوااسکریپت را آن گونه که دوست دارند تغییر دهند و کمترین کاری که می‌شود با آن انجام داد دیفیس سایت‌ها است. در حالتی دیگر ممکن است سرور سایت اصلی هک شود؛ یعنی هکر یک سرور را هک می‌کند و همزمان تمام سایت‌هایی که به آن سرور وابسته‌اند را مورد حمله قرار می‌دهد. جاوااسکریپت به قدری قدرتمند هست که بتوان با آن سایت و سرور شما را به صورت کامل مورد حمله قرار داد.

به روز رسانی فایل‌های قالب و ماجرای هک یاهو در سال ۲۰۱۳

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

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

آخرین‌تلاش: استفاده از اسکنرهای XSS

اگر تمام فایل‌های یک قالب به صورت محلی بارگذاری شوند به احتمال زیاد بیشترین تهدیدی که می‌تواند امنیت قالب را به چالش بکشد حملات XSS خواهد بود. چون قالب مجموعه‌ای از کدهای html, javascript و CSS هاست و حملات XSS هم به خاطر عدم پاکسازی ورودی‌ها در فایل‌های جاوااسکریپت است. (برای مطالعه بیشتر و نحوه‌ی پاکسازی ورودی‌ها به صفحه‌ی OWASP Persian Translation Project مراجعه کنید)

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

گروه امنیتی Minded Security روی DOM Based XSS یک سری تحقیقات اساسی انجام داده است و در حال حاضر روی دو پروژه برای بهبود و کمک به DOM Based XSS کار می کنند:
۱- ابزار DOMinator- که یک ابزار تجاری بوده و روی مرورگر فایرفاکس نصب می‌شود. این ابزار موتور جاوااسکریپت Spidermonkey را به نحوی تغییر داده است که می‌توان از آن برای شناسایی و تایید رخنه ی DOM Based XSS بهره برد.
لینک: https://dominator.mindedsecurity.com
۲- ویکی DOM XSS- که مشغول به ساخت مرجعی کامل در این خصوص اند ولی هنوز جای کار دارد.
لینک: http://code.google.com/p/domxsswiki
۳- DOM Snitch- یک افزونه‌‌ی کروم است که برای توسعه دهندگان و نفوذگران این امکان را فراهم می‌سازد که شیوه‌های رایجی که در کدهای سمت کلاینت آسیب پذیراند را شناسایی کند. این ابزار توسط گوگل پشتیبانی می‌شود:
لینک: http://code.google.com/p/domsnitch

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