تست نفوذ وب‌اپلیکیشن؛ از Scope امن تا Retest

تست نفوذ وب‌اپلیکیشن زمانی ارزش دارد که یک سؤال مشخص را با مجوز کتبی پاسخ دهد: آیا مهاجم می‌تواند از مسیرهای واقعاً در دسترس، کنترل‌های فعلی را دور بزند و به یک دارایی یا فرایند مهم آسیب بزند؟ اجرای چند اسکن، شمارش CVE یا تحویل PDF طولانی جواب این سؤال نیست. Pentest خوب Scope و Rules of Engagement روشن دارد، منطق کسب‌وکار و مرز Tenant/Role را می‌آزماید، Evidence حداقلی و قابل‌بازتولید می‌دهد، اصلاح را به Owner می‌رساند و با Retest بسته می‌شود.

هر آزمون فقط باید روی سامانه‌ای انجام شود که مالک یا نماینده مجاز آن، محدوده و روش را صریحاً تأیید کرده است. تست بدون مجوز می‌تواند غیرقانونی، مخرب و موجب افشای داده یا اختلال خدمت شود. این راهنما برای برنامه‌ریزی، خرید، نظارت و دفاع مجاز است؛ دستورالعمل نفوذ به سامانه دیگران ارائه نمی‌کند.

تست نفوذ دقیقاً چیست؟

تست نفوذ یک ارزیابی زمان‌دار و کنترل‌شده است که در آن متخصص امنیت، با مجوز و در محدوده توافق‌شده، امکان سوءاستفاده از ضعف‌ها و اثر زنجیره‌ای آن‌ها را بررسی می‌کند. خروجی مطلوب «اثبات کنترل‌شده ریسک + مسیر اصلاح + Retest» است.

تست نفوذ چه چیزی نیست؟

NIST SP 800-115 آزمون فنی را مجموعه‌ای از روش‌ها با مزیت و محدودیت متفاوت می‌داند. یک برنامه بالغ این روش‌ها را مکمل می‌کند؛ Pentest جای Secure SDLC یا Vulnerability management را نمی‌گیرد.

چه زمانی تست نفوذ لازم است؟

قاعده «برای همه سالی یک‌بار» بیش از حد ساده است. Cadence باید از ریسک، تغییر، Exposure، Requirement قراردادی و سابقه یافته بیاید.

برای محیط مشمول PCI DSS، نسخه و Requirement جاری را از کتابخانه رسمی PCI SSC بگیرید؛ PCI DSS v4.۰.۱ Requirement ۱۱.۴ درباره تست نفوذ بیرونی/درونی، اصلاح ضعف‌های قابل‌سوءاستفاده و در شرایط تعریف‌شده آزمون دوره‌ای/پس از تغییر صحبت می‌کند. Scope و روش اعتبارسنجی را با QSA یا متخصص واجدصلاحیت خود تطبیق دهید؛ استاندارد کارت جهانی را بی‌دلیل به همه کسب‌وکارهای ایرانی تعمیم ندهید.

Gate صفر: مجوز کتبی و Rules of Engagement

هیچ تستی پیش از امضای Authorization و RoE شروع نمی‌شود. مالک کسب‌وکار، مالک فنی، Hosting/Cloud/Provider مرتبط و Tester باید بدانند چه چیزی مجاز است.

«حفظ دسترسی» یا نصب Backdoor یک مرحله پیش‌فرض Pentest وب نیست. Persistence، Data exfiltration، تغییر رکورد و Denial of Service باید ممنوع باشند مگر هدف دقیق، محیط ایزوله، Approval و روش بازگشت جداگانه داشته باشند. معمولاً Proof حداقلی بدون نگه‌داشتن دسترسی کافی است.

Scope را از Inventory بسازید

فقط یک URL صفحه اصلی Scope نیست. Web app مدرن از Frontend، API، Admin، Auth provider، Object storage، Queue، Webhook، CDN و سرویس ثالث تشکیل می‌شود.

Asset ناشناخته به Coverage gap تبدیل می‌شود. OWASP Web Security Testing Guide چارچوب جامعی برای تست وب ارائه می‌کند و توصیه می‌کند شناسه سناریوها با نسخه ارجاع شوند. در Statement of Work بنویسید مثلاً WSTG version/snapshot و کدام Scenarioها In scope هستند؛ عبارت مبهم «بر اساس OWASP» قابل‌ممیزی نیست.

Black-box، Gray-box و White-box رتبه کیفیت نیستند

برای وب‌اپ بیشتر اوقات Gray/White-box با چند Role و دو Tenant، شواهد بهتری از Black-box تنها می‌دهد. شبیه‌سازی مهاجم بیرونی یک Objective ممکن است؛ اتلاف زمان برای کشف چیزی که مالک می‌تواند مستند کند، الزام کیفیت نیست.

