تست امنیت سایت شرکت: از بررسی رایگان تا ارزیابی واقعی سطح حمله
صبح شنبه، مدیرعامل یک سؤال ساده می‌پرسد: «سایت ما امن است؟» شما آدرس سایت را در یک سرویس آنلاین رایگان وارد می‌کنید، چند ثانیه بعد یک نمره A سبز می‌بینید و همان را فوروارد می‌کنید. پرونده بسته شد.
مشکل این است که آن نمره به سؤالی جواب داده که کسی نپرسیده بود. تست امنیت سایت شرکت یعنی مشخص کردن اینکه چه چیزی از سازمان شما از بیرون قابل دیدن است، کدام بخش آن قابل سوءاستفاده است، و اگر کسی از آن مسیر وارد شود دقیقاً چه چیزی را از دست می‌دهید. یک ابزار آنلاین بخش کوچکی از این تصویر را می‌بیند و درباره بقیه‌اش ساکت است.
در این مقاله سه چیز روشن می‌شود: ابزارهای رایگان واقعاً چه چیزی را اندازه می‌گیرند، یک ارزیابی جدی چه لایه‌هایی را بررسی می‌کند، و اگر می‌خواهید همین هفته شروع کنید، ترتیب درست قدم‌ها چیست.
تست امنیت سایت یعنی چه — و چه چیزی نیست
تست امنیت سایت یعنی بررسی هدفمند اینکه آیا کسی می‌تواند از طریق وب‌سایت یا سرویس‌های متصل به آن، به داده یا دسترسی‌ای برسد که نباید. این بررسی می‌تواند خودکار باشد، دستی باشد یا ترکیبی از هر دو؛ اما در همه حالت‌ها یک ویژگی مشترک دارد: خروجی آن فهرستی از یافته‌های قابل رسیدگی است، نه یک نمره.
نکته دوم اینکه «سایت» تقریباً هیچ‌وقت فقط یک صفحه نیست. یک وب‌سایت سازمانی معمولاً به پایگاه داده، پنل مدیریت، فرم‌های ارسال اطلاعات، سرویس ایمیل، فضای ابری، افزونه‌ها و گاهی یک API داخلی وصل است. هر کدام از این‌ها یک در جداگانه است. شما یک در را قفل کرده‌اید و بقیه را نشمرده‌اید.
تفاوت «سایت سالم است» با «سایت امن است»
بررسی سلامت سایت به وضعیت ظاهری نگاه می‌کند: گواهی SSL معتبر است؟ سایت بالا است؟ سرعت بارگذاری قابل قبول است؟ این‌ها مفیدند، اما درباره امکان نفوذ چیزی نمی‌گویند.
تست امنیت سؤال دیگری می‌پرسد: اگر کسی عمداً دنبال راه ورود بگردد، چه پیدا می‌کند؟ یک سایت می‌تواند گواهی بی‌نقص و نمره عالی داشته باشد و در همان لحظه پنل مدیریتش با رمز پیش‌فرض روی اینترنت باز باشد. ابزار سلامت‌سنجی نمره خوب می‌دهد؛ مهاجم در دقیقه اول وارد می‌شود. هر دو هم درست عمل کرده‌اند — فقط دو چیز متفاوت را اندازه گرفته‌اند.
ابزارهای رایگان تا کجا کمک می‌کنند؟
ابزارهای رایگان بررسی امنیت سایت بی‌ارزش نیستند. اگر تا امروز هیچ بررسی‌ای نکرده‌اید، همین سطح هم از هیچ بهتر است. فقط باید بدانید محدوده کارشان کجاست.
چه چیزی را واقعاً پیدا می‌کنند
- اعتبار، تاریخ انقضا و پیکربندی گواهی TLS/SSL و پشتیبانی از نسخه‌های قدیمی و ناامن پروتکل.
- نبودِ هدرهای امنیتی رایج مثل HSTS، Content-Security-Policy و X-Frame-Options.
- افشای نسخه نرم‌افزار در پاسخ سرور؛ وقتی نسخه دقیق Nginx، PHP یا WordPress در هدرها یا صفحات خطا دیده می‌شود.
- افزونه‌ها و قالب‌هایی که نسخه آسیب‌پذیر شناخته‌شده‌شان روی سایت نصب است.
- ارجاع سایت به منابع خارجی ناامن یا محتوای مختلط (mixed content).
چرا نمره A معنی «امن» نمی‌دهد
محدودیت این ابزارها ساختاری است، نه کیفی. آن‌ها فقط همان یک دامنه‌ای را که شما وارد کرده‌اید می‌بینند، فقط از بیرون و بدون ورود به حساب کاربری نگاه می‌کنند، و فقط الگوهای از پیش تعریف‌شده را تطبیق می‌دهند. هر چیزی که فهمیدنش نیاز به دانستن منطق کسب‌وکار شما داشته باشد، از دیدشان خارج است.
نمونه‌هایی از چیزهایی که یک اسکن سطحی معمولاً نمی‌بیند:
- نقص در کنترل دسترسی؛ مثلاً کاربر عادی با تغییر یک شناسه در آدرس، فاکتور کاربر دیگر را می‌بیند.
- پنل مدیریت، محیط تست یا سرویس فایل که روی زیردامنه‌ای جدا از دامنه اصلی نشسته است.
- سرویس‌های باز روی سرور که اصلاً وب نیستند؛ مثل پایگاه داده یا دسترسی ریموت مدیریتی.
- اعتبارنامه‌های سازمانی که در نشت‌های قبلی افشا شده‌اند و هنوز روی همان پنل کار می‌کنند.
- فایل پیکربندی، نسخه پشتیبان یا مخزن کدی که سهواً روی وب‌سرور قابل دانلود مانده است.
فهرست OWASP Top 10 هم دقیقاً روی همین شکاف انگشت می‌گذارد: مهم‌ترین ریسک‌های اپلیکیشن‌های وب بیشتر از جنس منطق و دسترسی‌اند تا پیکربندی ظاهری، و تشخیص‌شان بررسی هدفمند می‌خواهد.
یک تست واقعی سه لایه دارد
جدا کردن این سه لایه فقط تقسیم‌بندی فنی نیست؛ هر لایه صاحب متفاوتی در سازمان دارد. لایه اول معمولاً دست تیم توسعه است، لایه دوم دست تیم زیرساخت، و لایه سوم اغلب هیچ صاحبی ندارد — و دقیقاً به همین دلیل خطرناک‌ترین است.
لایه اول: اپلیکیشن
اینجا منطق برنامه بررسی می‌شود. آیا ورودی کاربر پیش از رسیدن به پایگاه داده یا سیستم فایل اعتبارسنجی می‌شود؟ آیا فرآیند ورود در برابر حدس زدن رمز و امتحان کردن اعتبارنامه‌های نشت‌شده مقاوم است؟ آیا کاربری که وارد شده فقط به داده‌های خودش دسترسی دارد؟
پرتکرارترین یافته این لایه معمولاً نقص کنترل دسترسی است؛ همان که در OWASP Top 10 در صدر فهرست ایستاده. این نوع نقص تقریباً هیچ‌وقت با اسکن خودکار پیدا نمی‌شود، چون ابزار نمی‌داند کاربر شماره ۱۲ حق دیدن سفارش شماره ۹۸ را دارد یا نه. این را فقط آدم می‌فهمد.
لایه دوم: سرور و سرویس‌های جانبی
سایت روی چیزی اجرا می‌شود و آن چیز خودش سطح حمله دارد. در این لایه بررسی می‌شود چه پورت‌ها و سرویس‌هایی از اینترنت در دسترس‌اند، نسخه نرم‌افزارها به‌روز است یا نه، و آیا آسیب‌پذیری شناخته‌شده‌ای با شناسه CVE روی آن‌ها اعمال‌شدنی است.
موارد تکراری که در سازمان‌ها زیاد دیده می‌شود: پایگاه داده‌ای که برای «یک تست موقت» به بیرون باز شده و بسته نشده، دسترسی ریموت مدیریتی بدون محدودیت IP، و سرویس انتقال فایلی که سال‌ها پیش نصب شده و کسی یادش نمی‌آید چرا. راهنمای NIST SP 800-115 همین ترتیب را توصیه می‌کند: اول کشف و شناسایی، بعد تحلیل آسیب‌پذیری، و در انتها تأیید عملی.
لایه سوم: چیزهایی که فراموش شده‌اند
این لایه کمترین توجه را می‌گیرد و بیشترین حادثه را می‌سازد. منظور همه چیزهایی است که روزی برای کاری بالا آمده و بعد از یاد رفته: محیط staging که هنوز با داده واقعی کار می‌کند، نسخه قدیمی سایت روی زیردامنه‌ای جدا، فایل پشتیبان پایگاه داده در مسیری قابل دانلود، یا پنل مدیریتی که تنها محافظش این است که آدرسش را کسی نمی‌داند.
پیدا کردن این‌ها برای مهاجم کار سختی نیست. فهرست زیردامنه‌ها، گواهی‌های صادرشده و سرویس‌های شناسایی‌شده روی IP سازمان همگی از منابع عمومی قابل جمع‌آوری‌اند. تفاوت مهاجم و شما در ابزار نیست؛ در این است که او این فهرست را تهیه کرده و شما نکرده‌اید.
شما یک دامنه را تست می‌کنید، مهاجم کل سازمان را
اینجا نقطه‌ای است که تست امنیت سایت به سؤال بزرگ‌تری وصل می‌شود. آنچه سازمان شما را در معرض خطر می‌گذارد مجموعه همه دارایی‌های قابل دسترس از بیرون است: دامنه‌ها و زیردامنه‌ها، سرورها، سرویس‌های ابری، حساب‌های SaaS، اپلیکیشن موبایل و هر چیزی که نام یا زیرساخت شما را حمل می‌کند.
الگوی رایج این است: تیم روی دامنه اصلی تمرکز می‌کند و آن را خوب هم نگه می‌دارد، اما حادثه از مسیری می‌آید که اصلاً در فهرست نبوده. مشکل کیفیت تست نبوده؛ دامنه تست بوده. به این نگاه مجموعه‌ای، مدیریت سطح حمله گفته می‌شود.
سه الگوی تکراری که تست تک‌دامنه‌ای نمی‌بیند
- زیردامنه رهاشده: رکورد DNS به سرویسی اشاره می‌کند که دیگر در اختیار شما نیست. هر کسی که آن سرویس را دوباره ثبت کند، عملاً صاحب زیردامنه شما می‌شود.
- محیط تست یا نسخه قدیمی: بدون به‌روزرسانی، بدون WAF، اغلب با رمز ساده و گاهی با کپی داده واقعی.
- سرویس پروژه تمام‌شده: سروری که برای یک کمپین یا سامانه موقت بالا آمده، هزینه‌اش هنوز پرداخت می‌شود و مسئولش رفته است.
راه‌حل این‌ها تست عمیق‌تر یک سایت نیست؛ کامل کردن فهرست دارایی‌هاست. اگر می‌خواهید ببینید همین امروز چه چیزی از سازمان شما از بیرون قابل مشاهده است، نقطه شروع منطقی یک ارزیابی سطح حمله خارجی است که پیش از هر تست عمیقی، تصویر کامل دارایی‌های در معرض اینترنت را می‌سازد.
چک‌لیست عملی: هفت قدم برای شروع
- فهرست دارایی‌ها را بسازید. همه دامنه‌ها، زیردامنه‌ها، IPها، سرورها و سرویس‌های ابری. اگر این فهرست را ندارید، هر کار بعدی روی حدس بنا شده است.
- برای هر دارایی یک مالک بنویسید. نام یک نفر مشخص، نه نام یک تیم. دارایی بدون مالک همان چیزی است که فراموش می‌شود.
- محدوده و مجوز را مکتوب کنید. تست فقط روی دارایی‌های متعلق به سازمان و با تأیید کتبی. این نکته حقوقی است، نه تشریفاتی.
- یک اسکن خودکار پایه بگیرید. نسخه‌های قدیمی، پیکربندی‌های اشتباه و آسیب‌پذیری‌های شناخته‌شده را همین‌جا بردارید تا وقت بررسی دستی تلف نشود.
- نقاط حساس را دستی بررسی کنید. ورود و بازیابی رمز، مسیرهای پرداخت، آپلود فایل، و هر جایی که کاربر به داده کاربر دیگر نزدیک می‌شود.
- اصلاح کنید و دوباره تأیید بگیرید. یافته‌ای که رفع شده اما دوباره تست نشده، هنوز باز فرض می‌شود.
- دوره تکرار تعیین کنید. و مهم‌تر: قاعده‌ای بگذارید که هر سرویس جدید پیش از انتشار وارد همین چرخه شود.
اولویت‌بندی یافته‌ها: کدام را اول درست کنیم؟
گزارش تست معمولاً بلند است و اگر از بالا شروع کنید، هفته‌ها روی موارد کم‌اهمیت وقت می‌گذارید. امتیاز CVSS به‌تنهایی هم اولویت نیست؛ آن عدد شدت فنی را می‌گوید، نه ریسک شما را. برای هر یافته سه سؤال بپرسید:
- آیا از اینترنت و بدون احراز هویت قابل دسترسی است؟
- آیا روش سوءاستفاده از آن به‌صورت عمومی منتشر شده است؟
- پشت آن چه داده یا چه دسترسی‌ای قرار دارد؟
هر یافته‌ای که به هر سه جواب مثبت بدهد، در صف اول است. ترتیب عملی که معمولاً جواب می‌دهد: اول دسترسی‌های مدیریتی باز روی اینترنت، بعد اعتبارنامه‌های افشاشده و رمزهای پیش‌فرض، بعد آسیب‌پذیری‌های شناخته‌شده با اکسپلویت عمومی، بعد نقص‌های کنترل دسترسی، و در انتها سخت‌سازی‌های پیکربندی.
از تست موردی به پایش مستمر
تست امنیت یک عکس لحظه‌ای است. نتیجه‌اش برای همان روز معتبر است. سازمان شما اما هر هفته تغییر می‌کند: زیردامنه جدید بالا می‌آید، افزونه‌ای نصب می‌شود، سرویسی برای یک پروژه موقت باز می‌ماند و آسیب‌پذیری جدیدی برای نرم‌افزاری که دیروز امن بود منتشر می‌شود.
به همین دلیل سازمان‌هایی که به بلوغ می‌رسند، از تست دوره‌ای به پایش مستمر حرکت می‌کنند: فهرست دارایی‌ها به‌صورت خودکار به‌روز می‌ماند، تغییرات در معرض اینترنت دیده می‌شود و یافته جدید به‌جای اینکه شش ماه بعد در گزارش بعدی ظاهر شود، همان هفته به دست مالکش می‌رسد. این همان کاری است که یک سامانه مدیریت سطح حمله انجام می‌دهد.
پرسش‌های پرتکرار
هر چند وقت یک‌بار باید تست امنیت سایت انجام دهیم؟
قاعده ثابتی وجود ندارد، اما دو محرک عملی هست: یک بازه دوره‌ای (بسته به حساسیت سرویس، معمولاً سالانه یا شش‌ماهه) و هر تغییر مهم — انتشار نسخه جدید، اضافه شدن درگاه پرداخت، مهاجرت سرور یا راه‌اندازی زیردامنه جدید.
می‌توانیم خودمان انجامش دهیم؟
بخشی را بله. ساختن فهرست دارایی، بستن سرویس‌های بی‌استفاده، فعال کردن MFA روی پنل‌ها و به‌روزرسانی نرم‌افزارها کار داخلی است و بیشترین اثر را دارد. بررسی منطق دسترسی و مسیرهای پیچیده سوءاستفاده معمولاً به نگاه بیرونی و تخصص جدا نیاز دارد.
تست نفوذ و اسکن آسیب‌پذیری چه فرقی دارند؟
اسکن آسیب‌پذیری خودکار است، سریع اجرا می‌شود و فهرستی از موارد محتمل می‌دهد. تست نفوذ دستی است و تلاش می‌کند نشان دهد کدام‌یک از آن موارد واقعاً قابل بهره‌برداری است و تا کجا پیش می‌رود. اولی پهنا دارد، دومی عمق.
آیا تست به سایت آسیب می‌زند؟
تست درست‌طراحی‌شده مخرب نیست، اما بی‌اثر هم نیست: اسکن می‌تواند بار اضافه بسازد یا داده تستی در فرم‌ها ثبت کند. به همین دلیل محدوده، زمان اجرا و سطح تهاجم باید از قبل توافق و مکتوب شود.
جمع‌بندی و قدم بعدی
تست امنیت سایت شرکت وقتی ارزش دارد که به سؤال درست جواب بدهد. نمره یک ابزار آنلاین به شما می‌گوید پیکربندی ظاهری‌تان مرتب است؛ چیزی درباره پنلی که فراموش کرده‌اید، زیردامنه‌ای که رها شده یا کاربری که می‌تواند داده کاربر دیگر را ببیند نمی‌گوید.
اگر می‌خواهید همین هفته یک قدم مؤثر بردارید، از فهرست دارایی‌ها شروع کنید: بنویسید چه دامنه‌ها، زیردامنه‌ها و سرویس‌هایی به نام سازمان شما روی اینترنت در دسترس‌اند و هر کدام مال کیست. تقریباً همیشه چند مورد در این فهرست هست که انتظارش را نداشته‌اید — و همان‌ها معمولاً نقطه شروع درست تست هستند.
اگر ترجیح می‌دهید این تصویر را با کمک یک تیم بیرونی بسازید و بعد سراغ تست عمیق بروید، می‌توانید از مشاوره امنیت سایبری امن‌آپس شروع کنید تا محدوده و ترتیب کار متناسب با زیرساخت خودتان مشخص شود.
