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

چارچوب چهارلایه امنیت وب

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

لایههدف مهاجمنمونه دفاع
ورودیدسترسی به حساب مدیررمز قوی، 2FA، محدودسازی لاگین
ترافیکارسال درخواست مخربفایروال، فیلتر ربات، WAF
فایل و کداجرای کد مخرببه‌روزرسانی، اسکن بدافزار
بازیابیاز بین بردن دادهبکاپ، لاگ، بازگردانی تست‌شده

این چارچوب، ستون فقرات هر پروژه امنیتی من است. در راهنمای امنیت وردپرس همین چارچوب را با جزئیات وردپرسی باز کرده‌ام. ولی امنیت وب گسترده‌تر از وردپرس است؛ بخش‌های بعدی همین چهار لایه را در فضای کلی وب می‌کاوند.

امنیت، نه یک افزونه است و نه یک نصب یک‌بار برای همیشه؛ یک چرخه پیوسته است که در هر تغییر، دوباره به‌روز می‌شود.

لایه ورودی: رمز عبور، احراز هویت، دسترسی

لایه اول، همان‌جایی است که بیشترین حملات موفق از آن شروع می‌شود. در تجربه‌ام، تقریباً هیچ هکی از یک حفره صفر روز (Zero Day) شروع نشده؛ از رمز تکراری، حساب فراموش‌شده، یا نبود 2FA (Two-Factor Authentication) شروع شده. سه حرکت اساسی:

  1. رمز عبور یکتا: هر حساب، رمز متفاوت. مدیریت رمز با ابزار تخصصی، نه با فایل متنی روی میز.
  2. 2FA روی همه حساب‌های مدیریتی: حتی برای سایت شخصی. اثرش را در چگونه 2FA امنیت را بالا می‌برد سنجیده‌ام.
  3. محدودسازی ورودهای ناموفق: پنج تلاش خطا، ده دقیقه قفل. ساده‌ترین و مؤثرترین ابزار در برابر Brute Force.

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

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

لایه ترافیک: فایروال و مدیریت ربات‌ها

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

  • فایروال ابری: پیش از رسیدن ترافیک به سرور شما، فیلتر می‌کند. بار فیلترینگ از سرور شما برداشته می‌شود. نیاز به تغییر DNS دارد و تنظیم دقیق می‌خواهد.
  • فایروال سروری: روی خود سرور اجرا می‌شود. کنترل کامل، ولی مصرف CPU دارد. روی هاست‌های اشتراکی ضعیف، گاهی خودش به گلوگاه تبدیل می‌شود.

در پروژه‌ها، از ترکیب هر دو استفاده می‌کنم: فایروال ابری برای جلوگیری از حملات حجیم (مانند DDoS (Distributed Denial of Service))، و فایروال سروری برای قوانین ظریف‌تر. مقایسه دقیق در فایروال ابری در برابر سنتی و راهنمای عملی در فایروال نرم‌افزاری در سرور آمده است.

بخش دیگر این لایه، مدیریت ربات‌هاست. ربات‌های جستجوگر مفیدند، ولی ربات‌های اسپم و اسکرپر (Scraper)، منابع سرور را می‌بلعند. تنظیم robots.txt درست و استفاده از سرویس‌های CAPTCHA (Completely Automated Public Turing test) در فرم‌ها، دو حرکت ساده ولی مؤثر هستند.

در لایه ترافیک، سادگی بهترین دوست شماست؛ هر قاعده اضافه‌ای که دلیلش را نمی‌دانید، خودش یک ریسک است.

لایه فایل و کد: دست‌کاری، تزریق، اجرا

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

تزریق SQL (SQL Injection)

وقتی کد شما ورودی کاربر را بدون پاک‌سازی به کوئری SQL می‌چسباند، مهاجم می‌تواند کل دیتابیس را بخواند، تغییر دهد یا پاک کند. دفاع: استفاده از Prepared Statement، اعتبارسنجی ورودی، و اجتناب از چسباندن مستقیم رشته‌ها در کوئری. راهنمای کامل در SQL Injection چیست و چگونه جلوگیری کنیم و جلوگیری از SQLi با Prepared Statement آمده است.