Test account matrix؛ قلب آزمون Authorization

با این ماتریس می‌توان Same-role، Cross-user، Cross-tenant، vertical privilege و lifecycle revoke را آزمود. مقاله امنیت API و OWASP قرارداد دقیق Authorization، OAuth/JWT و Webhook را پوشش می‌دهد؛ Pentest باید پیاده‌سازی واقعی آن قرارداد را ارزیابی کند.

Baseline را با ASVS بسازید، نه فقط Top ۱۰

OWASP Top 10:2025 سند Awareness است و دسته‌های ریسک مهمی مثل Broken Access Control، Security Misconfiguration، Supply Chain Failures و Mishandling of Exceptional Conditions را برجسته می‌کند؛ اما Checklist کامل پذیرش نیست.

OWASP ASVS 5.0.0 Requirementهای قابل‌ارجاع برای طراحی، توسعه، تست و Procurement می‌دهد. Requirement ID را با Version ذخیره کنید تا Coverage و Retest در طول زمان قابل‌ردیابی بماند.

Coverage map وب‌اپلیکیشن

فهرست زیر سطح پوشش است، نه دستور Exploit. تکنیک دقیق فقط در RoE، محیط مجاز و توسط متخصص اجرا می‌شود.

Business logic را چگونه Scope کنیم؟

Scanner نمی‌داند «تخفیف فقط یک‌بار»، «بازپرداخت حداکثر مبلغ تسویه‌شده» یا «تأییدکننده نباید درخواست‌کننده باشد» یعنی چه. Product و Finance باید Invariantها را قبل از تست بنویسند.

برای Login، تفکیک Brute force، Credential stuffing و Recovery abuse در راهنمای دفاع Login آمده است؛ برای حساب‌های مدیریت نیز MFA و Break-glass باید در Scope باشد.

API و Webhook را ضمیمه فرض نکنید

SPA و Mobile app ممکن است فقط Clientهای API باشند. Scope باید Endpoint inventory، نسخه‌های قدیمی، GraphQL operation، Webhook receiver، background job و admin API را پوشش دهد. OWASP API Security Top 10:2023 ریسک‌هایی مثل Object-level authorization، Sensitive business flow، Inventory و Unsafe consumption را یادآوری می‌کند.

Production یا Staging؟

هیچ پاسخ یکسانی وجود ندارد. Staging ایزوله ریسک عملیاتی را کم می‌کند اما ممکن است WAF، IAM، data volume، CDN، secret و configuration واقعی را بازنمایی نکند. Production واقعی‌تر است و Blast radius بیشتری دارد.

پیش از Production test، Backup و Restore باید اثبات شده باشند؛ راهنمای Disaster Recovery و بازیابی را به Pre-flight وصل کنید. Backup مجوز تست مخرب نیست.

Pre-flight پیش از شروع

• نسخه، Feature flag و deployment freeze یا change log ثبت شده است.
• Test account/tenant/data قابل‌حذف آماده‌اند.
• On-call، SOC، Hosting و Vendorهای لازم اطلاع دارند.
• Source IP و Window ثبت و Alert suppression محدود تعریف شده است.
• Backup/restore و Capacity headroom تأیید شده‌اند.
• Stop command و کانال اضطراری آزموده شده‌اند.
• Evidence vault و encryption/retention تعیین شده است.
• Legal/Privacy approval و third-party permission موجود است.

Stop condition و ارتباط حین تست

Telemetry باید تست را از حمله واقعی جدا کند. Trace، audit log، WAF/auth event و Alert باید Correlation ID یا Tag مجاز داشته باشند. راهنمای Observability، SLO و Alert برای این Evidence عملیاتی لازم است.

Evidence؛ حداقل لازم، نه جمع‌آوری حداکثری

گزارش نباید خود به نشت داده تبدیل شود. برای اثبات، رکورد مصنوعی و حداقل Field استفاده کنید. Secret، Token، Cookie، PII و Payment data را Mask کنید.

Severity با یک عدد Base تمام نمی‌شود

CVSS ۴.۰ از FIRST Base، Threat، Environmental و Supplemental metric دارد و تأکید می‌کند CVSS فقط Base score نیست. نمره فنی ورودی تصمیم است؛ Priority باید Context سازمان را نیز ببیند.

Remediation priority = technical severity
× asset criticality
× reachable population
× threat relevance
× business consequence
÷ validated control effectiveness

این فرمول مفهومی است، نه ماشین‌حساب علمی. Assumption، داده و Risk owner را کنار نتیجه ثبت کنید. برای تبدیل سناریوی امنیتی به Loss range از راهنمای بودجه امنیت سایت و Roadmap ریسک‌محور استفاده کنید.

گزارش Pentest چه بخش‌هایی دارد؟

Screenshot بدون Request context یا Tool dump چندصدصفحه‌ای گزارش نیست. هر Finding باید Reproducible، Deduplicated، Root-cause-oriented و قابل‌ردیابی به Requirement باشد.

یافته را به Ticket قابل‌ساخت تبدیل کنید

Finding: PT-2026-014
Asset/version: ...
Affected roles/tenants: ...
Precondition: ...
Expected security rule: ...
Observed behavior: ...
Sanitized evidence/trace: ...
Root cause hypothesis: ...
Required control and acceptance tests: ...
Owner / due date / risk decision: ...
Retest result: pending

راهکار «ورودی را Validate کنید» کافی نیست. Recommendation باید محل Enforcement، Policy، deny behavior، Audit event و Regression test را مشخص کند بدون اینکه معماری را از بیرون تحمیل کند.

Remediation و Retest؛ پایان واقعی پروژه

Retest فقط اجرای Payload قبلی نیست. Root cause، مسیرهای مشابه، Role/Tenantهای متاثر، negative test و نبود Regression بررسی می‌شوند. اگر Scope یا نسخه عوض شده است، نتیجه قبلی را خودکار تعمیم ندهید.

Remediation SLA را ریسک‌محور تعریف کنید

عدد روز ثابت را بدون Appetite و Capability کپی نکنید. SLA باید با Criticality، Exposure، Threat، Control و Release model شما سازگار و Expiry پذیرش ریسک مشخص باشد.

Pentest را به SDLC وصل کنید

Finding باید به Test دائمی تبدیل شود تا در Release بعدی برنگردد. Pipeline CI/CD امن می‌تواند Security gate، Artifact provenance، Progressive delivery و Rollback را اجرا کند؛ Pentest جای آن را نمی‌گیرد.

CSP و WAF در Pentest چه نقشی دارند؟

WAF، CSP، Rate limit یا MFA کنترل جبرانی‌اند؛ وجودشان Finding ریشه‌ای را خودکار حذف نمی‌کند. باید نشان دهید کنترل در مسیر واقعی فعال، قابل‌دورزدن‌نبوده، قابل‌مشاهده و دارای Failure behavior مناسب است.

برای XSS، CSP سخت‌گیرانه Defense-in-depth است و جای Output encoding/DOM safety را نمی‌گیرد. Pentest باید Policy و Report telemetry را ببیند، اما نباید با ایجاد Payload مخرب برای کاربران واقعی از RoE عبور کند.

انتخاب شرکت یا Tester

هزینه تست نفوذ چگونه برآورد می‌شود؟

قیمت ثابت عمومی قابل‌اعتماد نیست. هزینه تابع Person-day، تعداد Role/Tenant/Flow/API، Source access، Environment، Compliance mapping، Report language، Retest و Window است.

Engagement TCO = scoping and preparation
+ testing and peer review
+ report/debrief
+ engineering remediation
+ retest/regression
+ operational coordination
+ residual-risk handling

پیشنهاد ارزان با Scope مبهم می‌تواند Coverage کمی بدهد و هزینه Remediation را بالا ببرد. بودجه را بر اساس Risk reduction و Coverage critical flow بسنجید، نه تعداد Finding.

ملاحظات اجرای تست نفوذ در ایران

از داده یا حساب مشتری واقعی برای «واقعی‌ترشدن» تست استفاده نکنید، مگر ضرورت، رضایت، حداقل‌گرایی و کنترل آن مستند باشد. کیفیت از مدل Threat و Fixture درست می‌آید، نه افزایش ریسک کاربران.

متریک‌های برنامه Pentest

RACI تست نفوذ

چهار Runbook ضروری

۱. تست باعث افت SLO می‌شود

1. Tester Stop command را اجرا و timestamp/source را اعلام کند.
2. On-call اثر را از حمله واقعی تفکیک و سرویس را پایدار کند.
3. Evidence و change/test log حفظ شود.
4. فقط پس از Root cause، rate جدید و Approval از سر گرفته شود.

۲. Tester به داده واقعی غیرمنتظره می‌رسد

1. مشاهده/جمع‌آوری بیشتر متوقف شود.
2. حداقل Evidence رمز‌شده و دسترسی محدود ثبت شود.
3. Privacy/Security owner Scope و Incident threshold را تصمیم بگیرند.
4. داده طبق Retention قرارداد حذف و attestation ثبت شود.

۳. Finding بحرانی در حین تست

1. کانال Out-of-band و شناسه Finding استفاده شود.
2. Reach/impact بدون گسترش غیرضروری تأیید شود.
3. Containment کم‌خطر مثل disable/rotate/restrict/monitor اجرا شود.
4. Incident classification، fix و emergency retest برنامه‌ریزی شود.

