بیشتر چیزهایی که در فارسی با عنوان «چک لیست تست نفوذ» منتشر میشود، فهرستی از نام آسیب‌پذیری‌هاست: SQL Injection، XSS، CSRF و چند مورد دیگر. آن فهرست چکلیست نیست، واژه‌نامه است. چکلیست واقعی به شما می‌گوید چه چیزی را در کدام بخش برنامه بررسی کنید و پوشش را قابل اندازه‌گیری میکند. مرجع استاندارد این کار راهنمای OWASP Web Security Testing Guide v4.2 است: دوازده دسته و در نسخهی پایدار حدود ۹۷ آزمون نامگذاریشده. این مقاله همان ساختار را در قالب جدول‌های قابل استفاده ارائه میکند، به‌علاوه‌ی چکلیست پیش از شروع پروژه که نبودش شایع‌ترین منبع دردسر عملیاتی و حقوقی است.
در یک نگاه
- مرجع پوشش، WSTG v4.2 است — نسخهی پایدار جاری، منتشرشده در ۳ دسامبر ۲۰۲۰. نسخهی ۴٫۳ منتشر نشده و ۵٫۰ در حال توسعه است.
- دوازده دسته با پیشوند شناسه: INFO ۱۰ آزمون، CONF ۱۱، IDNT ۵، ATHN ۱۰، ATHZ ۴، SESS ۹، INPV ۱۹، ERRH ۲، CRYP ۴، BUSL ۹، CLNT ۱۳، APIT ۱ — جمعاً حدود ۹۷ آزمون.
- بزرگترین دسته INPV (اعتبارسنجی ورودی) با ۱۹ آزمون است؛ اما پرارزش‌ترین یافتهها معمولاً از ATHZ و BUSL بیرون می‌آیند که با هم فقط ۱۳ آزمون دارند.
- دستهی WSTG-APIT فقط یک آزمون دارد (GraphQL). برای API باید OWASP API Security Top 10 (۲۰۲۳) را به‌عنوان مرجع مکمل به کار برد.
- چکلیست پیش از شروع — مجوز کتبی، انجماد دامنه، بازه‌ی آزمون، تماس تشدید و پشتیبان تأییدشده — به‌اندازه‌ی چکلیست فنی الزامی است.
چکلیست پیش از شروع: پنج موردی که نبودشان پروژه را خراب میکند
پیش از اولین درخواست HTTP، این پنج مورد باید مکتوب و امضاشده باشند. هیچ‌کدام کار فنی نیست و هر پنج مورد در همه‌ی چارچوب‌های جدی — از فازهای PTES تا مرحله‌ی «Planning» در NIST SP 800-115 — الزامی‌اند.
| مورد | چه چیزی باید مشخص شود | چرا حیاتی است |
|---|---|---|
| مجوز کتبی آزمون | نام دارایی‌ها، نام و امضای مالک سامانه، تاریخ اعتبار، ارجاع به قرارداد و NDA | بدون آن، آزمون از نظر حقوقی دسترسی غیرمجاز است. این سند غیرقابل‌مذاکره است |
| انجماد دامنه (Scope Freeze) | فهرست بسته‌ی دامنه‌ها، زیردامنه‌ها، اندپوینت‌های API، و صریحاً موارد خارج از دامنه | جلوگیری از هم آزمون ناخواسته‌ی دارایی ثالث و هم از دست رفتن دارایی فراموش‌شده |
| بازه‌ی آزمون | تاریخ و ساعت شروع و پایان، و پنجره‌های ممنوع (مثلاً روز کمپین فروش) | تیم پایش باید بداند؛ و گزارش باید عکس لحظه‌ای مشخصی داشته باشد |
| تماس تشدید (Escalation) | نام و شماره‌ی تماس فوری در دو طرف، برای ۲۴ ساعت شبانه‌روز | اگر آزمون سرویس را ناپایدار کرد یا نشانه‌ی نفوذ واقعی پیدا شد، باید بلافاصله ارتباط برقرار شود |
| پشتیبان تأییدشده | پشتیبان تازه که بازیابی‌اش آزموده شده، نه فقط گرفته شده | پشتیبانی که بازیابی‌اش امتحان نشده، پشتیبان نیست |
سه مورد تکمیلی که توصیه میشود: فهرست IPهای مبدأ تیم آزمون (برای فهرست سفید و برای بازبینی لاگ‌ها)، حساب کاربری برای هر نقش در برنامه، و تصمیم روشن درباره‌ی محیط — عملیاتی یا Staging. جزئیات قالب مجوز و بندهای قرارداد در قرارداد و مجوز تست نفوذ و روش تعریف دامنه در دامنه‌ی تست نفوذ آمده است.
«چون سامانه مال خودمان است، مجوز کتبی لازم نیست.» مالکیت سازمانی جای مجوز مکتوب را نمی‌گیرد. سرور شما ممکن است روی زیرساخت ابری ثالث باشد، درگاه پرداختتان متعلق به شرکت دیگری است، و CDN شما سرویس‌دهنده‌ی مستقلی است. مجوز باید مشخص کند کدام دارایی متعلق به شماست و آزمون کدام بخش‌ها را پوشش نمی‌دهد. تیمی که بدون این سند کار را شروع میکند، شما را هم در معرض ریسک قرار می‌دهد.
چک لیست تست نفوذ بر پایه‌ی دوازده دستهی WSTG v4.2
جدول زیر ساختار کامل را نشان می‌دهد. شمارش‌ها از فهرست مطالب نسخهی پایدار وب استخراج شده‌اند؛ چون این نسخه بین انتشارهای برچسب‌دار بهصورت تدریجی به‌روز میشود، عبارت درست «حدود ۹۷ آزمون» است نه عدد قطعی.
| پیشوند شناسه | دسته | تعداد آزمون | محور |
|---|---|---|---|
| WSTG-INFO | گردآوری اطلاعات | ۱۰ | نگاشت سطح حمله پیش از آزمون |
| WSTG-CONF | پیکربندی و مدیریت استقرار | ۱۱ | پلتفرم، فایل‌های رهاشده، هدرها، ذخیره‌سازی ابری |
| WSTG-IDNT | مدیریت هویت | ۵ | نقشها، ثبت‌نام، شمارش حساب |
| WSTG-ATHN | احراز هویت | ۱۰ | ورود، قفل حساب، بازیابی رمز |
| WSTG-ATHZ | مجوزدهی | ۴ | ارتقای سطح دسترسی، IDOR، عبور از مسیر |
| WSTG-SESS | مدیریت نشست | ۹ | کوکی، تثبیت نشست، CSRF، خروج |
| WSTG-INPV | اعتبارسنجی ورودی | ۱۹ | بزرگترین دسته: انواع تزریق، SSRF، SSTI |
| WSTG-ERRH | مدیریت خطا | ۲ | خطای نامناسب، Stack Trace |
| WSTG-CRYP | رمزنگاری ضعیف | ۴ | TLS، Padding Oracle، انتقال ناامن |
| WSTG-BUSL | منطق کسب‌وکار | ۹ | دور زدن جریان، سقف‌ها، آپلود فایل |
| WSTG-CLNT | سمت کلاینت | ۱۳ | DOM XSS، CORS، Clickjacking، WebSocket |
| WSTG-APIT | آزمون API | ۱ | فقط GraphQL |
دو مشاهده‌ی مهم از همین جدول. اول: توزیع تعداد آزمون‌ها با توزیع ریسک همراستا نیست. دستهی INPV نوزده آزمون دارد و ATHZ فقط چهار، در حالی که کنترل دسترسی شکسته رتبه‌ی یک OWASP Top 10:2025 است و OWASP گزارش میکند ۱۰۰٪ برنامه‌های آزموده‌شده نوعی نقص کنترل دسترسی داشته‌اند. تعداد آزمون معیار زمان صرف‌شده نیست.
دوم: WSTG و OWASP Top 10 دو تاکسونومی متفاوت‌اند و کاملاً همراستا نیستند. نمونه‌ی روشن: SSRF در WSTG زیر اعتبارسنجی ورودی است (WSTG-INPV-19) اما در Top 10:2025 داخل A01 کنترل دسترسی شکسته ادغام شده. اگر گزارشی این دو را یکسان نشان دهد، ساده‌سازی نادرستی انجام داده است. تفصیل موضوع در متدولوژی تست نفوذ.
شناسایی و پیکربندی — INFO (۱۰) و CONF (۱۱)
این بیست‌ویک آزمون پیش‌نیاز همه‌ی کار بعدی است. هر اندپوینتی که در این مرحله پیدا نشود، آزموده هم نمی‌شود.
| آزمون | چه چیزی را بررسی میکنید |
|---|---|
| نشت اطلاعات از موتور جست‌وجو | صفحات ایندکس‌شده‌ای که نباید عمومی باشند؛ نسخه‌های کش‌شده |
| اثرانگشت وب‌سرور | محصول و نسخه از هدرها، ترتیب هدرها و رفتار خطا |
| بازبینی فایل‌های فرا‌داده | robots.txt، sitemap.xml، security.txt، .well-known/ |
| شمارش برنامه‌های میزبان | چند برنامه روی یک میزبان؟ زیردامنه‌ها و پورت‌های غیرمتعارف |
| نشت اطلاعات در محتوای صفحه | کامنت‌های HTML، فایل‌های JS باندل‌شده، Source Map رهاشده، کلید API |
| شناسایی نقاط ورودی | هر پارامتر، هدر، کوکی و بدنه‌ای که برنامه می‌خواند |
| نگاشت مسیرهای اجرا | جریان‌های چندمرحله‌ای و ترتیب اجباری آن‌ها |
| اثرانگشت فریم‌ورک و برنامه | فریم‌ورک و نسخه — ورودی کار روی زنجیره‌ی تأمین (A03:2025) |
| نگاشت معماری برنامه | CDN، WAF، Load Balancer، لایه‌های میانی |
| پیکربندی شبکه و پلتفرم | سرویس‌های اضافی، نسخه‌های وصله‌نشده، محیط‌های Staging عمومی |
| مدیریت پسوند فایل | رفتار سرور با .bak، .old، .inc، .config |
| فایل‌های پشتیبان و بی‌ارجاع | آرشیو کد، .git/ افشاشده، فایل .env |
| رابط‌های مدیریتی | پنل ادمین بی‌محافظ یا صرفاً «پنهان» |
| متدهای HTTP | PUT، DELETE، TRACE، و هدرهای بازنویسی متد |
| HSTS | وجود، مقدار max-age و includeSubDomains |
| سیاست دامنه‌ی متقاطع RIA | crossdomain.xml و clientaccesspolicy.xml باقی‌مانده |
| مجوزهای فایل | فایل‌های قابل نوشتن در مسیر سرویس‌دهی |
| تصاحب زیردامنه | رکورد DNS اشاره‌کننده به سرویس آزادشده |
| ذخیره‌سازی ابری | باکت با دسترسی عمومی خواندن یا نوشتن |
در عمل بیشتر این مرحله با ابزار انجام میشود: کشف زیردامنه با subfinder، بررسی زنده‌بودن و اثرانگشت با httpx، کشف مسیر با ffuf و بررسی الگوهای شناخته‌شده با Nuclei. مبانی این فاز در شناسایی (Reconnaissance) توضیح داده شده و فهرست کامل ابزارها در ابزارهای تست نفوذ.
هویت و احراز هویت — IDNT (۵) و ATHN (۱۰)
این پانزده آزمون به دستهی A07:2025 خطاهای احراز هویت نگاشت می‌شوند.
| آزمون | چه چیزی را بررسی میکنید |
|---|---|
| تعریف نقشها | فهرست کامل نقشها و مجوز هر نقش — پیش‌نیاز کل کار ATHZ |
| فرایند ثبت‌نام | آیا کاربر میتواند نقشی بالاتر از پیش‌فرض برای خودش بسازد؟ تأیید ایمیل و شماره اجباری است؟ |
| تخصیص حساب | چه کسی حساب می‌سازد، حذف میکند و نقش تغییر می‌دهد؛ آیا حساب حذف‌شده واقعاً غیرفعال میشود؟ |
| شمارش حساب | تفاوت پاسخ ورود/بازیابی برای کاربر موجود و ناموجود؛ تفاوت زمان پاسخ |
| سیاست نام کاربری | امکان ساخت نام‌های مشابه یا هم‌ارز پس از نرمال‌سازی |
| انتقال اعتبارنامه | ارسال روی کانال رمزنگاری‌شده؛ اعتبارنامه در Query String نباشد |
| اعتبارنامه‌ی پیش‌فرض | حساب پیش‌فرض پنل‌ها، سرویس‌های مدیریتی و ابزارهای همراه فریم‌ورک |
| قفل حساب | وجود سازوکار، و از آن مهم‌تر: آیا خودش به منع سرویس تبدیل میشود؟ |
| دور زدن طرح احراز هویت | دسترسی مستقیم به مسیر پس از ورود، دستکاری پارامتر وضعیت، اجبار مرور |
| «مرا به یاد داشته باش» | توکن ماندگار قابل حدس یا بدون انقضا |
| ضعف کش مرورگر | داده‌ی حساس قابل بازگشت با دکمه‌ی Back پس از خروج |
| سیاست رمز عبور | هم‌راستایی با NIST SP 800-63B؛ بررسی در برابر مجموعه‌های فاش‌شده |
| سؤال امنیتی | وجودشان به‌خودی‌خود یک یافته است — پاسخ‌ها برای افراد متعدد دانستنی‌اند |
| تغییر و بازیابی رمز | عمر و یکبارمصرف بودن توکن، پیوند بازیابی، ابطال نشست‌های فعال پس از تغییر |
| احراز هویت در کانال‌های جایگزین | اپ موبایل، API، سامانه‌ی قدیمی — آیا کنترل ضعیف‌تری دارند؟ |
موارد مربوط به توکن را جداگانه بررسی کنید: اگر برنامه از JWT استفاده میکند، اعتبارسنجی ادعاهای aud و iss، فهرست سفید الگوریتم و رفتار در برابر جابه‌جایی الگوریتم را بیازمایید؛ و اگر ورود از طریق OAuth است، تطابق دقیق redirect_uri، وجود state و PKCE را.
مجوزدهی و نشست — ATHZ (۴) و SESS (۹)
سیزده آزمون که پرارزش‌ترین یافته‌های هر پروژه از آن‌ها بیرون می‌آید. توجه کنید که این بخش عملاً تمام‌دستی است؛ هیچ ابزاری نمی‌داند کاربر ۵ مجاز به دیدن رکورد ۷ است یا نه.
| آزمون | چه چیزی را بررسی میکنید |
|---|---|
| عبور از مسیر و گنجاندن فایل | خواندن فایل خارج از ریشه؛ جزئیات در LFI |
| دور زدن طرح مجوزدهی | دسترسی افقی و عمودی؛ مسیر دوقلوی API، هدرهای X-Original-URL و بازنویسی متد |
| ارتقای سطح دسترسی | تبدیل کاربر عادی به مدیر؛ Mass Assignment روی فیلد نقش. جزئیات در ارتقای سطح دسترسی |
| ارجاع مستقیم ناامن به شیء | تغییر شناسه در پارامتر یا بدنه؛ جزئیات در IDOR |
| طرح مدیریت نشست | آنتروپی شناسه‌ی نشست، تولید سمت سرور، تغییر شناسه پس از ورود |
| ویژگی‌های کوکی | HttpOnly، Secure، SameSite، دامنه و مسیر، پیشوند __Host- |
| تثبیت نشست | آیا شناسه‌ی پیش از ورود بعد از ورود معتبر می‌ماند؟ |
| افشای متغیرهای نشست | توکن در URL، در لاگ، در هدر Referer، در localStorage |
| CSRF | توکن هم‌گام‌ساز سمت سرور؛ جزئیات در CSRF |
| عملکرد خروج | ابطال نشست در سمت سرور، نه فقط پاک کردن کوکی |
| انقضای نشست | انقضای بی‌کاری و انقضای مطلق |
| Session Puzzling | استفاده‌ی مشترک از یک متغیر نشست در دو جریان متفاوت |
| ربایش نشست | پذیرش نشست از IP یا User-Agent متفاوت، بازپخش توکن |
روش استاندارد آزمون کنترل دسترسی: با هر نقش وارد شوید، مجموعه‌ی کامل درخواست‌های آن نقش را ثبت کنید، سپس هر درخواست را با نشست نقش‌های دیگر و بدون نشست بازپخش کنید و هر سه چیز را مقایسه کنید: کد وضعیت، طول پاسخ و محتوا. برای هر منبع، همه‌ی متدها را جدا بیازمایید (GET، POST، PUT، PATCH، DELETE) — الگوی رایج این است که بررسی مجوز روی GET هست و روی PATCH نیست. مفاهیم پایه در کنترل دسترسی شکسته.
«چون همه‌ی مرورگرها پیش‌فرض SameSite=Lax دارند، CSRF حل شده است.» این نادرست است. Chrome این پیش‌فرض را اعمال میکند، اما Firefox نه — باگ متناظر در Mozilla با وضعیت WONTFIX بسته شده و قابلیت که در Firefox 96 عرضه شده بود، به‌دلیل شکستن سایت‌ها برگردانده شد. Safari سازوکار متفاوتی (مسدودسازی کوکی ثالث) دارد. علاوه بر این، SameSite در سطح دامنه‌ی قابل ثبت عمل میکند نه Origin، پس زیردامنه‌های خواهر آن را دور می‌زنند، و تغییر وضعیت با متد GET همچنان کار میکند. توکن CSRF سمت سرور همچنان الزامی است.
اعتبارسنجی ورودی — INPV (۱۹)
بزرگترین دسته و همان بخشی که ابزارها بیشترین کمک را میکنند. این‌جا خودکارسازی توجیه دارد — اما تأیید نهایی هر یافته دستی است.
| آزمون | نکته‌ی عملی |
|---|---|
| XSS بازتابی | هر پارامتر در هر بافت (HTML، اتریبیوت، JS، URL) — XSS |
| XSS ذخیره‌شده | ورودی‌هایی که بعداً به کاربر دیگری نمایش داده می‌شوند؛ پنل ادمین را فراموش نکنید |
| دستکاری متد HTTP | پذیرش متدهای غیرمنتظره روی مسیرهای حساس |
| آلودگی پارامتر (HPP) | ارسال تکراری یک پارامتر و بررسی اینکه کدام مقدار برنده میشود |
| تزریق SQL | هشت زیرآزمون پایگاه‌داده‌محور به‌علاوه‌ی NoSQL، ORM و سمت کلاینت — SQL Injection |
| تزریق LDAP | در سامانه‌های متصل به Active Directory |
| تزریق XML | مقدمه‌ی XXE؛ در جاوا و آپلود SVG/OOXML جدی‌تر است |
| تزریق SSI | در سرورهای قدیمی با Server Side Includes |
| تزریق XPath | جست‌وجو روی داده‌ی XML |
| تزریق IMAP/SMTP | فرم‌های تماس و سامانه‌های وب‌میل |
| تزریق کد | شامل زیرآزمون‌های LFI و RFI |
| تزریق دستور | شامل تزریق آرگومان که بدون شل هم کار میکند — Command Injection |
| Format String | در کامپوننت‌های بومی و لاگ‌نویسی‌های خاص |
| آسیب‌پذیری پرورش‌یافته | ورودی امروز ذخیره میشود و در جریان دیگری فردا اجرا میشود (تزریق مرتبه‌دوم) |
| HTTP Splitting و Smuggling | اختلاف تفسیر بین پروکسی و بک‌اند |
| درخواست‌های ورودی HTTP | رفتار در برابر درخواست‌های ناهنجار |
| تزریق هدر Host | مسمومیت کش و پیوند بازیابی رمز آلوده |
| SSTI | وقتی ورودی به قالب می‌رسد نه به داده — SSTI |
| SSRF (WSTG-INPV-19) | متادیتای ابری، سرویس داخلی، تشخیص کور با OAST — SSRF |
یک تذکر مهم درباره‌ی SSRF: باور قدیمی «SSRF روی AWS مساوی است با گرفتن فوری اعتبارنامه‌ی IAM» دیگر پیش‌فرض درست نیست. IMDSv2 برای دریافت توکن به درخواست PUT و هدر اختصاصی نیاز دارد و بهصورت پیش‌فرض محدودیت hop برابر ۱ دارد؛ Amazon Linux 2023 و نمونه‌های جدیدتر پیش‌فرض روی IMDSv2 هستند. درست این است که بررسی کنید IMDSv1 فعال است یا نه، نه اینکه فرض بگیرید.
خطا، رمزنگاری و سمت کلاینت — ERRH (۲)، CRYP (۴)، CLNT (۱۳)
نوزده آزمون که دو دستهی کوچک و یک دستهی بزرگ را پوشش می‌دهند.
| دسته | آزمون‌ها |
|---|---|
| ERRH (۲) | مدیریت نامناسب خطا؛ افشای Stack Trace. این‌ها به دستهی جدید A10:2025 مدیریت نادرست شرایط استثنایی هم مربوط‌اند |
| CRYP (۴) | ضعف TLS (نسخه و مجموعه‌رمزها)؛ Padding Oracle؛ انتقال داده‌ی حساس روی کانال رمزنشده؛ رمزنگاری ضعیف در سطح برنامه — TLS |
| CLNT (۱۳) | DOM XSS؛ اجرای JavaScript؛ تزریق HTML؛ تغییر مسیر سمت کلاینت؛ تزریق CSS؛ دستکاری منابع سمت کلاینت؛ CORS؛ Cross-Site Flashing؛ Clickjacking؛ WebSocket؛ پیام‌رسانی وب (postMessage)؛ ذخیره‌سازی مرورگر؛ XSSI |
برای TLS، مبنای فعلی: TLS 1.3 فعال باشد؛ TLS 1.0 و 1.1 طبق RFC 8996 منسوخ‌اند و باید غیرفعال شوند؛ و اگر TLS 1.2 را برای سازگاری نگه می‌دارید، طبق RFC 10015 (جولای ۲۰۲۶) مجموعه‌رمزهای RSA ایستا و همه‌ی خانواده‌ی FFDHE از رده خارج شده‌اند — یعنی فقط ECDHE با AEAD. توصیه‌ی HPKP دیگر معتبر نیست و از مرورگرها حذف شده.
برای بخش سمت کلاینت، دو نکته: اول اینکه DOM XSS را با اسکن سمت سرور پیدا نمی‌کنید، چون بارِ حمله معمولاً در Fragment آدرس است که هرگز به سرور ارسال نمی‌شود؛ ابزار درست، بازرسی مسیر منبع تا سینک در جاوااسکریپت است. دوم، سیاست CSP را ارزیابی کنید ولی به آن به‌عنوان رفع نگاه نکنید: سیاست‌های مبتنی بر فهرست سفید به‌طور ساختاری دور زده می‌شوند و رویکرد درست، nonce بههمراه strict-dynamic است.
منطق کسب‌وکار — BUSL (۹)
نُه آزمون که هیچ‌کدام قابل خودکارسازی نیستند و بیشترین اثر مالی مستقیم را دارند. برای اجرای این بخش، تیم آزمون باید فرایند کسب‌وکار شما را بفهمد — به همین دلیل است که پرسش‌نامه‌ی اسکوپینگ باید سراغ جریان‌های کسب‌وکار برود.
| آزمون | پرسشی که پاسخ می‌دهد |
|---|---|
| اعتبارسنجی داده‌ی منطق کسب‌وکار | آیا مقدار خارج از محدوده‌ی منطقی پذیرفته میشود؟ تعداد منفی، قیمت صفر، تاریخ گذشته |
| امکان جعل درخواست | آیا می‌توان درخواستی ساخت که رابط کاربری هرگز تولید نمیکند؟ |
| بررسی یکپارچگی | آیا داده‌ی حساس (قیمت، تخفیف، شناسه‌ی فروشنده) از سمت کلاینت پذیرفته میشود؟ |
| زمان‌بندی فرایند | آیا با کند یا سریع کردن مراحل، وضعیت غیرمنتظره می‌سازید؟ نقطه‌ی ورود شرایط مسابقه |
| سقف استفاده از تابع | آیا کد تخفیف یکبارمصرف چند بار قابل استفاده است؟ سقف برداشت قابل دور زدن است؟ |
| دور زدن جریان کاری | آیا می‌توان مرحله‌ی پرداخت یا تأیید را حذف کرد و مستقیم به مرحله‌ی نهایی رفت؟ |
| دفاع در برابر سوءاستفاده | آیا برنامه رفتار غیرعادی را تشخیص می‌دهد یا فقط خطا برمی‌گرداند؟ |
| آپلود انواع فایل غیرمنتظره | اعتبارسنجی نوع واقعی فایل، نه پسوند و نه هدر Content-Type |
| آپلود فایل مخرب | محل ذخیره، امکان اجرا، پردازش سمت سرور (تبدیل تصویر، استخراج آرشیو) |
درباره‌ی شرایط مسابقه یک به‌روزرسانی مهم لازم است: تصور «حمله‌ی مسابقه روی اینترنت عملی نیست» منسوخ است. تکنیک single-packet attack با استفاده از چندگانه‌سازی HTTP/2 چندین درخواست کامل را در یک بسته‌ی TCP بسته‌بندی میکند و اثر نویز شبکه را حذف میکند؛ پژوهش PortSwigger میانه‌ی پراکندگی ۱ میلی‌ثانیه را در برابر ۴ میلی‌ثانیه‌ی روش قدیمی گزارش کرده است. پس هر جریان مالی که به وضعیت مشترک دست می‌زند باید تحت بار موازی آزموده شود. نمونه‌ی عملی این آزمون را در نمونه تست نفوذ روایت کردهایم.
API: چرا WSTG-APIT کافی نیست
این را باید صریح گفت: دستهی WSTG-APIT در نسخهی ۴٫۲ فقط یک آزمون دارد و آن هم GraphQL است. WSTG v4.2 متدولوژی جامعی برای REST API نیست. اگر پیمانکاری ادعا میکند «API شما را بر پایه‌ی WSTG کامل آزمودیم»، یا مرجع را نمی‌شناسد یا در حال ساده‌سازی گمراه‌کننده است.
مرجع درست برای API، OWASP API Security Top 10 (نسخهی ۲۰۲۳) است. جدول زیر آن را به‌عنوان چکلیست مکمل ارائه میکند:
| دسته | در عمل چه چیزی را بیازمایید |
|---|---|
| BOLA — مجوزدهی شکسته در سطح شیء | هر شناسه در مسیر و بدنه، با نشست کاربر دیگر |
| احراز هویت شکسته | اعتبارسنجی توکن، عمر، ابطال، مسیرهای بازیابی |
| BOPLA — مجوزدهی شکسته در سطح ویژگی | Mass Assignment در نوشتن، و برگشت فیلدهای اضافی در خواندن |
| مصرف نامحدود منابع | نبود سقف صفحه‌بندی، عملیات سنگین بدون محدودسازی نرخ |
| BFLA — مجوزدهی شکسته در سطح تابع | فراخوانی متد یا مسیر مدیریتی با نقش پایین |
| دسترسی نامحدود به جریان‌های حساس | سوءاستفاده‌ی خودکار از جریان‌هایی مثل ثبت سفارش یا رزرو |
| SSRF | هر پارامتری که سرور را وادار به درخواست بیرونی میکند |
| پیکربندی نادرست | CORS بازتابی، هدرها، افشای خطا، محیط Debug فعال |
| مدیریت نادرست موجودی | نسخه‌های قدیمی API، محیط Staging عمومی، مستندات افشاشده |
| مصرف ناامن APIهای ثالث | اعتماد بدون اعتبارسنجی به پاسخ سرویس بیرونی |
در پایان یک هشدار درباره‌ی خودِ چکلیست: چکلیست پوشش را تضمین میکند، کیفیت را نه. تیمی که فقط ردیف‌ها را تیک می‌زند، همان کاری را میکند که یک اسکنر میکند — با سرعت کمتر. ارزش واقعی وقتی ساخته میشود که تستر از چکلیست خارج شود و بپرسد «این برنامه چه کار میکند و چه چیزی برایش بدترین اتفاق است؟» — و این همان جایی است که مدل‌سازی تهدید وارد میشود. برای دیدن اینکه نتیجه‌ی این کار چگونه مستند میشود گزارش تست نفوذ را ببینید، برای ارزیابی سریع وضعیت خودتان چکلیست امنیتی، و برای اجرای کامل این پوشش خدمات تست نفوذ وب یا درخواست مشاوره.
پرسش‌های متداول
چک لیست تست نفوذ استاندارد کدام است؟
مرجع پذیرفتهشدهی جهانی OWASP Web Security Testing Guide است و نسخهی پایدار جاری آن v4.2 (۳ دسامبر ۲۰۲۰) با دوازده دسته و حدود ۹۷ آزمون. نسخهی ۴٫۳ منتشر نشده و ۵٫۰ در حال توسعه است. برای API باید OWASP API Security Top 10 (۲۰۲۳) را هم به کار برد، چون دستهی WSTG-APIT فقط یک آزمون دارد.
آیا OWASP Top 10 همان چکلیست تست نفوذ است؟
نه. Top 10 یک تاکسونومی ریسک با ده دسته برای طبقهبندی یافتههاست؛ WSTG یک متدولوژی آزمون با آزمونهای نامگذاریشده و شناسهدار. برای بیان پوشش از WSTG استفاده میکنید و برای ردهبندی یافتهها از Top 10 و CWE. این دو کاملاً همراستا هم نیستند؛ نمونهاش SSRF است که در WSTG زیر اعتبارسنجی ورودی و در Top 10:2025 داخل A01 است.
چکلیست را خودمان میتوانیم اجرا کنیم؟
بخشهایی بله و بخشهایی نه. دستههای INFO، CONF، ERRH و CRYP تا حد خوبی با ابزار و دانش عمومی قابل پوششاند و انجامشان توسط تیم داخلی ارزش دارد. دستههای ATHZ و BUSL به تجربهی حملهمحور و ذهنیت سوءاستفاده نیاز دارند و همانجایی هستند که تیم داخلی معمولاً کور است، چون برنامه را از دید طراح میبیند. بحث کامل در تیم تست نفوذ.
کدام دسته از چکلیست بیشترین زمان را میگیرد؟
از نظر تعداد آزمون، INPV با ۱۹ مورد بزرگترین است. اما از نظر زمان واقعی، ATHZ بههمراه BUSL بیشترین زمان را میگیرند، چون تمامدستیاند و با تعداد نقشها بهصورت ترکیبی رشد میکنند. اگر برنامهی شما پنج نقش دارد، آزمون کنترل دسترسی بهتنهایی میتواند بیش از نیمی از بودجهی پروژه را بگیرد — موضوعی که در هزینه تست نفوذ باز کردهایم.
برای هر آزمون چه شواهدی باید نگه داشت؟
برای هر ردیف چکلیست سه چیز: وضعیت (آزموده شد / آسیبپذیر / خارج از دامنه)، شواهد خام (درخواست و پاسخ HTTP کامل) و زمان اجرا. مستندسازی «آزموده شد و مشکلی نبود» هم لازم است، چون همین است که پوشش را اثبات میکند و در آزمون سال بعد مرجع مقایسه میشود.
هر چند وقت یکبار باید کل چکلیست را اجرا کرد؟
پوشش کامل معمولاً سالانه، و آزمون هدفمند روی بخشهای تغییریافته پس از هر انتشار بزرگ. برای سازمانهای مشمول PCI DSS این حداقل هر ۱۲ ماه و پس از هر تغییر مهم زیرساخت یا برنامه الزامی است، و پس از رفع یافتهها آزمون باید تکرار شود. توجه کنید ISO/IEC 27001:2022 دورهی مشخصی تعیین نمیکند و فرایند مبتنی بر ریسک میخواهد.
منابع
- OWASP Web Security Testing Guide — نسخهی پایدار (فهرست کامل آزمون‌ها)
- OWASP WSTG — صفحه‌ی پروژه و تاریخ نسخه‌ها
- OWASP API Security Top 10 (2023)
- OWASP Top 10:2025
- NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
- PortSwigger Research — Smashing the State Machine (single-packet attack)
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.