تست امنیت وب‌سایت چگونه انجام می‌شود و از کجا باید شروع کرد؟

اولین بار که قرار شد تست امنیت یک سایت را خودم انجام دهم، فکر می‌کردم با نصب یک اسکنر و زدن دکمه Scan کار تمام می‌شود. سه ساعت بعد، در لاگ WAF (Web Application Firewall) شاهد اسکن‌های خودکار بودم که قربانیانه به سایت مشتری هجوم می‌آوردند و در عوض، حفره‌ای که دو هفته بعد از راه افتادن سایت به‌عنوان نقطه ورود واقعی استفاده شد، در گزارش آن اسکنر اصلاً دیده نشده بود. آن روز فهمیدم تست امنیت، یک کلیک نیست؛ یک پروتکل چندفازی است که در آن ابزار فقط یک لایه است. این مقاله از دید کسی نوشته شده که سال‌ها تست امنیت وب‌سایت انجام داده و یاد گرفته که تفاوت بین تست آماتور و تست حرفه‌ای، نه در ابزار، که در روش است.

تست امنیت وب‌سایت دقیقاً چه معنایی دارد؟

تست امنیت وب‌سایت (Website Security Testing) به مجموعه‌ای از فعالیت‌های فنی گفته می‌شود که هدفشان کشف و ارزیابی آسیب‌پذیری‌ها، ضعف‌های پیکربندی و خطاهای منطقی در یک برنامه وب است. هدف نهایی این تست، نه فقط پیدا کردن حفره‌ها، بلکه پاسخ به یک پرسش کاربردی است: اگر یک مهاجم با انگیزه امروز به این برنامه حمله کند، چه چیزی بدست می‌آورد؟

این تعریف سه ضلع مهم دارد که در ادامه روی هر سه کار می‌کنیم:

1. ضلع فنی: آسیب‌پذیری‌های کلاسیک مثل تزریق SQL، XSS (Cross-Site Scripting)، CSRF (Cross-Site Request Forgery) و IDOR (Insecure Direct Object Reference). اگر با این دسته آشنا نیستید، ابتدا آسیب‌پذیری وب چیست و انواع آسیب‌پذیری‌های رایج وب را بخوانید.
2. ضلع منطقی: آسیب‌پذیری‌هایی که از قواعد کسب‌وکار ناشی می‌شوند. مثلاً فرمی که با پارامترهای دست‌کاری‌شده تخفیف بی‌جا اعمال می‌کند.
3. ضلع عملیاتی: پیکربندی سرور، TLS، هدرهای امنیتی، دسترسی‌ها و سرسختی‌سازی زیرساخت. مرور کلی این لایه در امنیت وب چیست و چه اصولی دارد آمده است.

تست امنیت با تست عملکرد (Performance) یا تست کاربر (UX Testing) تفاوت بنیادی دارد: در آن دو، ما به دنبال تجربه بهتر هستیم؛ در تست امنیت، به دنبال یافتن مسیرهایی هستیم که طراح یا توسعه‌دهنده پیش‌بینی نکرده. به همین دلیل، این رشته در ادبیات مهندسی، ذیل تفکر خصمانه (Adversarial Thinking) دسته‌بندی می‌شود.

تست امنیت، نه تأیید ایمنی است و نه ضمانت. تنها ادعایی که می‌توان از آن داشت این است: در این بازه، با این محدوده، این تیم، این حفره‌ها را پیدا کردیم. بقیه فضا، نامعلوم است.

چرا تست امنیت، پروژه است نه اسکن؟

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