۴. اصلاح در Retest رد می‌شود

1. Diff نسخه و Environment تأیید شود.
2. Patch symptom از Root cause جدا شود.
3. Variant/role/tenant و negative test بازبینی شوند.
4. Ticket با Owner/Deadline جدید باز و Risk موقت تصمیم‌دار شود.

برنامه ۹۰روزه برای Pentest قابل‌دفاع

چک‌لیست نهایی

• مالک دارای اختیار، Authorization کتبی داده است.
• In-scope/Out-of-scope و Third party دقیق‌اند.
• DoS، Social engineering، Persistence و Data handling حکم صریح دارند.
• Stop condition، On-call و کانال Critical آزموده شده‌اند.
• Asset، API، Role، Tenant، State و Integration inventory شده‌اند.
• WSTG/ASVS با Version و Test ID نگاشت شده‌اند.
• Top ۱۰ به‌جای Baseline کامل استفاده نشده است.
• Business invariant و Abuse case در Scope هستند.
• Staging/Production parity و Coverage gap ثبت شده‌اند.
• Evidence حداقلی، Masked، رمز‌شده و دارای Retention است.
• CVSS با Threat/Environment و Business impact غنی شده است.
• Report شامل Root cause، Acceptance، Owner و Deadline است.
• Fix به Regression test و Retest مستقل رسیده است.
• Risk acceptance Approver و Expiry دارد.
• Cadence بعدی با Trigger ریسک‌محور تعریف شده است.

جمع‌بندی

تست نفوذ وب‌اپلیکیشن «حمله نمایشی» یا اسکن گران نیست. یک Engagement مهندسی و ریسک است: هدف و Scope، مجوز و RoE، Account/Role/Tenant، Requirement و Test ID، اجرای ایمن، Evidence حداقلی، Severity زمینه‌دار، Root cause، اصلاح و Retest.

اگر فقط یک PDF دریافت کنید، چرخه امنیت بهتر نشده است. ارزش واقعی وقتی ایجاد می‌شود که Finding به کنترل قابل‌آزمون، Owner، Release امن، Telemetry و تصمیم Residual risk متصل شود. Pentest یک Snapshot با Coverage محدود است؛ امنیت وب‌اپلیکیشن از تکرار Secure design، تست خودکار، عملیات قابل‌مشاهده و ارزیابی انسانی هدفمند ساخته می‌شود.

پرسش‌های متداول

تست نفوذ وب‌اپلیکیشن چیست؟

ارزیابی مجاز، زمان‌دار و کنترل‌شده‌ای است که امکان سوءاستفاده از ضعف‌ها و اثر واقعی آن‌ها را در Scope مشخص بررسی می‌کند. خروجی باید Evidence امن، Root cause، اولویت، راه اصلاح و نتیجه Retest داشته باشد؛ تست هر سامانه بدون مجوز صریح ممنوع است.

هر چند وقت یک‌بار باید Pentest انجام دهیم؟

Frequency از ریسک و Requirement می‌آید: پیش از Production برای مسیر حیاتی، پس از تغییر مهم Identity/Architecture/Payment/API، پس از Incident و در Cadence دوره‌ای متناسب با Exposure و Criticality. برخی استانداردها مثل PCI DSS الزام خاص دارند که باید از نسخه جاری و متخصص مربوط بررسی شود.

تفاوت Vulnerability scan و تست نفوذ چیست؟

Scan معمولاً ضعف‌های بالقوه را با پوشش وسیع پیدا می‌کند؛ Pentest به‌صورت انسانی و کنترل‌شده Exploitability، زنجیره، Authorization و Business logic را می‌سنجد. هیچ‌کدام جای دیگری را نمی‌گیرد و هر دو باید با Code review، SAST/SCA و Secure SDLC تکمیل شوند.

Black-box بهتر است یا Gray-box و White-box؟

هیچ‌کدام ذاتاً بهتر نیست. Black-box دید بیرونی می‌دهد، Gray-box برای Role/Tenant و Workflow کارآمد است و White-box عمق/Root cause را بیشتر می‌کند. ترکیب مناسب از Objective، Threat و بودجه می‌آید؛ میزان اطلاعات Tester رتبه کیفیت نیست.

هزینه تست نفوذ وب‌اپلیکیشن چقدر است؟

به Surface، تعداد Role/Tenant/API/Flow، مدل دسترسی، Environment، Requirement mapping، Person-day، گزارش، Workshop و Retest بستگی دارد. برای Quote منصفانه Inventory و Scope واحد به چند تیم بدهید و Coverage، Safety، گزارش نمونه و Retest را مقایسه کنید، نه فقط مبلغ نهایی.