امنیت سایت یک محصول نیست که بخرید و نصب کنید؛ مجموعه‌ای از لایه‌های کنترل است که هرکدام هزینه و بازده متفاوتی دارند. مشکل اصلی مالکان سایت هم کمبود اطلاعات نیست، ترتیب است: کاری که ده دقیقه وقت می‌برد و هیچ هزینهی نقدی ندارد اما مسیر اصلی نفوذ را می‌بندد، اغلب انجام نمی‌شود، در حالی که پول قابل توجهی صرف کنترل‌هایی میشود که فقط لایهی پایانی دفاع‌اند. این راهنما همان ترتیب را میدهد: از ارزان‌ترین و مؤثرترین به سمت گران‌ترین و تخصصی‌ترین.
در یک نگاه
- مؤثرترین کنترل ارزان: احراز هویت چندعاملی روی هر پنل مدیریت و هر حساب توسعه‌دهنده.
- پرتکرارترین علت نفوذ سایتهای ایرانی، اجزای به‌روزنشده و پیکربندی نادرست است — نه حمله‌ی هدفمند پیچیده.
- پشتیبانی که بازیابی‌اش آزمون نشده پشتیبان نیست؛ روز حادثه تازه می‌فهمید ناقص است.
- WAF زمان میخرد، اما نسبت به کنترل دسترسی شکسته و منطق کسبوکار ساختاراً نابیناست.
- تست نفوذ زمانی ارزش دارد که پایهها انجام شده باشد؛ وگرنه گزارش پر از یافته‌های بدیهی و ارزان میشود.
چرا ترتیب کارها از فهرست کارها مهم‌تر است
در پروژه‌های واقعی، آنچه یک سایت را از دست میدهد تقریباً هرگز یک تکنیک نادر و پیشرفته نیست. مسیرهای غالب همیشه همان چند مسیر آشناست: یک افزونه یا کتابخانه‌ی وصله‌نشده، یک رمز عبور ضعیف یا بازاستفاده‌شده روی پنل مدیریت، یک پیکربندی سهل‌انگارانه‌ی سرور که فایل پشتیبان یا پوشهی .git را در معرض دید گذاشته، و یک ورودی اعتبارسنجی‌نشده که به پایگاه‌داده می‌رسد.
OWASP در نسخهی ۲۰۲۵ فهرست ریسک خود دو تغییر معنادار داشته که همین را تأیید میکند: پیکربندی نادرست امنیتی از رتبه‌ی ۵ به رتبه‌ی ۲ صعود کرده، و نقص‌های زنجیره‌ی تأمین نرم‌افزار به‌عنوان دسته‌ی A03 وارد فهرست شده. یعنی همان دو مسیری که برای مالک سایت ارزان‌ترین‌اند، در دادهی جهانی هم پرتکرارترین‌اند.
جدول زیر لایه‌ها را به ترتیب بازده به هزینه می‌چیند. اگر از بالا به پایین پیش بروید، در هر مرحله بیشترین ریسک را با کمترین هزینه حذف کرده‌اید.
| لایه | چه چیزی را پوشش میدهد | هزینه | نیاز به تیم فنی |
|---|---|---|---|
| ۱. کنترل دسترسی و MFA پنل مدیریت | سرقت و حدس اعتبارنامه، Credential Stuffing | ناچیز | کم |
| ۲. بهروزرسانی و مدیریت اجزا | سوءاستفاده از CVEهای شناخته‌شده (A03:2025) | کم، اما پیوسته | متوسط |
| ۳. مقاومسازی هاست و پیکربندی | پیکربندی نادرست (A02:2025)، فایلهای افشاشده | کم | متوسط |
| ۴. پشتیبان‌گیری با بازیابی آزمون‌شده | باج‌گیری، خرابی، خطای انسانی | کم تا متوسط | کم |
| ۵. TLS و هدرهای امنیتی | شنود مسیر، بخشی از حملات سمت مرورگر | ناچیز | متوسط |
| ۶. ثبت رخداد و پایش | کشف دیرهنگام نفوذ (A09:2025) | متوسط | متوسط |
| ۷. WAF و محدودسازی نرخ | اسکن انبوه، بهرهجویی خودکار، خرید زمان | متوسط | کم |
| ۸. تست نفوذ و بازبینی کد | کنترل دسترسی، منطق کسبوکار، زنجیره‌ی نقص‌ها | بالا | برون‌سپاری |
«سایت من کوچک است و دادهی ارزشمندی ندارد، پس هدف حمله نیست.» اکثریت قاطع حملات وب هدفمند نیستند: رباتی محدوده‌های IP و دامنه‌ها را اسکن میکند، نسخهی افزونهها را می‌خواند و هر جا الگوی آسیب‌پذیر شناخته‌شده پیدا کند، بهرهجویی خودکار را اجرا میکند. اندازه‌ی کسبوکار شما در این معادله وجود ندارد. ارزش سایت هک‌شده برای مهاجم هم غالباً دادهی شما نیست: هرزنامه، تغییر مسیر SEO، میزبانی صفحه‌ی فیشینگ و استخراج ارز رمزی.
لایه ۱ — کنترل دسترسی و احراز هویت چندعاملی
این ارزان‌ترین و مؤثرترین کاری است که امروز می‌توانید انجام دهید. سه اقدام مشخص:
- MFA روی هر حساب مدیریتی. پنل مدیریت سایت، کنترل‌پنل هاست، پنل ثبت‌کننده‌ی دامنه، حساب ایمیل مرتبط، و حساب مخزن کد. یادآوری: حساب ایمیل مدیر عملاً کلید بازیابی همهی حسابهای دیگر است — اگر آن یکی MFA ندارد، بقیه هم ندارند.
- حساب اختصاصی برای هر نفر، با کمترین سطح دسترسی لازم. حساب مشترک
adminکه چند نفر رمزش را می‌دانند، هم مسئولیت را غیرقابل ردیابی میکند و هم با خروج هر نفر از تیم به یک بدهی امنیتی تبدیل میشود. - حذف فوری حسابهای بیاستفاده. حساب پیمانکار پروژه‌ی سال گذشته یکی از رایج‌ترین نقاط ورود است.
در کنار اینها، سیاست رمز عبور را با راهنمای NIST SP 800-63B هم‌راستا کنید: طول را جدی بگیرید، رمزهای جدید را در برابر فهرست‌های فاش‌شده بررسی کنید، از مدیر رمز عبور پشتیبانی کنید، و اجبار به تعویض دوره‌ای را حذف کنید — این قاعده در عمل کاربران را به رمزهای الگودار و ضعیف‌تر سوق میدهد. یکی از سناریوهای رسمی OWASP در دسته‌ی خطاهای احراز هویت هم دقیقاً همین است: مهاجمان فهرست‌های فاش‌شده را با جهش الگو تنظیم می‌کنند، مثلاً Winter2025 را به Winter2026.
و در نهایت: محدودسازی نرخ ورود و تأخیر تصاعدی روی تلاش‌های ناموفق. اگر پنل مدیریت شما بدون هیچ محدودیتی هزار درخواست ورود در دقیقه را قبول میکند، هیچ سیاست رمزی نجاتتان نمی‌دهد.
لایه ۲ — بهروزرسانی و مدیریت اجزا
با ورود «نقص‌های زنجیره‌ی تأمین نرم‌افزار» به رتبه‌ی A03 در OWASP Top 10:2025، بهروزرسانی از یک کار نگهداری به یک کنترل امنیتی درجه‌یک ارتقا یافته است. برای مالک یک سایت، این لایه سه بخش دارد:
می‌دانید چه چیزی روی سایتتان اجرا میشود؟
فهرست مکتوبی از اینها داشته باشید: نسخهی CMS یا فریم‌ورک، فهرست افزونهها و قالب‌ها با نسخه، نسخهی PHP یا زبان اجرایی، و کتابخانه‌های سمت کلاینت. در پروژه‌های توسعه‌ای، معادل حرفهای این فهرست SBOM است که در زمان بیلد تولید میشود. اگر این فهرست را نداشته باشید، روز انتشار یک CVE بحرانی نمی‌توانید در چند دقیقه بگویید «متأثر هستم یا نه».
وصله‌کردن با یک فرایند، نه با یادآوری ذهنی
- به‌روزرسانی‌های امنیتی را در یک بازه‌ی زمانی مشخص و متعهدشده اعمال کنید — نه «هر وقت رسیدیم».
- افزونهها و قالب‌ها را فقط از منبع رسمی نصب کنید. نسخهی «کرک‌شده» یا فایل دانلودشده از سایتهای واسط، رایج‌ترین شکل آلودگی از پیش‌کاشته است.
- هر جزئی که استفاده نمی‌کنید را حذف کنید، نه غیرفعال. افزونه‌ی غیرفعال هم فایل‌هایش روی سرور است و در برخی موارد قابل فراخوانی مستقیم می‌ماند.
- اجزای رهاشده و بدون نگه‌دارنده را جدی بگیرید. کتابخانه‌ای که دو سال بهروزرسانی نشده، آسیب‌پذیری‌اش هم هرگز رفع نمی‌شود — CWE-1104 دقیقاً همین است.
محیط آزمون پیش از عملیات
دلیل واقعی اینکه تیم‌ها بهروزرسانی نمی‌کنند، ترس از خرابی است؛ راه‌حل یک محیط Staging است. اما یک هشدار: محیط Staging در معرض اینترنت با دادهی واقعی و بدون احراز هویت، خودش یکی از جدی‌ترین یافته‌های تست نفوذ است. آن را با احراز هویت سطح وب‌سرور محافظت کنید و داده را ناشناس‌سازی کنید.
اگر روی وردپرس هستید، جزئیات این لایه در امنیت وردپرس و فهرست الگوهای آسیبپذیری در آسیب‌پذیری‌های وردپرس آمده است. چرخه‌ی کامل شناسایی و رفع را هم در مدیریت آسیبپذیری ببینید.
لایه ۳ — مقاومسازی هاست و پیکربندی
پیکربندی نادرست در نسخهی ۲۰۲۵ فهرست OWASP رتبه‌ی دوم را دارد و در ۱۰۰٪ برنامه‌های آزموده‌شده دیده شده است. خوش‌شانسی ماجرا این است که رفعش تقریباً هیچ‌وقت به تغییر کد نیاز ندارد.
چه چیزی نباید از بیرون قابل دسترسی باشد
- فایلهای پشتیبان.
backup.zip،db.sql،site-old.tar.gzدر ریشه‌ی وب. این یکی از سریع‌ترین راه‌های از دست دادن کل پایگاه‌داده است و با یک اسکن ساده پیدا میشود. - پوشهی
.git. اگر ریشه‌ی وب یک مخزن گیت باشد و پوشهی.gitقابل دسترسی، کل تاریخچه‌ی کد — و اغلب کلیدها و رمزهای داخل آن — قابل بازسازی است. - فایلهای محیطی و پیکربندی:
.env،config.php.bak،web.config، فایلهای.swpجامانده از ویرایشگر. - فهرست‌شدن دایرکتوری. اگر باز کردن یک مسیر، فهرست فایل‌ها را نشان میدهد، عملاً نقشه‌ی سرور را در اختیار مهاجم گذاشته‌اید.
- پنل مدیریت پایگاه‌داده و ابزارهای مدیریتی مثل phpMyAdmin و آدمینر روی مسیر پیش‌فرض و بدون محدودیت IP.
پیام‌های خطا
در محیط عملیاتی، Stack Trace و پیام خطای پرجزئیات را خاموش کنید؛ این پیام‌ها نام و نسخهی دقیق کامپوننت‌ها و ساختار پایگاه‌داده را لو می‌دهند و یکی از سناریوهای رسمی OWASP این است که مهاجم از ساختار اسکیمای افشاشده در پیام خطا برای ساختن تزریق استفاده میکند. کاربر باید پیام عمومی ببیند و جزئیات کامل فقط در لاگ سمت سرور بنشیند.
مجوز فایل‌ها و جداسازی
مجوز نوشتن را به حداقل مسیرهای لازم محدود کنید و اجرای کد در پوشهی آپلود را ببندید. روی هاست اشتراکی، جداسازی حسابها را از میزبان بپرسید: در پیکربندیهای ضعیف، نفوذ به یک سایت روی همان سرور میتواند به سایتهای همسایه هم برسد. اگر سایت شما درآمدزا است، هاست اختصاصی یا VPS با کاربر مجزا از این نظر یک ارتقای امنیتی واقعی است، نه فقط عملکردی.
لایه ۴ — پشتیبان‌گیری که واقعاً کار میکند
پشتیبان‌گیری از حمله جلوگیری نمیکند؛ تفاوت میان «چند ساعت اختلال» و «کسبوکار از دست رفت» را می‌سازد. چهار شرط برای اینکه پشتیبان شما واقعاً پشتیبان باشد:
- خارج از همان سرور. پشتیبانی که روی همان هاست ذخیره میشود، در حمله‌ی باج‌گیری یا خرابی سرور همراه اصل داده از دست می‌رود.
- حداقل یک نسخهی غیرقابل بازنویسی. اگر اعتبارنامه‌ی دسترسی به فضای پشتیبان روی همان سرور آلوده ذخیره شده باشد، مهاجم پشتیبان‌ها را هم پاک میکند. نسخهی فقط-افزودنی یا با نگهداری اجباری، این را حل میکند.
- هم فایل و هم پایگاه‌داده، هم‌زمان. پشتیبان فایل بدون پایگاه‌داده‌ی همان لحظه، بازیابی را ناقص میکند.
- آزمون بازیابی دوره‌ای. این بند از سه بند قبلی مهم‌تر است.
«پشتیبان‌گیری خودکار داریم، پس مشکلی نیست.» تا وقتی یک بازیابی کامل را روی محیط جدا انجام نداده‌اید، نمی‌دانید پشتیبان شما سالم است. رایج‌ترین کشف‌های روز حادثه: فایل‌ها هست اما پایگاه‌داده نیست، پشتیبان از هفته‌ها قبل متوقف شده و هیچ‌کس متوجه نشده، فایل خروجی خراب است، یا نسخهی پشتیبان خودش از قبل آلوده است چون نفوذ ماه‌ها پیش رخ داده بوده. حداقل دو بار در سال یک بازیابی آزمایشی انجام دهید و زمانش را ثبت کنید.
در کنار پشتیبان، یک برنامه‌ی مکتوب پاسخ به رخداد داشته باشید: چه کسی تصمیم میگیرد سایت را از دسترس خارج کند، کدام اعتبارنامه‌ها فوراً چرخانده می‌شوند، و چه چیزی به کاربران گفته میشود. اگر با نشانه‌های نفوذ روبه‌رو شده‌اید، نشانه‌های هک شدن سایت و بازیابی سایت هک‌شده نقطه‌ی شروع درست‌اند.
لایه ۵ — TLS و هدرهای امنیتی
این لایه هزینهی نزدیک به صفر دارد و اغلب نیم‌ساعت کار پیکربندی است. خط پایه:
- TLS 1.3 فعال؛ TLS 1.2 فقط برای سازگاری و محدود به مجموعه‌رمزهای ECDHE با AEAD. TLS 1.0 و 1.1 خاموش — این دو رسماً منسوخ شده‌اند.
- هدایت کامل HTTP به HTTPS و فعال‌سازی
Strict-Transport-Securityباmax-ageطولانی. پیش از افزودنincludeSubDomainsمطمئن شوید همهی زیردامنه‌ها گواهی معتبر دارند. - تمدید خودکار گواهی با پایش انقضا. مدت اعتبار گواهی‌ها در سال‌های اخیر روند کاهشی داشته و تمدید دستی به‌مرور غیرعملی میشود.
- محتوای ترکیبی را حذف کنید: یک اسکریپت یا تصویر که با
http://بارگذاری میشود، بخشی از محافظت را از بین می‌برد.
در سمت هدرها، حداقل مجموعه‌ی مفید: Strict-Transport-Security، X-Content-Type-Options: nosniff، Referrer-Policy، و CSP با دستور frame-ancestors برای Clickjacking. یک نکته‌ی مهم دربارهی CSP: سیاست بر پایه‌ی فهرست دامنه‌های مجاز در عمل تقریباً همیشه دور زده میشود — پژوهش گوگل نشان داد ۱۴ دامنه از ۱۵ دامنه‌ی پرکاربرد در این فهرست‌ها اندپوینت ناامن داشتند. شکل درست، سیاست بر پایه‌ی nonce همراه با strict-dynamic است؛ راه‌اندازی را با حالت Report-Only شروع کنید.
ابزار سنجش این لایه ساده است: هر اسکنر هدر و testssl.sh یا sslyze در چند دقیقه وضعیت را می‌گوید. فهرست ابزارها در ابزارهای امنیت سایت آمده است.
لایه ۶ — ثبت رخداد و پایش
در فهرست ۲۰۲۵ نام این دسته از «پایش» به «هشداردهی» تغییر کرده و این تغییر عمدی است: جمع کردن لاگ بدون سازوکار هشدار، فقط یک آرشیو است. سناریوی مرجع OWASP در این دسته تکان‌دهنده است — رخنه‌ای در یک ارائه‌دهنده‌ی طرح سلامت کودکان که ۳٫۵ میلیون کودک را متأثر کرد و از سال ۲۰۱۳ به‌دلیل نبود لاگ و پایش کشف نشده بود؛ سرانجام یک طرف بیرونی آن را گزارش کرد.
برای یک سایت متوسط، حداقل کاربردی این است:
- ثبت رخدادهای امنیتی با زمینه‌ی کافی: ورود موفق و ناموفق، تغییر رمز، تغییر نقش و سطح دسترسی، عملیات حساس مثل حذف و تغییر مبلغ، و شکست‌های کنترل دسترسی (پاسخ‌های ۴۰۳). موج ناگهانی ۴۰۳ یکی از قوی‌ترین نشانه‌های شمارش خودکار است.
- لاگ خارج از سرور برنامه. اگر مهاجم به سرور دسترسی بگیرد، اولین کارش پاک کردن رد پاست. مسیر ممیزی فقط-افزودنی و ارسال به یک مقصد بیرونی این را حل میکند.
- پرهیز از ثبت دادهی حساس در لاگ مثل رمز و توکن و شماره کارت (CWE-532)، و کدگذاری خروجی لاگ برای جلوگیری از تزریق به لاگ (CWE-117).
- هشدار برای چند رخداد مشخص، نه برای همه‌چیز. سه هشدار مفید که کسی خاموشش نمیکند بهتر از پنجاه هشداری است که همه نادیده می‌گیرند.
پایش خارجی هم ارزان و مفید است: پایش دسترس‌پذیری، پایش تغییر فایلهای حساس، و بررسی وضعیت دامنه در سرویس‌های اعتبارسنجی مرورگرها — که اگر سایت به فهرست سیاه برود سریع مطلع شوید. توضیح این حالت در فهرست سیاه گوگل آمده است.
لایه ۷ — WAF: چه میکند و چه نمیکند
فایروال برنامه‌ی وب یک پروکسی معکوس است که درخواست‌ها را در برابر امضاها، اکتشافی‌ها و قواعد نرخ بررسی میکند. مجموعه‌قواعد مرجع متن‌باز، OWASP Core Rule Set است.
چه چیزی را واقعاً بهتر میکند: خریدن زمان در برابر یک CVE تازه‌منتشرشده تا زمانی که وصله‌ی واقعی را اعمال کنید (وصله‌ی مجازی) — که قابل دفاع‌ترین کاربرد آن است؛ مسدودسازی اسکن انبوه و ترافیک بهرهجویی خودکار؛ محدودسازی نرخ و مدیریت ربات؛ و کم کردن نوفه‌ی لاگ تا حملات واقعی دیده شوند.
«WAF داریم، پس در برابر OWASP Top 10 محافظت شده‌ایم.» WAF نسبت به چند دسته ساختاراً نابیناست: کنترل دسترسی شکسته و IDOR (فایروال نمی‌داند کاربر شماره‌ی ۵ مجاز است رکورد ۷ را ببیند یا نه — و این رتبه‌ی یک فهرست است)، منطق کسبوکار، شرایط مسابقه (هر درخواست به‌تنهایی مجاز است)، بخش عمدهی DOM XSS (بار حمله اغلب در بخش fragment آدرس است که هیچ‌وقت به سرور نمی‌رسد)، و SSRF (درخواست خروجی از مسیر WAF نمی‌گذرد). به‌علاوه قابل دور زدن است و مؤثرترین راه دور زدن، پیدا کردن IP اصلی سرور و اتصال مستقیم به آن است. WAF هرگز نباید به‌عنوان راهکار رفع یک آسیبپذیری کد ثبت شود.
اگر WAF می‌گذارید، دو کار را انجام دهید: IP اصلی سرور را طوری محدود کنید که فقط از طریق WAF قابل دسترسی باشد (وگرنه همهی محافظت با یک درخواست مستقیم دور زده میشود)، و از حالت گزارش‌محور شروع کنید تا قواعد را تنظیم کنید — چون فشار مثبت‌های کاذب معمولاً به کاهش شدت قواعد و در نهایت بی‌اثر شدن آن منتهی میشود.
لایه ۸ — چه زمانی تست نفوذ لازم میشود
لایه‌های یک تا هفت را می‌توان تا حد زیادی خودتان انجام دهید. اما یک محدودیت سخت وجود دارد: هیچ‌کدام از اینها کنترل دسترسی شکسته، نقص منطق کسبوکار و شرایط مسابقه را پیدا نمیکند. اینها نه با اسکنر پیدا می‌شوند و نه با چک‌لیست پیکربندی؛ به آزمونگری نیاز دارند که فرایند کسبوکار شما را بفهمد و عمداً از آن سوءاستفاده کند.
زمان‌های منطقی برای تست نفوذ:
- پیش از راه‌اندازی یک سامانهی جدید که دادهی حساس یا پرداخت دارد — به امنیت سایت جدید نگاه کنید.
- پس از هر تغییر معماری مهم یا افزودن قابلیت حساس مثل درگاه پرداخت، ورود با حساب دیگران، یا آپلود فایل.
- دوره‌ای، حداقل سالی یک‌بار برای سامانه‌های عملیاتی مهم.
- وقتی یک الزام قراردادی یا انطباقی دارید — مثلاً الزام‌های حوزه‌ی پرداخت که آزمون سالانه و آزمون مجدد پس از رفع را می‌طلبند.
- پس از یک رخداد امنیتی، برای اطمینان از اینکه مسیر اصلی نفوذ و مسیرهای مشابه بسته شده‌اند.
پیش از سفارش تست، این پایهها را انجام دهید تا بودجه‌ی تست صرف یافتن موارد بدیهی نشود: به‌روزرسانی‌ها، MFA پنل‌ها، حذف فایلهای افشاشده و خاموش کردن پیام‌های خطای پرجزئیات. برای ارزیابی وضعیت فعلی به‌صورت خودارزیاب، راهنمای بررسی امنیت سایت و چک‌لیست امنیتی را ببینید؛ برای فهرست گام‌به‌گام و اولویت‌دار اقدامات، افزایش امنیت سایت؛ و برای فهم ساختار هزینه، هزینهی امنیت سایت. اگر آماده‌ی ارزیابی حرفهای هستید، تست نفوذ وب پی‌هانتر پوشش آزمون، امتیازدهی شدت و آزمون مجدد رفع را در یک بسته ارائه میدهد.
پرسش‌های متداول
برای امنیت سایت اول از کجا شروع کنم؟
از فعال کردن احراز هویت چندعاملی روی همهی حسابهای مدیریتی — پنل سایت، هاست، دامنه و ایمیل مرتبط. بعد بهروزرسانی همهی اجزا و حذف افزونههای بیاستفاده، سپس بستن فایلهای افشاشده مثل پشتیبان و پوشهی .git. این سه کار هزینهی تقریباً صفر دارند و پرتکرارترین مسیرهای نفوذ را میبندند.
آیا نصب پلاگین امنیتی برای سایت کافی است؟
نه. پلاگین امنیتی چند کار مفید انجام میدهد — محدودسازی نرخ ورود، پایش تغییر فایل، مقاومسازی پیکربندی — اما آسیبپذیری در کد افزونهها و قالب شما را رفع نمیکند و نقص کنترل دسترسی یا منطق کسبوکار را پیدا نمیکند. به آن مثل یک لایهی کمکی نگاه کنید، نه جانشین بهروزرسانی و امنسازی.
چند وقت یک‌بار باید از سایت پشتیبان بگیرم؟
بسته به نرخ تغییر داده. برای فروشگاه یا سایتی با محتوای روزانه، روزانه؛ برای سایت معرفی شرکت، هفتگی کافی است. مهم‌تر از دوره، این سه شرط است: نسخهی پشتیبان خارج از همان سرور نگهداری شود، حداقل یک نسخه غیرقابل بازنویسی باشد، و حداقل دو بار در سال بازیابی را واقعاً آزمون کنید.
آیا فایروال یا WAF جلوی هک شدن سایت را میگیرد؟
بخشی از آن را. WAF اسکن انبوه و بهرهجویی خودکار را خوب مسدود میکند و در برابر یک CVE تازه به شما زمان میخرد. اما نسبت به کنترل دسترسی شکسته، منطق کسبوکار، شرایط مسابقه و بخش عمدهی DOM XSS نابیناست، و اگر IP اصلی سرور از بیرون قابل دسترسی باشد کاملاً دور زده میشود. WAF مکمل امنسازی است، نه جانشین آن.
هاست اشتراکی برای امنیت سایت مشکل دارد؟
در پیکربندیهای ضعیف بله: جداسازی ناکافی حسابها میتواند اجازه دهد نفوذ به یک سایت روی همان سرور به سایتهای همسایه هم برسد. اگر روی هاست اشتراکی هستید، از میزبان دربارهی جداسازی کاربران و نسخهی زبان اجرایی بپرسید. برای سایت درآمدزا، VPS یا هاست اختصاصی با کاربر مجزا یک ارتقای امنیتی واقعی است.
از کجا بفهمم امنسازی سایتم کافی بوده یا نه؟
خودارزیابی میتواند پیکربندی نادرست، اجزای قدیمی، فایلهای افشاشده و ضعف TLS و هدرها را پیدا کند. اما نمیتواند کنترل دسترسی شکسته، نقص منطق کسبوکار و شرایط مسابقه را پیدا کند — اینها به آزمون دستی نیاز دارند. اگر سامانهی شما دادهی حساس یا پرداخت دارد، پس از انجام پایهها یک ارزیابی حرفهای سنجهی واقعی وضعیت است.
منابع
علیرضا کیا
متخصص تست نفوذ وب و اندروید با سابقه‌ی مدیریت تیم نفوذ در داتین. مهندسی معکوس اپ‌ها و کشف ذخیره‌سازی ناامن، تخصص اوست.