SECURITY
چکلیست ممیزی امنیتی سایت و اپلیکیشن: ۱۵ موردی که پیش از هر چیز بررسی کنید
· ۱۰ دقیقه · تیم یازیاپ
آخرین بازبینی محتوایی:
پانزده بررسی عملی برای سنجش امنیت سایت یا اپلیکیشن، از HTTPS و رمزها تا پشتیبانگیری و دسترسیها؛ با توضیح اینکه کدام را خودتان میتوانید انجام دهید و کدام به متخصص نیاز دارد.

پاسخ کوتاه
ممیزی امنیتی یعنی بررسی منظم نقاطی که بیشترین حملهها از آنها انجام میشود: اتصال رمزنگاریشده، تنظیمات سرور، رمزها و دسترسیها، نرمافزارهای قدیمی، ورودی فرمها، و توان بازگشت بعد از حادثه. نیمی از این ۱۵ مورد را خودتان در یک ساعت میتوانید بررسی کنید؛ بقیه به دسترسی به کد و دانش تخصصی نیاز دارد.
بیشتر نفوذهایی که در سایتهای کوچک و متوسط میبینیم، نتیجهی حملهی پیچیده نیستند. افزونهای که دو سال بهروز نشده، رمز مشترک بین چند نفر، پنل مدیریتی با آدرس پیشفرض یا نبود پشتیبان قابل بازیابی؛ اینها مسیرهای رایجاند. خبر خوب این است که بستن همین مسیرها، بخش بزرگی از ریسک را کم میکند.
این چکلیست بر اساس همان مواردی تنظیم شده که در ممیزی امنیتی یازیاپ بررسی میکنیم و با فهرست رایجترین آسیبپذیریهای وب که بنیاد OWASP منتشر میکند همراستاست. آن را به ترتیب اولویت بخوانید.
بخش اول: بررسیهایی که خودتان میتوانید انجام دهید
این هفت مورد به دسترسی فنی عمیق نیاز ندارند. با مرورگر، پنل مدیریت سایت و پنل هاست قابل بررسیاند. اگر یکی از آنها را نمیدانید، همین نداستن یک یافته است.
- ۱. HTTPS روی همهی صفحات فعال است و نسخهی http به https هدایت میشود
- ۲. گواهی SSL معتبر است و تمدید خودکار دارد
- ۳. هر نفر حساب کاربری جدا دارد؛ هیچ رمز مشترکی نیست
- ۴. ورود دومرحلهای برای پنل مدیریت، هاست و ایمیل اصلی فعال است
- ۵. حسابهای کارمندان یا پیمانکاران سابق حذف شده است
- ۶. هسته، قالب و همهی افزونهها بهروزند و افزونهی استفادهنشده حذف شده
- ۷. پشتیبان خودکار وجود دارد و دستکم یکبار بازیابی آن امتحان شده است
بخش دوم: بررسیهایی که به متخصص نیاز دارند
این هشت مورد به شناخت سرور، کد یا ابزارهای تخصصی نیاز دارند. اگر سایتتان فروشگاهی است، اطلاعات کاربر نگه میدارد یا پنل کاربری دارد، این بخش را جدی بگیرید.
- ۸. هدرهای امنیتی (مثل HSTS، Content-Security-Policy و X-Frame-Options) تنظیم شدهاند
- ۹. ورودی فرمها در سمت سرور اعتبارسنجی میشوند، نه فقط در مرورگر
- ۱۰. در برابر تزریق SQL و اسکریپت (XSS) محافظت وجود دارد
- ۱۱. محدودیت تعداد درخواست برای ورود و فرمها وجود دارد
- ۱۲. رمزها با الگوریتم مناسب هش شدهاند و کلیدها در کد نیستند
- ۱۳. هر کاربر فقط به دادهی خودش دسترسی دارد (کنترل دسترسی سمت سرور)
- ۱۴. کتابخانهها و وابستگیها آسیبپذیری شناختهشده ندارند
- ۱۵. خطاها لاگ میشوند و پیام خطا اطلاعات داخلی را به کاربر نشان نمیدهد
اولویتبندی: از کجا شروع کنیم؟
اول مواردی که اگر خراب باشند، کل سایت را در دسترس مهاجم میگذارند: رمزها، دسترسیها و نرمافزار قدیمی. بعد مواردی که بازگشت را ممکن میکنند: پشتیبان. بعد بقیه.
در گزارش ممیزی یازیاپ یافتهها در سه دسته میآیند: فوری، مهم، بعداً. این تقسیمبندی کمک میکند بودجهی محدود را درست خرج کنید. جدول زیر نمونهای از این اولویتبندی برای همین ۱۵ مورد است. در هر سایت بسته به نوع آن ممکن است جابهجا شود.
| اولویت | موارد | چرا |
|---|---|---|
| فوری | ۳، ۴، ۵، ۶، ۱۰، ۱۳ | مستقیم به نفوذ یا دسترسی غیرمجاز به داده منجر میشوند |
| مهم | ۱، ۲، ۷، ۹، ۱۱، ۱۲، ۱۴ | ریسک را بالا میبرند یا بازگشت بعد از حادثه را ناممکن میکنند |
| بعداً (ولی لازم) | ۸، ۱۵ | لایهی دفاعی اضافه و امکان پیگیری حادثه |
پشتیبان: موردی که همه دارند تا روزی که لازم شود
بیشتر مدیران سایت میگویند پشتیبان دارند. سؤال درست این است: آخرین بار کی آن را بازیابی کردهاید؟ پشتیبانی که هرگز امتحان نشده، فقط یک فرض است. گاهی فایل ناقص است، گاهی پایگاه داده جدا ذخیره نشده و گاهی پشتیبان روی همان سروری است که از دست رفته.
قانون سادهای که توصیه میکنیم: دستکم یک نسخهی پشتیبان بیرون از سرور اصلی، نگهداری چند نسخهی قدیمیتر برای وقتی که مشکل دیر کشف شده، و بازیابی آزمایشی هر چند ماه یکبار.
اپلیکیشن موبایل: چند نکتهی اضافه
در اپلیکیشن، بخش بزرگی از امنیت در سرور یا API است، نه خود اپ. هر چیزی که در اپ است، با کمی تلاش قابل استخراج است؛ پس کلید API محرمانه، رمز پایگاه داده یا منطق قیمتگذاری نباید در کد اپ باشد.
API باید هر درخواست را جداگانه احراز هویت کند و بررسی کند که کاربر اجازهی همان کار را دارد. اپهایی که فقط در رابط کاربری دکمهها را پنهان میکنند و در سرور کنترل ندارند، رایجترین مورد آسیبپذیریاند که میبینیم.
ممیزی پایه یا کامل؟
ممیزی پایه از بیرون و بدون دسترسی به کد انجام میشود و برای سایتهای معرفی و فروشگاههای کوچک نقطهی شروع خوبی است. ممیزی کامل با دسترسی به کد و سرور، وابستگیها و منطق دسترسی را هم بررسی میکند. هیچکدام آزمون نفوذ تهاجمی یا مهندسی اجتماعی نیستند و رفع مشکلات هم جدا قیمت داده میشود.
| نوع | دسترسی | هزینه | خروجی |
|---|---|---|---|
| ممیزی پایه | بیرونی، بدون کد | ۶٬۹۰۰٬۰۰۰ تومان | امنیت و هدرها، سرعت و سئوی فنی، گزارش مکتوب |
| ممیزی کامل | با دسترسی به کد و سرور | ۱۸٬۹۰۰٬۰۰۰ تومان | بهعلاوهی بازبینی کد و وابستگیها و جلسهی توضیح ۱ ساعته |
بعد از ممیزی چه کنیم؟
گزارش ممیزی وقتی ارزش دارد که موارد آن اولویتبندی و رفع شوند و چند ماه بعد دوباره بررسی شوند.
خروجی ممیزی امنیتی معمولاً فهرستی از یافتههاست که هر کدام سطح خطری دارد. اشتباه رایج این است که همه را با هم شروع کنید یا گزارش را در پوشهای بگذارید و فراموش کنید. بهتر است موارد پرخطر، مثل دسترسی بدون احراز هویت به داده یا رمزهای پیشفرض، در همان هفته رفع شوند و بقیه در یک برنامهی زمانی مشخص قرار بگیرند.
برای هر یافته یک مسئول و یک تاریخ تعیین کنید. اگر تیم داخلی ندارید، رفع موارد را از همان تیمی بخواهید که سایت را ساخته یا به تیم دیگری بسپارید؛ مهم این است که بعد از رفع، کسی دوباره بررسی کند که مشکل واقعاً برطرف شده است.
امنیت یک کار یکباره نیست. کتابخانهها و افزونهها مرتب آسیبپذیری تازه پیدا میکنند، کارکنان عوض میشوند و امکانات جدید به سایت اضافه میشود. برای سایتهایی که پرداخت یا اطلاعات شخصی مشتری را نگه میدارند، تکرار ممیزی بهصورت دورهای و بعد از هر تغییر بزرگ منطقی است.
در کنار ممیزی، دو کار ساده بیشترین اثر را دارند: پشتیبانگیری منظم که بازگردانی آن واقعاً آزمایش شده باشد، و حذف دسترسی کسانی که دیگر با شما کار نمیکنند. این دو مورد در بسیاری از حادثهها فرق بین یک روز دردسر و از دست رفتن کامل داده است.
- رفع فوری موارد پرخطر
- تعیین مسئول و تاریخ برای هر یافته
- بررسی دوباره بعد از رفع
- آزمایش واقعی بازگردانی پشتیبان
ممیزی را از چه کسی بخواهیم؟
ممیزی را ترجیحاً از تیمی بخواهید که سایت را نساخته است؛ چشم تازه چیزهایی را میبیند که سازنده به آن عادت کرده است.
تیم سازندهی سایت معمولاً بهترین شناخت را از کد دارد، اما همین شناخت باعث میشود فرضهایش را بررسی نکند. ممیز مستقل از نگاه یک مهاجم شروع میکند و سؤالهایی میپرسد که در زمان ساخت مطرح نشدهاند.
پیش از شروع، دامنهی ممیزی را مکتوب کنید: کدام آدرسها، کدام بخشهای پنل، آیا آزمون نفوذ فعال هم انجام میشود یا فقط بررسی تنظیمات و کد؟ همچنین مشخص کنید آزمون روی نسخهی اصلی انجام میشود یا نسخهی آزمایشی، تا فروش واقعی تحت تأثیر قرار نگیرد.
گزارش خوب، فقط فهرست مشکل نیست؛ برای هر یافته توضیح میدهد چطور بازتولید میشود، چه خطری دارد و پیشنهاد رفعش چیست. اگر گزارشی فقط خروجی خام یک ابزار خودکار است، ارزش آن محدود است.
سؤالهای پرتکرار
ممیزی امنیتی به دادههای سایت آسیب میزند؟
خیر. بررسی آسیبپذیریهای رایج بدون آسیب به داده انجام میشود و پیش از شروع، مجوز بررسی امضا میشود.
چقدر طول میکشد؟
بررسی معمولاً ۳ تا ۷ روز کاری طول میکشد و بعد از آن جلسهی توضیح گزارش برگزار میشود.
رفع مشکلات هم با شماست؟
رفع مشکلات اختیاری است و پیشنهاد جدا دارد؛ گزارش را میتوانید به تیم فعلیتان هم بدهید.
هر چند وقت یکبار ممیزی لازم است؟
بعد از هر تغییر بزرگ و در غیر این صورت سالی یکبار توصیه میشود؛ موارد بخش اول را هر ماه خودتان مرور کنید.
قدم بعدی
بخش اول چکلیست را همین امروز مرور کنید. اگر به مورد نامطمئنی رسیدید یا سایتتان اطلاعات کاربر نگه میدارد، صفحهی ممیزی امنیتی را ببینید. برای اینکه بعد از ممیزی هم از قطعیها باخبر شوید، مانیتورینگ آپتایم مکمل خوبی است.