XSS (Cross-Site Scripting)

وقتی کد شما خروجی کاربر را بدون پاک‌سازی نمایش می‌دهد، مهاجم می‌تواند اسکریپت مخرب تزریق کند. دفاع: خروجی‌ها را با توابع escape مناسب پاک‌سازی کنید، Content Security Policy فعال کنید، و ورودی‌ها را اعتبارسنجی کنید. مسیر تفصیلی در XSS چیست و چگونه دفع می‌شود و جلوگیری از XSS در برنامه‌های وب.

CSRF (Cross-Site Request Forgery)

وقتی سایت شما فرمی دارد که بدون تأیید هویت کاربر، عملی انجام می‌دهد، مهاجم می‌تواند کاربر را فریب دهد تا آن عمل را انجام دهد. دفاع: استفاده از توکن CSRF در همه فرم‌ها. در وردپرس، این کار با nonce انجام می‌شود؛ راهنمای کامل در نانس وردپرس و امنیت فرم‌ها و CSRF چیست و چگونه از آن جلوگیری کنیم.

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

لایه بازیابی: بکاپ، لاگ، بازگردانی

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

  1. بکاپ آفلاین تست‌شده: حداقل یک نسخه در سروری جدا از سایت. راهنمای کامل در بکاپ وردپرس.
  2. لاگ فعالیت: چه کسی چه‌کار کرد؟ در مواقع حادثه، لاگ‌ها ریشه را سریع‌تر نشان می‌دهند.
  3. تمرین بازگردانی: بکاپی که بازیابی‌اش تمرین نشده، بکاپ نیست.

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

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

سه حمله پرتکرار و راه دفاع

فارغ از سه حمله لایه فایل، چند حمله دیگر هم رایج هستند که در پروژه‌ها زیاد می‌بینم:

حملههدفدفاع اصلی
Brute Forceحدس رمز عبورمحدودسازی لاگین + 2FA
DDoSاز کار انداختن سرورفایروال ابری + CDN
Phishingفریب کاربر برای افشای اطلاعاتآموزش کاربران + SPF/DKIM/DMARC

Brute Force و DDoS را در پست‌های جداگانه باز کرده‌ام: حمله Brute Force و روش‌های مقابله و حمله DDoS و راه دفاع. Phishing به آموزش انسانی وابسته است، ولی بخش فنی آن با تنظیم رکوردهای ایمیل (SPF، DKIM، DMARC) تقویت می‌شود؛ راهنما در DMARC چیست.

امنیت به‌عنوان عادت، نه پروژه

خطای رایج این است که امنیت را به‌عنوان یک پروژه یک‌بار برای همیشه ببینیم. تجربه من از صدها پرونده نشان می‌دهد امنیت واقعی، مجموعه‌ای از عادت‌های کوچک است که هر ماه تکرار می‌شوند:

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

این پنج عادت، به‌تنهایی از ۹۰٪ حملات جلوگیری می‌کنند. برای بحث کلی‌تر اشتباهات امنیتی، پست اشتباهات رایج امنیت وب را ببینید. اگر شک دارید سایت هک شده یا نه، نشانه‌ها را در چگونه بفهمم سایتم هک شده آورده‌ام.

جمع‌بندی راهبردی

امنیت وب در سه جمله خلاصه می‌شود: در لایه ورودی، رمز قوی و 2FA؛ در لایه ترافیک، فایروال مناسب با نیاز سایت؛ در لایه فایل، اعتماد نکردن به ورودی کاربر؛ و در لایه بازیابی، بکاپ تست‌شده. اگر این چهار لایه را با عادت‌های ماهانه ترکیب کنید، امنیت سایت شما از سطح «قبول» به سطح «مقاوم» می‌رسد. تجربه من این است: سایت‌هایی که هک می‌شوند، تقریباً همیشه یکی از این چهار لایه را رها کرده‌اند. توصیه عملی: از همین امروز، یک بازبینی چهارلایه‌ای انجام دهید و ببینید کدام لایه ضعیف‌تر است. اگر تجربه‌ای از یک حمله واقعی دارید که در این چارچوب نمی‌گنجد، در دیدگاه‌ها بنویسید. 🛡️