• اسکنرهای خودکار، آسیب‌پذیری منطقی را نمی‌فهمند. یک اسکنر می‌تواند بگوید کوئری X تزریق‌پذیر است یا هدر Y تنظیم نشده، اما نمی‌تواند بگوید فرم ثبت‌نام اجازه می‌دهد با یک ایمیل مشابه یونیکد، دو حساب بسازی که بعداً در بازیابی رمز با هم قاطی شوند.
• اسکنرها حجم بالایی از هشدار کاذب تولید می‌کنند. در تجربه من، بیش از نیمی از یافته‌های اسکنرهای پیش‌فرض، یا false positive هستند یا ریسک پایین دارند. بدون مهندس باتجربه، این حجم هشدار، به بی‌توجهی تیم به همه گزارش می‌انجامد.
• اسکنر نمی‌تواند سناریوهای چندمرحله‌ای بسازد. حمله واقعی معمولاً از چند گام ساخته می‌شود: کشف یک اطلاعات کوچک در مرحله اول، استفاده از آن در مرحله دوم، و اجرای اثر نهایی در مرحله سوم. اسکنر در هر مرحله جدا عمل می‌کند.

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

سه مدل تست: Black-box، White-box، Gray-box

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

در پروژه‌های واقعی، اکثر تست‌ها از جنس Gray-box هستند: تیم تست یک حساب کاربری در اختیار دارد، مستندات کلی معماری را می‌داند، اما به کد منبع دسترسی ندارد. مزیت این مدل، کشف آسیب‌پذیری‌هایی است که فقط با دسترسی به یک حساب کاربری معمولی قابل مشاهده‌اند — که دقیقاً همان شرایطی است که اکثر مهاجمان در دنیای واقعی تجربه می‌کنند.

انتخاب مدل، بر اساس هدف تست تعیین می‌شود. اگر هدف پاسخ به این پرسش است که آیا سیستم در برابر حمله واقعی مقاوم است، Black-box یا Gray-box انتخاب درست است. اگر هدف این است که همه ضعف‌های ممکن در کد کشف شود، White-box لازم است.

فاز صفر: تعریف محدوده و قواعد تعامل

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

سند محدوده باید صریحاً به این پرسش‌ها پاسخ دهد:

• کدام دامنه‌ها و زیردامنه‌ها در محدوده هستند؟ صراحت لازم است، چون یک زیردامنه فراموش‌شده می‌تواند نقطه ورود کل تست شود.
• کدام IPها یا بخش‌های زیرساخت باید از محدوده خارج شوند؟ مثلاً اگر سایت روی یک CDN مشترک است، بعضی تست‌ها باید محدود شوند تا سرویس دیگران آسیب نبیند.
• آیا تست روی محیط تولید (Production) یا محیط آزمایشی (Staging) انجام می‌شود؟ ترجیح همیشه محیط آزمایشی است. اما در برخی پروژه‌ها که محیط آزمایشی شبیه تولید نیست، تست روی تولید با احتیاط‌های اضافه انجام می‌شود.
• ساعات مجاز تست چیست؟ اگر روی تولید تست می‌کنید، باید بازه‌ای را انتخاب کنید که ترافیک پایین است و تیم پشتیبانی آماده است.
• قواعد تعامل (Rules of Engagement) چیست؟ چه چیزهایی مجاز است (مثلاً Brute-force محدود، بدون DoS) و چه چیزهایی ممنوع است (تخریب داده، آسیب به کاربران واقعی).
• نقطه تماس اضطراری کیست؟ اگر در حین تست، سایت از دسترس خارج شد یا یک رفتار مشکوک مشاهده شد، چه کسی باید باخبر شود؟

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

فاز یک: شناسایی و اطلاعات‌کاوی

در ادبیات تست نفوذ، این فاز با عنوان Reconnaissance یا Footprinting شناخته می‌شود. هدف، کشف حداکثر اطلاعات در مورد هدف است، بدون این‌که هیچ تماس مستقیمی با سیستم برقرار شود. این اطلاعات، پایه همه فازهای بعدی است.

در سطح عملی، این سه دسته اطلاعات را جمع می‌کنم:

1. دامنه‌های مرتبط و زیردامنه‌ها. از طریق سرویس‌های Certificate Transparency، جستجو در WHOIS، ابزارهایی مثل Amass یا Subfinder. زیردامنه‌ها اغلب شکارچیان آسیب‌پذیری را به سمت سیستم‌های قدیمی و کمتر محافظت‌شده هدایت می‌کنند.
2. فناوری‌های مورد استفاده. با تحلیل هدرهای HTTP، فایل‌های JS، نام کوکی‌ها و الگوهای URL می‌توان تشخیص داد سایت روی چه stack (مثلاً WordPress، Laravel، Django، Shopify) اجرا می‌شود.
3. حضور در اینترنت. جستجوی سایت در موتورهای جستجو، بررسی indexed pages، مشاهده cached pages، و مرور سرویس‌هایی مثل Shodan یا Censys برای یافتن نقاط اتصال به سرور.

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

فاز دو: اسکن خودکار، نقطه شروع نه پایان

حالا اولین تماس فعال با هدف برقرار می‌شود. ابزارهای اسکن خودکار می‌آیند روی صحنه:

• Nmap: کشف پورت‌های باز و سرویس‌های فعال روی سرور. اولین ابزار در جعبه‌ابزار هر مهندس امنیت.
• Nikto یا Nuclei: اسکن شناخته‌شده‌های پیکربندی سرور، فایل‌های حساس و آسیب‌پذیری‌های رایج.
• OWASP ZAP یا Burp Suite: اسکنرهای برنامه وب که آسیب‌پذیری‌هایی مثل XSS، SQL Injection و خطاهای پیکربندی را شناسایی می‌کنند.
• Wordfence یا WPScan برای وردپرس: اگر هدف روی وردپرس است، ابزارهای تخصصی اطلاعات دقیق‌تری در مورد نسخه، افزونه‌ها و آسیب‌پذیری‌های شناخته‌شده می‌دهند.

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

1. حذف خطاهای مثبت (False Positives): هر یافته باید دستی بازبینی شود. اسکنری که «XSS یافت شد» را گزارش می‌کند، ممکن است در واقع یک بازتاب امن HTML دیده باشد.
2. دسته‌بندی بر اساس ریسک واقعی: با استفاده از چارچوب CVSS (Common Vulnerability Scoring System) یا معادل‌های عملی، هر یافته امتیازدهی می‌شود. جزئیات بیشتر در CVE چیست و چه نقشی در امنیت دارد آمده است.
3. زنجیره‌سازی یافته‌ها: دو آسیب‌پذیری با شدت متوسط، در صورت زنجیره شدن، می‌توانند یک آسیب‌پذیری بحرانی بسازند. اسکنر این زنجیره را نمی‌بیند؛ مهندس تستر می‌بیند.

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

در همین فاز، ابزارهایی مثل اسکنرهای آسیب‌پذیری وب نقش دارند. برای انتخاب ابزار مناسب، باید به نوع هدف (سایت ساده، SPA، API)، نوع محدوده و نوع یافته‌های موردانتظار توجه کرد. در تجربه من، Burp Suite برای برنامه‌های مدرن و تعاملی، انتخاب اول است؛ WPScan برای وردپرس، ابزار تخصصی و ارزشمند.

فاز سه: تست احراز هویت و مدیریت نشست

لایه احراز هویت (Authentication) و مدیریت نشست (Session Management) معمولاً نقطه ورود ترجیحی مهاجمان است. در تست، این پرسش‌ها را بررسی می‌کنم:

• آیا نام‌های کاربری قابل شمارش هستند؟ اگر خطای ورود با نام کاربری اشتباه و رمز اشتباه متفاوت باشد، مهاجم می‌تواند نام کاربری‌های معتبر را کشف کند.
• آیا محدودیت تلاش ورود وجود دارد؟ نبود محدودیت، امکان Brute-force را باز می‌کند. برای وردپرس، نقشه راه در امن‌سازی ورود ادمین وردپرس آمده است.
• آیا نشست‌ها به‌درستی مدیریت می‌شوند؟ کوکی‌های نشست باید Secure، HttpOnly و SameSite داشته باشند. اگر تنظیمات ناقص باشد، دزدیدن نشست از طریق XSS یا CSRF ممکن می‌شود.
• آیا بازیابی رمز عبور امن است؟ توکن‌های بازیابی باید یک‌بارمصرف، دارای زمان انقضا و با آنتروپی کافی باشند. بیشتر آسیب‌پذیری‌های احراز هویت در پروژه‌های داخلی، از همین بخش می‌آید.
• آیا مکانیزم‌های 2FA واقعاً کار می‌کنند؟ گاهی 2FA در فرانت‌اند فعال است اما مسیر API مستقیم، آن را دور می‌زند.

این فاز در تست امنیت وردپرس اهمیت ویژه دارد، چرا که هسته وردپرس به‌تنهایی برخی از این کنترل‌ها را ندارد و افزونه‌ها باید اضافه شوند. مرور کلی این لایه در راهنمای امنیت وردپرس برای مبتدیان آمده است، اما تست حرفه‌ای نیازمند تست دستی این سناریوهاست.

فاز چهار: تست ورودی‌ها و کلاس‌های OWASP

لایه ورودی‌ها، محل کلاسیک آسیب‌پذیری‌های وب است. OWASP (Open Web Application Security Project) در فهرست Top 10 خود، دسته‌های اصلی این آسیب‌پذیری‌ها را جمع‌بندی کرده است. در تست عملی، این چهار دسته را با دقت بررسی می‌کنم:

تزریق (Injection)

شامل تزریق SQL، Command Injection، LDAP Injection و NoSQL Injection. روش‌های تست: ارسال کاراکترهای ویژه، بررسی رفتار پاسخ، تحلیل زمان پاسخ در سناریوهای Blind. جزئیات دفاع در SQL Injection چیست و چگونه جلوگیری کنیم آمده است.

XSS و کلاس‌های مرتبط

شامل Reflected XSS، Stored XSS، DOM-based XSS. برای تست این‌ها، ترکیب اسکنر و دستی لازم است، چون DOM-based XSS اغلب از چشم اسکنرها پنهان می‌ماند. دستورالعمل دفاعی در حملات XSS چیست و چگونه دفع می‌شود آمده است.

CSRF و کلاس‌های مرتبط با نشست

تست CSRF نیازمند بررسی توکن‌های ضد-CSRF، بررسی SameSite کوکی‌ها و تست سناریوهای Cross-Origin است. مرور کلی در CSRF چیست و چگونه از آن جلوگیری کنیم آمده است.

کنترل دسترسی نامناسب (Broken Access Control)

شامل IDOR، Privilege Escalation و Force Browsing. این دسته، امروز در رتبه اول OWASP Top 10 است، چون نه اسکنرهای خودکار به‌خوبی آن را می‌بینند و نه تیم‌ها معمولاً آن را تست می‌کنند. راهنمای تخصصی در آسیب‌پذیری IDOR چیست آمده است.

در تست ورودی‌ها، دو اصل مهم را رعایت می‌کنم: اول، هر پارامتر ورودی — شامل URL، Form Data، JSON Body، Header، Cookie و حتی فایل‌های آپلودی — به‌عنوان یک مسیر حمله بالقوه بررسی می‌شود. دوم، هر تست به‌صورت کنترل‌شده انجام می‌شود تا اثرات جانبی روی داده واقعی ایجاد نکند.

فاز پنج: تست منطق کسب‌وکار

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

چند نمونه واقعی که در پروژه‌ها دیده‌ام:

• تخفیف قابل تکرار: فرمی که کد تخفیف یک‌بارمصرف را می‌پذیرفت، اما با ارسال درخواست‌های موازی، امکان اعمال چندباره داشت.
• دور زدن مرحله پرداخت: فلو خرید چندمرحله‌ای که امکان پرش از مرحله تأیید پرداخت به مرحله تکمیل سفارش را داشت، بدون بررسی مجدد پرداخت.
• دستکاری قیمت در سمت کلاینت: قیمت محصول در صفحه نمایش داده می‌شد و همان مقدار در درخواست افزودن به سبد خرید ارسال می‌شد. مهاجم با تغییر قیمت در درخواست، محصول را با قیمت دلخواه می‌خرید.
• بازیابی رمز عبور با ایمیل مشابه: سیستم به‌جای تطابق کامل ایمیل، تطابق جزئی (case-insensitive یا بدون نرمال‌سازی یونیکد) داشت و امکان دسترسی به حساب دیگران فراهم می‌شد.
• دسترسی به فایل‌های خصوصی با حدس نام: فایل‌های با نام‌های قابل حدس مثل invoice_2024_001.pdf که هیچ توکن تصادفی نداشتند.

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

فاز شش: تست API

در برنامه‌های مدرن، بخش زیادی از منطق در API (Application Programming Interface) قرار دارد. تست امنیت API نیازمند رویکرد متفاوتی از تست وب سنتی است:

• مستندسازی و کشف endpoints: با تحلیل OpenAPI/Swagger، تحلیل ترافیک برنامه موبایل یا SPA، و مشاهده الگوهای URL. اگر مستندات API وجود دارد، آن را نقطه شروع بگیرید. اگر ندارد، تحلیل ترافیک شبکه بهترین راه است.
• تست احراز هویت API: JWT، OAuth، API Key — هر کدام ضعف‌های خاص خودشان را دارند. مثلاً JWT بدون بررسی امضا، یا OAuth با redirect_uri باز. مرور کلی در امنیت API در وب آمده است.
• تست Rate Limiting: آیا API در برابر درخواست‌های انبوه مقاوم است؟ نبود Rate Limiting باعث می‌شود حملاتی مثل Brute-force و Enumeration ساده شوند.
• تست Mass Assignment: در برخی فریم‌ورک‌ها، ارسال فیلد اضافی در JSON باعث می‌شود فریم‌ورک آن را مستقیم روی مدل اعمال کند. مثلاً مهاجم با ارسال {"role": "admin"}، نقش خود را ارتقا می‌دهد.
• تست دسترسی‌های سطح شیء (Object-level authorization): مشابه IDOR در وب، اما در سطح API. مثلاً endpoint /api/users/123/profile که فقط با تغییر 123 در URL، امکان دسترسی به پروفایل دیگران را می‌دهد.

ابزار Burp Suite در این فاز سنگین کار می‌کند. برای تست APIهای REST، پلاگین‌های تخصصی و امکان نوشتن اسکریپت‌های تست سفارشی ضروری است. برای GraphQL، ابزارهایی مثل GraphQL Voyager و InQL راهگشا هستند.

فاز هفت: تست سمت کلاینت

در برنامه‌های مدرن که حجم زیادی از منطق در سمت کلاینت (Frontend) اجرا می‌شود، تست سمت کلاینت اهمیت بالایی دارد. این فاز شامل این موارد است:

• تحلیل جاوااسکریپت: جستجوی API keys یا secrets هاردکد شده در باندل JS، بررسی منطق کنترل دسترسی که فقط در فرانت اعمال شده.
• تست Content Security Policy (CSP): بررسی تنظیم درست CSP در هدرهای HTTP برای کاهش ریسک XSS. مرور کلی در هدرهای امنیتی HTTP آمده است.
• تست Local Storage و Session Storage: بررسی این‌که داده‌های حساس در این مخازن ذخیره نشده باشند.
• تست PostMessage و iframe Communication: در برنامه‌هایی که از iframe یا postMessage استفاده می‌کنند، احتمال آسیب‌پذیری بالاست اگر origin بررسی نشود.
• تست Subresource Integrity (SRI): برای منابع خارجی لودشده (مثل کتابخانه‌های CDN)، بررسی این‌که SRI تنظیم شده است تا از حمله Supply Chain جلوگیری شود.

تست امنیت وردپرس: مسیر اختصاصی

اگر هدف وردپرس است، تست امنیت مسیر اختصاصی خودش را دارد. سه لایه اصلی:

1. لایه هسته: بررسی نسخه وردپرس، بررسی فایل‌های اصلی در برابر تغییرات، بررسی تنظیمات wp-config.php. راهنمای امن‌سازی فایل پیکربندی در امن‌سازی wp-config آمده است.
2. لایه افزونه و قالب: هر افزونه و قالب باید در برابر پایگاه‌های آسیب‌پذیری مثل WPScan Vulnerability Database بررسی شود. مسیرهای آسیب‌پذیری در افزونه‌ها در آسیب‌پذیری افزونه‌های وردپرس تحلیل شده است.
3. لایه سرسختی‌سازی: در سطح وردپرس، اقداماتی مثل nonce، sanitization و escaping ضروری است. فهرست خطاهای رایج در اشتباهات رایج امنیت وردپرس آمده است.

در تست امنیت وردپرس، ابزار WPScan و افزونه Wordfence نقش مهمی دارند. اما نباید فراموش کنیم که این ابزارها فقط سطح بیرونی را می‌بینند. تست لایه‌های داخلی — از جمله افزونه‌های سفارشی، قالب‌های اختصاصی، و هوک‌های استفاده‌شده — نیازمند تست دستی توسط مهندس باتجربه است.

ابزارها و جایگاهشان در پروتکل

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

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

گزارش‌نویسی و اولویت‌بندی یافته‌ها

تست بدون گزارش قابل‌اقدام، اتلاف وقت است. گزارش حرفه‌ای تست امنیت، سه ویژگی دارد:

1. قابل‌فهم برای مخاطب‌های مختلف: مدیر محصول، مدیر فنی و توسعه‌دهنده، هر کدام بخش متفاوتی از گزارش را می‌خوانند. خلاصه اجرایی برای مدیر، جزئیات فنی برای توسعه‌دهنده.
2. قابل بازتولید: برای هر یافته، دقیقاً ذکر شود که با چه درخواست HTTP، چه پارامتر و چه شرایطی، آسیب‌پذیری قابل مشاهده است. بدون این، توسعه‌دهنده نمی‌تواند تأیید یا رفع کند.
3. اولویت‌بندی‌شده: یافته‌ها بر اساس CVSS یا معیار عملی مشابه، اولویت‌بندی می‌شوند. راهنمای اولویت‌بندی در چگونه آسیب‌پذیری‌ها را رتبه‌بندی و رفع کنیم آمده است.

هر یافته در گزارش باید شامل این هفت بخش باشد: عنوان، توصیف، سطح ریسک، مراحل بازتولید (PoC)، اثر احتمالی، راه‌حل پیشنهادی، و منابع مرجع. در تجربه من، پیشنهاد راه‌حل باید هم سطح کوتاه‌مدت (مثلاً تنظیم WAF) و هم بلندمدت (اصلاح کد) داشته باشد.

تست امنیت در CI/CD: رگرسیون پیوسته

تست امنیت یک‌بار مصرف، ناکافی است. با هر تغییر کد، احتمال بازگشت آسیب‌پذیری وجود دارد. راه‌حل، یکپارچه‌سازی تست امنیت در CI/CD (Continuous Integration/Continuous Deployment) است.

در پروژه‌های امروزی، سه لایه تست امنیتی در CI/CD وجود دارد:

• SAST (Static Application Security Testing): ابزارهایی مثل Semgrep، SonarQube یا CodeQL که کد را در حالت ایستا بررسی می‌کنند. این ابزارها در مرحله Pull Request اجرا می‌شوند و جلوی ادغام کد ناامن را می‌گیرند.
• DAST (Dynamic Application Security Testing): ابزارهایی مثل ZAP که روی محیط استیجینگ اجرا می‌شوند. این ابزارها بخشی از آسیب‌پذیری‌های زمان اجرا را کشف می‌کنند.
• SCA (Software Composition Analysis): ابزارهایی که وابستگی‌های پروژه (پکیج‌های npm، Composer، pip) را برای آسیب‌پذیری‌های شناخته‌شده بررسی می‌کنند.

