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

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

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

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

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

همانطور که مشاهده میکنید ، اگر صفحه را به صورت عادی اجرا کنید ، تنها با دانستن مقادیر درست رمز عبور میتوانید با پیغام Welcome to system مواجه شوید . آیا نفوذگر میتواند رمز عبور درست را از میان هزاران رمز دیگر ، حدس بزند ؟ این به واقع غیر ممکن به نظر میرسد . چرا ؟ زیرا طراح خوب ، رمز عبور را توسط الگوریتم MD5 ، هش کرده است و امتحان کردن رمزهای پیاپی نیز کمکی به نفوذگر نمیکند و حتی اسکنرهای قدرتمند Netsparker نیز که مخصوص اسکن web application ها هستند نیز دچار سردرگمی و ارسال اطلاعات اشتباه به نفوذگر میشوند .

همانطور که مشاهده میکنید ، پس از مقداردهی درست ، رمز عبور متغیر Admin برابر با ۱ شده و ادمین ، تایید هویت میشود و پس از بررسی این متغیر ، در صورت درست بودن ( برابر با ۱ بودن ) پیام خوشامدگویی ظاهر میشود و در غیر این صورت ، پیام رمز اشتباه است دیده میشود . مساله روشن میشود ، تنها کاری که نفوذگر باید انجام دهد این است که مقدار ۱ را به متغیر ادمین بدهد . چگونه ؟ به تصویر زیر دقت کنید :

نفوذگر با نوشتن کدی مانند کد بالا ، و دادن حتی رمز اشتباه و فقط با فهماندن مقدار ۱ به متغیر ادمین میتواند به عنوان مدیر سایت ، وارد شود . نفوذگر این کد و اغلب کدهایی را که هدف آن ، قبولاندن اطلاعات فیک و جعلی به متغیرهای معیوب است ، با استفاده از روش POST و مقداردهی مقادیر به متغیرها ، مقادیری را به سمت Login . Php ارسال میکند . صفحه Login . Php ابتدا رمز عبور ارسالی را بررسی میکند و به سرعت درمیابد که رمز عبور اشتباه است و متغیر ادمین نیز مقداردهی نمیشود . در خطوط بعدی ، مقدار متغیر ادمین مورد بررسی قرار میگیرد که برابر با ۱ میشود . زیرا بعد از اجرای کد ، exploit.php ، در یکی از خطوط به صورت مخفی ، متغیری با نام Admin ، مقدار ۱ را با خود حمل میکند و این مقدار را به Login . Php میرساند . در صفحه Login . Php نیز ، متغیر ادمین بدون توجه به مقدار رمز وارد شده ، برابر ۱ میشود و سیستم نیز پیغام Welcome to system را به نفوذگر هدیه میدهد .

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

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

مورد دیگری که میتوان به آن اشاره کرد ، پیمایش دایرکتوری ها هستند که یکی از خطرناکترین موارد امنیتی در وردپرس و تمام CMC های PHP است . هدف اصلی پیمایش دایرکتوری ، فراخوانی و خواندن فایلها و مقادیری است که نفوذگر به صورت عادی از دیدن و خواندن آنها محروم است . با استفاده از این نوع آسیب پذیریها میتوان به هدف بزرگتری مانند CMD.EXE نیز دست یافت . توابعی که با مقداردهی نامناسب میتوانند بستری مناسب برای این اقدام را ایجاد نمایند ، عبارت هستند از : Require و ، Require_once و include once و include و Fopen و More .

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

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

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *