اگر برای شروع یادگیری تست نفوذ جست‌وجو کرده باشید، ده‌ها نتیجه دیده‌اید که وعده‌ی «هکر شدن در یک ماه» می‌دهند. مشکل این محتوا فقط اغراق نیست؛ ترتیب اشتباه است. تست نفوذ وب مهارتی است که روی چند لایه‌ی پیش‌نیاز بنا می‌شود و اگر لایه‌ی پایینی را جا بیندازید، در سطح «اجرای ابزار» متوقف می‌مانید. این نقشه راه یادگیری تست نفوذ وب همان ترتیبی است که در عمل کار می‌کند: از HTTP و شبکه و لینوکس تا مدل امنیتی مرورگر، دسته‌های آسیب‌پذیری به ترتیب وابستگی، تسلط بر Burp، تمرین روی اهداف قانونی، و در پایان گزارش‌نویسی و اولین موقعیت شغلی.
در یک نگاه
- ترتیب یادگیری مهم‌تر از فهرست منابع است: شبکه و HTTP ← لینوکس ← یک زبان برنامه‌نویسی ← مدل امنیتی مرورگر ← دسته‌های آسیب‌پذیری ← ابزار.
- یک زبان برنامه‌نویسی کافی است، نه پنج زبان. پایتون برای خودکارسازی و جاوااسکریپت برای خواندن سمت کلاینت، انتخاب‌های عملی‌اند.
- Burp Suite Community هیچ اسکنری ندارد — و همین محدودیت در دوره‌ی یادگیری یک مزیت است، چون شما را وادار می‌کند مهارت دستی بسازید.
- تمرین فقط روی اهداف قانونی: Web Security Academy، OWASP Juice Shop، DVWA یا نمونه‌ی خودمیزبان. آزمودن بدون مجوز کتبی، دسترسی غیرمجاز است.
- برنامه‌ی واقع‌بینانه چند فاز چندماهه است. هیچ‌کس نمی‌تواند نتیجه را تضمین کند، اما می‌توان مسیر را طوری چید که هر ماه یک مهارت قابل اثبات اضافه شود.
این مسیر چیست، و چه چیزی نیست
تست نفوذ وب در ماهیت مهارت «فهمیدن» است، نه مهارت «اجرا کردن». کسی که می‌داند یک درخواست HTTP در سمت سرور از چه لایه‌هایی می‌گذرد، بدون هیچ ابزار خودکاری می‌تواند حدس بزند بررسی مجوز کجا احتمالاً فراموش شده است. کسی که فقط دکمه‌ی Scan را می‌شناسد، هرجا اسکنر ساکت باشد ساکت می‌ماند — و بدترین خبر این است که اسکنرها دقیقاً در پرارزش‌ترین دسته‌ها (کنترل دسترسی و منطق کسب‌وکار) ساکت‌اند.
به همین دلیل این نقشه راه بر پایه‌ی ترتیب وابستگی مفاهیم چیده شده، نه بر پایه‌ی فهرست منابع. هر مرحله پیش‌نیاز مرحله‌ی بعد است و پریدن از رویشان صرفه‌جویی در زمان نیست؛ بدهی فنی است که چند ماه بعد به شکل «نمی‌فهمم چرا این پیلود کار نکرد» برمی‌گردد. اگر می‌خواهید ببینید خروجی این مسیر در عمل چه شکلی است، راهنمای تست نفوذ وب کل فرایند یک پروژه‌ی واقعی را از اسکوپ‌بندی تا گزارش شرح می‌دهد.
«در ۳۰ روز هکر شوید.» این پرتکرارترین وعده‌ی این کلیدواژه است و در هیچ نسخه‌ای درست نیست. در ۳۰ روز می‌توانید Burp را نصب کنید، چند آزمایشگاه XSS را حل کنید و یک اسکنر را اجرا کنید. آنچه در ۳۰ روز به‌دست نمی‌آید همان چیزی است که کارفرما بابتش پول می‌دهد: توان پوشش سیستماتیک یک برنامه، تشخیص یافته‌ی واقعی از مثبت کاذب، و نوشتن گزارشی که تیم توسعه بر اساسش کد را عوض کند.
شما فقط مجاز به آزمودن چیزی هستید که مالک آن هستید یا مجوز کتبی صریح برای آزمودنش دارید. «مجوز» یعنی قرارداد، توافق‌نامه‌ی اسکوپ، یا سیاست منتشرشده‌ی یک برنامه‌ی باگ‌بانتی — نه حدس، نه فرم تماس، و نه این استدلال که «سایت آسیب‌پذیر بود». اسکن یک سامانه‌ی متعلق به دیگری بدون مجوز، حتی با نیت خوب، مصداق دسترسی غیرمجاز است و مسیر شغلی شما را پیش از آغاز می‌بندد. تمام تمرین‌های این نقشه راه روی محیط‌های آزمایشگاهی قانونی انجام می‌شود.
پیش‌نیاز اول: شبکه و HTTP
این تنها بخشی از مسیر است که هیچ راه دور زدنی ندارد. آسیب‌پذیری وب در نهایت یک درخواست و پاسخ است؛ اگر نتوانید یک درخواست خام را خط‌به‌خط بخوانید و بگویید هر خط چه کاری می‌کند، هر یافته‌ای برایتان تصادفی خواهد بود.
از شبکه به عمق یک دوره‌ی CCNA نیاز ندارید. به این‌ها نیاز دارید: مدل لایه‌ای و اینکه TCP در برابر UDP چه تفاوتی دارد، DNS و انواع رکورد (و اینکه یک زیردامنه‌ی رهاشده چطور به تسخیر زیردامنه می‌رسد)، NAT و پروکسی و اینکه ترافیک شما دقیقاً از کجا رد می‌شود، و مبانی TLS در سطح «هنگام دست‌دادن چه اتفاقی می‌افتد و گواهی چه چیزی را اثبات می‌کند».
HTTP را در سطح پروتکل بشناسید
- متدها و اینکه چرا یک عملیات تغییردهنده‌ی وضعیت هرگز نباید با GET قابل انجام باشد.
- کدهای وضعیت و معنای دقیق ۴۰۱ در برابر ۴۰۳ — این تفاوت در تست کنترل دسترسی مستقیماً به کار می‌آید.
- هدرها:
Host،Referer،Origin،Content-Type،Authorization، خانواده‌یSec-Fetch-*. - کوکی و نشست: چطور وضعیت در پروتکلی بی‌حالت نگه داشته می‌شود، و چه صفاتی روی کوکی قابل تنظیم است.
- تغییر مسیر، کش و مذاکره‌ی محتوا — سه جایی که رفتار غیرمنتظره زیاد پیدا می‌شود.
- HTTP/2 در برابر HTTP/1.1: چندگانه‌سازی روی یک اتصال. این جزئیات ظاهراً خشک، پایه‌ی حمله‌ی تک‌بسته‌ای در شرایط رقابتی است.
معیار عبور از این مرحله ساده است: این درخواست را ببینید و بتوانید سه فرضیه‌ی آزمون‌پذیر از آن بیرون بکشید.
GET /api/invoice?id=1034 HTTP/1.1
Host: app.example.com
Cookie: session=eyJ1aWQiOjEwMzR9
Origin: https://app.example.com
Sec-Fetch-Site: same-originسه فرضیه‌ی خوب: آیا id در سمت سرور با مالک نشست تطبیق داده می‌شود؟ آیا محتوای کوکی نشست قابل رمزگشایی و دستکاری است؟ آیا اگر هدر Origin را عوض کنم پاسخ همراه با Access-Control-Allow-Credentials برمی‌گردد؟
پیش‌نیاز دوم: تسلط بر لینوکس
بخش عمده‌ی چیزی که آزمون می‌کنید روی لینوکس اجرا می‌شود، و تقریباً همه‌ی ابزارهای این حوزه لینوکس‌بومی‌اند. اما دلیل مهم‌تر این است که بدون درک سیستم‌عامل، بخشی از یافته‌ها را نمی‌فهمید: چرا خواندن /proc/self/environ در پیمایش مسیر ارزشمند است، چرا مجوزهای فایل روی دایرکتوری آپلود سرنوشت یک شل وب را تعیین می‌کند، و چرا یک سرویس systemd که با کاربر root اجرا می‌شود یافته‌ی مستقلی است.
| مهارت لینوکس | چرا در تست نفوذ وب لازم است |
|---|---|
| شل، لوله و تغییر مسیر ورودی/خروجی | ساخت خط لوله‌ی شناسایی؛ خروجی یک ابزار ورودی ابزار بعدی می‌شود |
| سلسله‌مراتب فایل‌سیستم و مجوزها | فهم اینکه با LFI چه فایل‌هایی ارزش خواندن دارند و چرا آپلود در مسیر قابل اجرا فاجعه است |
| پردازش‌ها، سرویس‌ها و systemd | تشخیص سرویس‌های اضافی و کاربرِ اجرای برنامه — مصداق مستقیم پیکربندی نادرست |
پردازش متن: grep، sed، awk، jq، sort -u | کار با خروجی چندهزارخطی ابزارهای شناسایی و پاسخ‌های JSON |
| SSH و مدیریت کلید | کار با ماشین آزمایشگاهی و سرور ابری خودتان |
| مدیریت بسته و کامپایل از سورس | نصب ابزارهایی که در مخزن توزیع شما نیستند |
لاگ‌ها: journalctl و لاگ وب‌سرور | فهم اینکه فعالیت شما چه ردی می‌گذارد — لازمه‌ی گزارش و لازمه‌ی حرفه‌ای‌بودن |
| کانتینر و Docker | راه‌اندازی محیط آسیب‌پذیر آزمایشگاهی در چند دقیقه، بدون آلوده‌کردن سیستم اصلی |
«اول باید کالی لینوکس را به‌عنوان سیستم‌عامل اصلی نصب کنم.» کالی یک توزیع ابزارمحور برای اجرای پروژه است، نه ابزار آموزش لینوکس. نصب کالی به شما لینوکس یاد نمی‌دهد؛ فقط چند صد ابزار می‌دهد که نمی‌دانید کدامشان به چه کاری می‌آید. مسیر بهتر: لینوکس را روی هر توزیع رایج (یا WSL2) یاد بگیرید و کالی را در یک ماشین مجازی برای زمان اجرای پروژه نگه دارید.
یک زبان برنامه‌نویسی — و چرا پایتون و جاوااسکریپت
پرسش «برای تست نفوذ باید برنامه‌نویسی بلد باشم؟» پاسخ کوتاهی دارد: برای شروع نه، برای عبور از سطح متوسط بله. تفاوت بین کسی که در سطح آزمایشگاه متوقف می‌شود و کسی که روی یک برنامه‌ی واقعی مؤثر است، تقریباً همیشه توان اسکریپت‌نویسی است.
پایتون: برای خودکارسازی
در عمل شما مدام به چیزهایی نیاز دارید که ابزار آماده ندارند: بازتولید یک جریان چندمرحله‌ای احراز هویت، تولید هزار شناسه با یک الگوی خاص، مقایسه‌ی هزار پاسخ برای پیدا کردن تفاوت معنادار، یا استخراج اندپوینت از یک فایل JavaScript باندل‌شده. همه‌ی این‌ها یک اسکریپت صدخطی است. سطح لازم: کار روان با کتابخانه‌ی درخواست HTTP، JSON، عبارت باقاعده و حلقه. به‌علاوه Turbo Intruder — ابزار استاندارد آزمون شرایط رقابتی — با پایتون اسکریپت می‌گیرد.
جاوااسکریپت: چون چیزی را که نمی‌خوانید نمی‌توانید تست کنید
در برنامه‌های امروزی بخش بزرگی از منطق در مرورگر اجرا می‌شود. برای پیدا کردن XSS از نوع DOM باید بتوانید مسیر داده را از یک منبع (مثلاً location.hash) تا یک سینک خطرناک (مثلاً innerHTML) دنبال کنید. برای آلودگی پروتوتایپ یا سوءاستفاده از postMessage باید کد را بخوانید. حتی در شناسایی، خواندن باندل و فایل sourcemap یکی از پربازده‌ترین کارهاست، چون اندپوینت‌هایی را لو می‌دهد که در رابط کاربری هیچ لینکی به آن‌ها نیست.
و به‌اندازه‌ی کافی SQL و Bash
بدون فهم SQL، ابزار تزریق برای شما جادو است و نمی‌توانید یافته را از مثبت کاذب تشخیص دهید؛ سطح لازم JOIN، UNION، زیرکوئری و توابع رشته‌ای است. Bash هم چسب خط لوله‌ی شناسایی است. اگر بعدها به افزونه‌نویسی برای Burp رسیدید، آن‌جا زبان جاواست. فهرست کامل و اینکه هر زبان دقیقاً برای چه کاری است، در منابع یادگیری امنیت وب با جزئیات بیشتری آمده.
مدل امنیتی مرورگر: لایه‌ای که همه جا می‌شکند
این مرحله بیشترین بازده را به ازای زمان صرف‌شده دارد و در بیشتر آموزش‌های فارسی کاملاً غایب است. اگر مدل امنیتی مرورگر را بدانید، چهار دسته‌ی آسیب‌پذیری (XSS، CSRF، پیکربندی نادرست CORS و مشکلات کوکی و نشست) به‌جای چهار فهرست پیلود، به یک مدل ذهنی منسجم تبدیل می‌شوند.
- سیاست هم‌مبدأ (Same-Origin Policy): مبدأ از سه‌گانه‌ی طرح‌واره، دامنه و پورت ساخته می‌شود. این پیش‌فرضِ محدودکننده است و همه‌ی مکانیزم‌های دیگر یا آن را شل می‌کنند یا سخت‌تر.
- تفاوت «مبدأ» و «سایت»: این ظریف‌ترین و پرکاربردترین نکته است.
SameSiteروی دامنه‌ی قابل ثبت عمل می‌کند نه روی مبدأ؛ پسa.example.comوb.example.comاز نظر آن هم‌سایت‌اند. نتیجه‌ی مستقیم: یک XSS روی هر زیردامنه، حفاظتSameSiteرا کامل خنثی می‌کند. - صفات کوکی:
HttpOnly،Secure،SameSiteو پیشوندهای__Host-و__Secure-. - CORS سیاست هم‌مبدأ را شل می‌کند؛ خودش کنترل امنیتی نیست. پیکربندی سخاوتمندانه‌ی آن حفاظت را برمی‌دارد، اضافه نمی‌کند.
- CSP یک اقدام کاهنده است، نه رفع آسیب‌پذیری. سیاست مبتنی بر فهرست میزبان‌های مجاز در عمل شکسته است؛ رویکرد درست nonce به‌همراه
strict-dynamicاست. - ذخیره‌سازی سمت کلاینت: هر چیزی که در
localStorageباشد با یک XSS خوانده می‌شود — و توکن‌های JWT اغلب همان‌جا پیدا می‌شوند.
«همه‌ی مرورگرهای مدرن پیش‌فرض SameSite=Lax دارند، پس CSRF حل شده است.» کروم این پیش‌فرض را اعمال می‌کند، اما فایرفاکس نه — تلاش موزیلا برای فعال‌سازی پیش‌فرض Lax به‌دلیل شکستن گسترده‌ی وب کنار گذاشته شد و باگ مربوطه با وضعیت WONTFIX بسته شده. یعنی برنامه‌ای که توکن CSRF ندارد و SameSite را صریحاً تنظیم نکرده، امروز در فایرفاکس آسیب‌پذیر است. توکن سمت سرور همچنان الزامی است.
ابزار این مرحله هم رایگان است: DevTools مرورگر یک سطح آزمون درجه‌یک است، نه ابزار کمکی. نقطه‌ی توقف روی تغییر DOM، پنل Storage برای بررسی صفات کوکی، و جست‌وجو در Sources برای یافتن اندپوینت و کلید در باندل — این‌ها مهارت‌های پایه‌اند.
دسته‌های آسیب‌پذیری، به ترتیب وابستگی
اشتباه رایج، یادگیری الفبایی یا تصادفی آسیب‌پذیری‌هاست. ترتیب زیر بر دو معیار بسته شده: پیش‌نیاز مفهومی هر دسته، و نسبت «تأثیر به هزینه‌ی یادگیری». چارچوب رده‌بندی هم OWASP Top 10:2025 است که نسخه‌ی جاری این فهرست محسوب می‌شود.
| # | دسته | پیش‌نیاز | چرا این جایگاه |
|---|---|---|---|
| ۱ | کنترل دسترسی شکسته و IDOR | HTTP و نشست | رتبه‌ی یک OWASP (A01:2025)؛ کم‌ترین پیش‌نیاز فنی، بیشترین تأثیر، و هیچ اسکنری قابل اعتماد پیدایش نمی‌کند |
| ۲ | تزریق SQL | SQL | مکانیزم شفاف و آموزنده؛ پایه‌ی فهم همه‌ی انواع تزریق |
| ۳ | XSS (بازتابی، ذخیره‌شده، DOM) | جاوااسکریپت و مدل مرورگر | پرحجم‌ترین CWE در داده‌ی جهانی؛ نوع DOM بهترین تمرین ردیابی منبع تا سینک |
| ۴ | CSRF و مسائل کوکی | مدل مرورگر | مستقیماً روی دانش مرحله‌ی قبل سوار می‌شود |
| ۵ | خطاهای احراز هویت و نشست | HTTP و رمزنگاری پایه | A07:2025؛ نیازمند تفکر فرایندی، نه پیلود |
| ۶ | SSRF | شبکه و DNS | در ۲۰۲۵ زیر A01 ادغام شده؛ فهمش بدون دانش شبکه ممکن نیست |
| ۷ | آپلود فایل، پیمایش مسیر و LFI | لینوکس و فایل‌سیستم | مسیر متداول رسیدن به اجرای کد |
| ۸ | SSTI، تزریق دستور، Deserialization | یک زبان سمت سرور | تأثیر بالا اما نیازمند درک زبان و کتابخانه‌ها |
| ۹ | JWT، OAuth و OIDC | رمزنگاری پایه و تفکر جریانی | پرخطاترین ناحیه‌ی برنامه‌های امروزی؛ باگ‌ها منطقی‌اند نه نحوی |
| ۱۰ | شرایط رقابتی | HTTP/2 و هم‌روندی | تکنیک تک‌بسته‌ای عملاً پراش شبکه را حذف کرده و این دسته را دوباره زنده کرده |
| ۱۱ | منطق کسب‌وکار | همه‌ی موارد بالا | پرارزش‌ترین یافته‌ها؛ کاملاً دستی و وابسته به درک فرایند |
و چیزهایی که وقت‌تان را نگیرند
دو موضوع در آموزش‌های قدیمی جای زیادی می‌گیرند و در عمل تقریباً مرده‌اند: RFI (چون allow_url_include در پیکربندی پیش‌فرض PHP خاموش است و از نسخه‌ی ۷٫۴ منسوخ شده) و ترفند بایت تهی برای دور زدن بررسی پسوند (که در PHP 5.3.4 رفع شد). XXE هم دیگر مسئله‌ی همه‌جایی نیست؛ کتابخانه‌های اصلی PHP و پایتون به‌صورت پیش‌فرض ایمن‌اند و شکارگاه واقعی‌اش پشته‌های جاوا و آپلود فایل‌های SVG و OOXML است.
«با React یا Vue می‌نویسیم، پس XSS نداریم.» فریم‌ورک‌های مدرن فقط درج متن را به‌صورت پیش‌فرض کدگذاری می‌کنند. دریچه‌های فرار (dangerouslySetInnerHTML، v-html)، مقادیر URL در صفاتی مثل href که در برابر طرح‌واره‌ی javascript: محافظت نمی‌شوند، تزریق قالب سمت کلاینت، و زنجیره‌های آلودگی پروتوتایپ همه باقی مانده‌اند. مستندات خود React درباره‌ی آن دریچه می‌گوید ایجاد یک آسیب‌پذیری XSS از این راه «بسیار ساده» است.
تسلط بر Burp Suite — و چرا نسخه‌ی رایگان برای یادگیری بس است
پروکسی رهگیر، ستون فقرات آزمون دستی وب است. ترتیب یادگیری داخل خود ابزار هم اهمیت دارد: Proxy و تاریخچه ← Repeater ← Intruder ← (در نسخه‌ی حرفه‌ای) Scanner و Collaborator. کسی که Repeater را عمیق بلد است از کسی که فقط Scanner را می‌شناسد بسیار مؤثرتر است، چون بیشتر یافته‌های واقعی از تکرار دستی یک درخواست با تغییرات کوچک بیرون می‌آیند.
جدول زیر مرز دقیق نسخه‌ی رایگان و حرفه‌ای است. این مرز را بدانید تا وقت‌تان را برای پیدا کردن قابلیتی که وجود ندارد تلف نکنید.
| قابلیت | Community | یادداشت عملی |
|---|---|---|
| پروکسی HTTP(S) و WebSocket، تاریخچه | دارد | ۹۰٪ کار یادگیری همین‌جا انجام می‌شود |
| Repeater، Decoder، Comparer، Sequencer | دارد | Repeater را به سطح رفلکس برسانید |
| DOM Invader | دارد | در Community هم موجود است؛ بهترین ابزار رایگان شکار XSS از نوع DOM |
| Intruder کامل | ندارد | نسخه‌ی نمایشی به‌شدت کندشده است؛ برای فازینگ واقعی از ffuf استفاده کنید |
| Burp Scanner | ندارد | هیچ اسکنر خودکاری در Community نیست |
| Burp Collaborator | ندارد | یعنی تشخیص آسیب‌پذیری‌های کور خارج از باند ممکن نیست |
| ذخیره‌ی پروژه، جست‌وجو در پروژه، گزارش خودکار | ندارد | محدودیت جدی در پروژه‌ی واقعی، نه در یادگیری |
«Burp Community یک اسکنر محدود دارد.» ندارد. اسکنر Burp به‌طور کامل قابلیت نسخه‌ی حرفه‌ای است و Collaborator هم همین‌طور. در مقابل، ادعای دیگری که زیاد تکرار می‌شود هم غلط است: DOM Invader قابلیت انحصاری نسخه‌ی حرفه‌ای نیست و در Community در دسترس است.
مسیر پیشنهادی: چند ماه اول را کامل با Community کار کنید. نبود اسکنر شما را مجبور می‌کند خودتان درخواست‌ها را مرور کنید و همین چیزی است که مهارت می‌سازد. توضیح گام‌به‌گام هر بخش ابزار در مدخل Burp Suite دانشنامه آمده است. اگر بعدها به‌عنوان جایگزین سبک‌تر برای کار دستی سراغ گزینه‌های دیگر رفتید، فقط این را بدانید که هیچ‌کدام معادل اسکنر و سرویس خارج از باند Burp را ندارند.
آزمایشگاه: تمرین روی اهداف قانونی
مهارت از تمرین می‌آید، اما تمرین باید جایی انجام شود که قانونی و آموزنده باشد. چهار گزینه‌ی معتبر:
- PortSwigger Web Security Academy — رایگان، با آزمایشگاه‌های تعاملی و درجه‌بندی از مقدماتی تا پیشرفته. از نظر کیفیت و به‌روزبودن، از بیشتر دوره‌های پول‌دار جلوتر است و مرجع عملی همین حوزه محسوب می‌شود.
- OWASP Juice Shop — برنامه‌ای آسیب‌پذیر با پشته‌ی مدرن جاوااسکریپت. به برنامه‌های واقعی امروزی نزدیک‌تر است و برای تمرین API و منطق کسب‌وکار خوب است.
- DVWA — کلاسیک و ساده، مناسب فهم مکانیزم خام تزریق SQL و LFI. بدانید که پشته‌اش قدیمی است و نباید تصویر شما از وب امروز را شکل بدهد.
- محیط خودمیزبان — نسخه‌ای از برنامه‌ی خودتان یا یک پروژه‌ی متن‌باز که در Docker بالا می‌آورید. این بهترین تمرین است، چون هم کد را دارید و هم مجوز کامل.
چطور تمرین کنیم که یاد بگیریم
هر آزمایشگاه را سه‌مرحله‌ای تمام کنید: اول حلش کنید، بعد بدون نگاه‌کردن به راهنما مکانیزم را برای خودتان توضیح دهید، و در آخر در سه پاراگراف بنویسید که نقص کجای کد بود و رفع درستش چیست. مرحله‌ی سوم است که تمرین را به مهارت تبدیل می‌کند — و تصادفی نیست که همان مهارت گزارش‌نویسی است.
هیچ سایت واقعیِ متعلق به دیگری، هدف تمرین نیست — حتی اگر جایی به‌عنوان «سایت آسیب‌پذیر برای تمرین» معرفی شده باشد. تنها استثنا برنامه‌های باگ‌بانتی است، و آن هم فقط در چارچوب دقیق اسکوپ و سیاست منتشرشده‌ی همان برنامه. نحوه‌ی ورود درست به این فضا در راهنمای یادگیری باگ‌بانتی توضیح داده شده است.
پوشش سیستماتیک هم اهمیت دارد: بعد از حل چند ده آزمایشگاه، فهرست آزمون‌های راهنمای WSTG را به‌عنوان چک‌لیست بردارید و ببینید کدام دسته‌ها را هرگز تمرین نکرده‌اید. تفاوت آماتور و حرفه‌ای اغلب در همان دسته‌های فراموش‌شده است.
خواندن گزارش‌های افشاشده و نوشتن گزارش
دو مهارت که در هیچ دوره‌ای جدی گرفته نمی‌شوند و بیشترین اثر را روی حرفه‌ای‌شدن دارند.
خواندن گزارش‌های افشاشده
گزارش‌های عمومی برنامه‌های باگ‌بانتی و رایت‌آپ‌های محققان، تنها جایی است که مسیر فکری یک تست را می‌بینید: چه چیزی توجه محقق را جلب کرد، چه فرضیه‌هایی را رد کرد، و چطور یک باگ کم‌شدت را به یک زنجیره‌ی پرتأثیر تبدیل کرد. هفته‌ای دو گزارش بخوانید و برای هرکدام یک جمله بنویسید: «الگوی قابل تعمیم این گزارش چه بود؟» بعد از پنجاه گزارش، شما یک کتابخانه‌ی ذهنی از الگوها دارید که هیچ فهرست پیلودی نمی‌دهد. فهرست منابع معتبر این دسته در منابع یادگیری امنیت وب آمده است.
نوشتن گزارش
یک یافته‌ی بدون گزارش خوب، عملاً وجود ندارد. ساختار حرفه‌ای:
- عنوان که خودِ مشکل و مکانش را بگوید، نه نام دسته را.
- شدت با امتیاز
CVSSو ذکر صریح اینکه از چه نسخه‌ای استفاده کرده‌اید — نسخه‌ی جاری v4.0 است اما v3.1 هنوز در داده‌ی واقعی غالب است و هر دو قابل‌دفاع‌اند، به شرط شفافیت. - مراحل بازتولید به‌قدری دقیق که یک توسعه‌دهنده بدون تماس با شما بتواند تکرار کند.
- شاهد: درخواست و پاسخ خام، و اثبات مفهوم غیرتسلیحاتی — کوچک‌ترین چیزی که وجود مشکل را اثبات کند، نه بیشتر.
- تأثیر به زبان کسب‌وکار: «مهاجم می‌تواند فاکتور همه‌ی کاربران را بخواند»، نه «پارامتر اعتبارسنجی نشده است».
- راهکار رفع، مرتب‌شده بر اساس اثربخشی.
«راهکار رفع: قرار دادن WAF.» این جمله در یک گزارش حرفه‌ای جایی ندارد. WAF یک کنترل جبرانی و خریدار زمان است؛ نسبت به کنترل دسترسی شکسته ساختاراً کور است، منطق کسب‌وکار را نمی‌فهمد، و قابل دور زدن است. راهکار رفع، تغییر کد است؛ قاعده‌ی WAF حداکثر یک اقدام موقت.
فازهای مسیر و زمان‌بندی واقع‌بینانه
بازه‌های زیر بر فرض تمرین منظم روزانه (حدود دو ساعت) نوشته شده‌اند. با زمان کمتر، بازه‌ها به‌همان نسبت طولانی‌تر می‌شوند. این‌ها تخمین است، نه تعهد — سرعت یادگیری افراد به پیش‌زمینه‌ی فنی‌شان بستگی دارد و هیچ برنامه‌ای نمی‌تواند نتیجه را تضمین کند.
| فاز | تمرکز | معیار عبور | بازه‌ی تقریبی |
|---|---|---|---|
| صفر — پایه | شبکه، HTTP، لینوکس، مبانی یک زبان | یک درخواست خام را خط‌به‌خط توضیح می‌دهید و یک اسکریپت صدخطی می‌نویسید | ۲ تا ۴ ماه |
| یک — مدل مرورگر و سه دسته‌ی اول | SOP، کوکی، CORS، CSP + کنترل دسترسی، تزریق SQL، XSS | هر سه دسته را در آزمایشگاه بازتولید و مکانیزمشان را تشریح می‌کنید | ۲ تا ۳ ماه |
| دو — ابزار و تمرین سیستماتیک | Burp، ffuf، شناسایی + حل حجمی آزمایشگاه | یک برنامه‌ی آزمایشگاهی را بدون راهنما به‌صورت کامل پوشش می‌دهید | ۳ تا ۴ ماه (همپوشان با فاز یک) |
| سه — پوشش کامل و گزارش | باقی دسته‌ها، چک‌لیست WSTG، CVSS، گزارش‌نویسی | یک گزارش کامل چندیافته‌ای می‌نویسید که خواندنی و قابل اقدام است | ۲ تا ۳ ماه |
| چهار — تخصص و خروجی عمومی | یک شاخه‌ی عمیق (API، منطق کسب‌وکار، احراز هویت) + رایت‌آپ و ابزار | خروجی قابل بررسی عمومی دارید | پیوسته |
سه نکته‌ی صادقانه درباره‌ی این جدول: اول، فازها همپوشانی دارند و خطی نیستند. دوم، «معیار عبور» مهم‌تر از «بازه» است؛ اگر معیار محقق نشده، عبور از فاز فقط خودفریبی است. سوم، اگر مسیر شما آموزش تیمی است نه فردی — یعنی می‌خواهید تیم توسعه‌ی یک شرکت را به سطح قابل قبولی برسانید — منطق زمان‌بندی کاملاً متفاوت است و در راهنمای انتخاب دوره و آموزش توسعه‌ی امن و دوره‌های سازمانی توسعه‌ی امن توضیح داده شده است.
اولین موقعیت شغلی یا اولین باگ
در پایان فاز سه، دو مسیر پیش روی شماست و هیچ‌کدام بر دیگری برتری مطلق ندارد.
مسیر استخدام
بازار به خروجی قابل بررسی نگاه می‌کند: رایت‌آپ‌های تحلیلی، یک ابزار کوچک منتشرشده، قاعده‌ی SAST یا قالب اسکن که نوشته‌اید، و نمونه‌گزارشی که روی یک محیط آزمایشگاهی نوشته‌اید و می‌توانید بدون نقض محرمانگی نشان دهید. یک مسیر کم‌گفته‌شده اما بسیار عملی هم وجود دارد: ورود از سمت توسعه. اگر توسعه‌دهنده‌اید، نقش «قهرمان امنیت» درون تیم خودتان سریع‌ترین راه رسیدن به کار امنیتی واقعی است. تصویر کامل نقش‌ها و مسیر رشد در بازار کار و مسیر شغلی امنیت سایبری آمده است.
مسیر باگ‌بانتی
باگ‌بانتی یک آزمایشگاه واقعی با مجوز است و برای ساختن رزومه بی‌نظیر است، اما درآمدش نامنظم است: تکراری‌بودن گزارش (Duplicate) بخش عادی کار است و رسیدن به اولین پاداش می‌تواند ماه‌ها طول بکشد. با دید «مکمل» به آن نگاه کنید، نه جایگزین حقوق.
قدم بعدی، بسته به جایی که ایستاده‌اید
- هنوز پایه ندارید: از فاز صفر شروع کنید و دوره‌ها و مسیر یادگیری را برای ترتیب مطالب ببینید.
- پایه دارید و می‌خواهید دسته‌ها را عمیق کنید: دانشنامه را دسته‌به‌دسته بخوانید و هر مدخل را همان روز در آزمایشگاه بازتولید کنید.
- می‌خواهید بدانید کارفرما چه می‌خواهد: بازار کار امنیت سایبری و سپس رزومه‌سازی.
- مسئول یک تیم توسعه‌اید و مسیرتان آموزش تیمی است: دوره‌ی سازمانی توسعه‌ی امن برای همین نوشته شده.
و یک یادآوری آخر، چون بیشترین آسیب را همین می‌زند: هر چیزی که یاد می‌گیرید فقط روی دارایی خودتان یا با مجوز کتبی اجرا شود. مهارت فنی بدون این انضباط، سرمایه نیست؛ ریسک است.
پرسش‌های متداول
برای یادگیری تست نفوذ وب از کجا شروع کنم؟
از HTTP و شبکه، نه از ابزار. تا وقتی نتوانید یک درخواست و پاسخ خام را خط‌به‌خط توضیح دهید، هر آموزش ابزاری سطحی می‌ماند. ترتیب پیشنهادی: شبکه و HTTP، سپس لینوکس، سپس مبانی یک زبان (پایتون یا جاوااسکریپت)، سپس مدل امنیتی مرورگر، و بعد از آن آسیب‌پذیری‌ها به ترتیب وابستگی — با شروع از کنترل دسترسی شکسته که هم کم‌ترین پیش‌نیاز را دارد و هم بیشترین تأثیر.
یادگیری تست نفوذ چقدر طول می‌کشد؟
با تمرین منظم روزانه، معمولاً چند ماه تا رسیدن به سطح آزمایشگاهی مستقل و حدود یک سال تا سطحی که بتوانید یک برنامه‌ی واقعی را به‌صورت سیستماتیک پوشش دهید و گزارش قابل اقدام بنویسید. این بازه تخمین است نه تعهد، و به پیش‌زمینه‌ی فنی شما بستگی دارد. هر محتوایی که عدد قطعی یا «هکر شدن در ۳۰ روز» وعده می‌دهد، چیزی می‌فروشد.
برای تست نفوذ باید برنامه‌نویسی بلد باشم؟
برای شروع خیر، برای عبور از سطح متوسط بله. یک زبان کافی است: پایتون برای خودکارسازی و نوشتن ابزار کوچک، و جاوااسکریپت برای خواندن کد سمت کلاینت — چون چیزی را که نمی‌توانید بخوانید نمی‌توانید تست کنید. به‌علاوه به‌اندازه‌ی کافی SQL برای فهم آسیب‌پذیری تزریق و Bash برای چسباندن خط لوله‌ی شناسایی.
آیا برای شروع باید کالی لینوکس نصب کنم؟
لازم نیست. کالی یک توزیع ابزارمحور برای زمان اجرای پروژه است، نه ابزار آموزش لینوکس. لینوکس را روی هر توزیع رایج یا WSL2 یاد بگیرید و کالی را داخل یک ماشین مجازی نگه دارید. نصب کالی به‌عنوان سیستم اصلی، مهارت اضافه نمی‌کند و فقط چند صد ابزار در اختیار شما می‌گذارد که نمی‌دانید کدامشان به چه کاری می‌آید.
نسخه‌ی رایگان Burp Suite برای یادگیری کافی است؟
بله، و برای چند ماه اول حتی بهتر است. Community پروکسی، تاریخچه، Repeater، Decoder، Comparer و DOM Invader را دارد که مجموعاً بخش عمده‌ی کار یادگیری است. آنچه ندارد: Burp Scanner (به‌طور کامل)، Collaborator، Intruder کامل و ذخیره‌ی پروژه. نبود اسکنر در دوره‌ی یادگیری یک مزیت است چون شما را وادار می‌کند خودتان درخواست‌ها را بررسی کنید؛ برای فازینگ هم ffuf جایگزین رایگان و سریع‌تری است.
تمرین تست نفوذ روی چه محیطی قانونی است؟
فقط روی چیزی که مالکش هستید یا مجوز کتبی صریح برای آزمودنش دارید. گزینه‌های قانونی و رایگان: PortSwigger Web Security Academy، OWASP Juice Shop، DVWA، و برنامه‌های آسیب‌پذیری که خودتان در Docker بالا می‌آورید. برنامه‌های باگ‌بانتی هم قانونی‌اند اما فقط در چارچوب دقیق اسکوپ و سیاست منتشرشده‌شان. آزمودن هر سامانه‌ی دیگری بدون مجوز، مصداق دسترسی غیرمجاز است.
منابع
مهدی مرادلو
محقق امنیتی با تمرکز روی منطق کسب‌وکار و زنجیره‌های حمله‌ی پیچیده. اسکوپ‌بندی پروژه‌ها و تضمین کیفیت گزارش‌ها با اوست.