در تجربه من، SAST با پیکربندی درست، پرثمرترین لایه در CI/CD است. اما باید آستانه حساسیت آن به‌درستی تنظیم شود، وگرنه هشدارهای بی‌پایان باعث می‌شود تیم به همه هشدارها بی‌توجه شود.

پرسش‌های پرتکرار درباره تست امنیت وب‌سایت

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

هر چند وقت یک بار باید تست امنیت انجام شود؟

برای سایت‌های پرمعامله یا در حال رشد، حداقل سالی یک بار تست کامل (Full-scope) و هر سه ماه یک بار تست محدود (Targeted). برای سایت‌های ثابت، سالی یک بار کافی است. در کنارش، تست پیوسته در CI/CD سطح رگرسیون را پوشش می‌دهد.

آیا اسکن خودکار برای شروع کافی است؟

برای اهداف آموزشی و آگاهی اولیه، بله. اما برای تصمیم‌های جدی (مثلاً اعلام امنیت به مشتری یا دریافت گواهی انطباق)، حتماً نیازمند تست دستی حرفه‌ای است.

هزینه تست امنیت چقدر است؟

دامنه قیمت بسیار وسیع است، از چند ساعت مشاوره تا چند هفته پروژه. عوامل مؤثر: اندازه سایت، پیچیدگی، تعداد endpoints، حساسیت داده‌ها و سطح عمق تست. برای یک سایت وردپرسی ساده، یک تست نسبتاً سبک کافی است؛ برای یک پلتفرم SaaS بزرگ، تیم چندنفره برای هفته‌ها نیاز است.

آیا می‌توانم خودم تست امنیت انجام دهم؟

تا حدی بله. برای سایت شخصی یا وردپرس ساده، ابزارهایی مثل WPScan یا OWASP ZAP می‌توانند شروع خوبی باشند. اما اگر داده کاربران حساس یا تراکنش مالی دارید، تخصص حرفه‌ای لازم است. اشتباه رایج در تست خودآموخته، نادیده گرفتن زنجیره‌های حمله است.

تفاوت Pentest و Vulnerability Assessment چیست؟

Vulnerability Assessment، شناسایی گسترده آسیب‌پذیری‌هاست و معمولاً خودکارتر است. Pentest، تلاش هدفمند برای بهره‌برداری از آسیب‌پذیری‌ها و اثبات اثر واقعی‌شان است. اولی مبنای کمی دارد، دومی مبنای کیفی. برای پروژه‌های جدی، ترکیب هر دو لازم است.

اگر در حین تست، سایت از دسترس خارج شد چه کنیم؟

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

آیا تست امنیت روی محیط Production ریسک دارد؟

بله، و به همین دلیل توصیه اول همیشه Staging است. اما اگر Production تنها گزینه است، سه احتیاط لازم است: تست در بازه ترافیک پایین، محدودسازی شدت تست‌ها (بدون DoS یا Brute-force گسترده)، و در دسترس بودن تیم پشتیبانی.

آنچه سال‌ها بعد هم تکرار می‌شود

تست امنیت وب‌سایت، یک پروتکل چندفازی است که ابزار در آن نقش دارد، اما نه نقش اصلی. اگر امروز بخواهم سه اولویت را برای شروع معرفی کنم، این‌ها خواهند بود: اول، نوشتن سند محدوده و قواعد تعامل پیش از هر کار فنی؛ دوم، تمرکز بر لایه‌هایی که اسکنر نمی‌بیند (احراز هویت، منطق کسب‌وکار، API)؛ سوم، یکپارچه‌سازی تست امنیت در CI/CD برای رگرسیون پیوسته.

اگر در پروژه‌ای تجربه تست امنیت داشته‌اید، برایم جالب است بدانید کدام فاز بیشترین زمان را از تیم گرفت یا کدام یافته غیرمنتظره بود. تجربه‌تان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر ابزار یا رویکردی در پروژه‌تان مؤثر بود که در این مقاله به آن اشاره نشده. 🔎