دو پژوهشگر می‌توانند دقیقاً یک آسیبپذیری را پیدا کنند و نتایج کاملاً متفاوتی بگیرند: یکی در چند روز پاداش کامل می‌گیرد و دیگری گزارشش با وضعیت «قابل بازتولید نیست» بسته میشود. متغیر تعیین‌کننده، رایت آپ است. تیم تریاژ به ذهن شما دسترسی ندارد؛ فقط متن شما را دارد و معمولاً ده‌ها گزارش دیگر هم در صف دارد. این مقاله آناتومی یک گزارش قابل‌اقدام را بخش‌به‌بخش توضیح می‌دهد، یک نمونه گزارش باگ بانتی کامل و بی‌نام‌سازی‌شده می‌آورد، همان یافته را در قالب یک گزارش ضعیف هم نشان می‌دهد، و درباره‌ی مرز اخلاقی اثبات آسیبپذیری و زمان‌بندی افشا صریح حرف می‌زند.
در یک نگاه
- گزارش خوب یک هدف دارد: تریاژر باید بدون حدس‌زدن و بدون پرسیدن بتواند یافته را بازتولید کند.
- بیان اثر کسبوکاری — نه نام فنی باگ — بزرگ‌ترین تفاوت میان پاداش کم و پاداش بالا است.
- شدت را همیشه با بردار کامل و ذکر نسخه بنویسید (CVSS v4.0 یا v3.1)، نه با یک عدد تنها.
- اثبات باید با حداقل دادهی لازم باشد؛ استخراج انبوه داده نقض اسکوپ است و Safe Harbour را باطل میکند.
- افشای عمومی فقط پس از مجوز و طبق سیاست برنامه مجاز است؛ هیچ مهلت خودکاری به شما حق انتشار نمیدهد.
تریاژر چه می‌بیند و چرا گزارش‌ها کند پیش می‌روند
تصور کنید تریاژری هستید با بیست گزارش در صف. برای هر گزارش باید تصمیم بگیرید: داخل اسکوپ است؟ بازتولید میشود؟ تکراری است؟ شدتش چقدر است؟ در این شرایط هر ابهام هزینه دارد و رفتار عقلانی این است که گزارش مبهم به انتهای صف برود. سه علت اصلی کندی یا رد شدن گزارش‌ها هیچ‌کدام فنی نیستند:
- مراحل بازتولید ناقص: نقش کاربر مشخص نیست، مقدار پارامتر ذکر نشده، یا پیش‌نیاز نامرئی وجود دارد (مثلاً «باید ابتدا یک سفارش ثبت شده باشد»).
- ابهام در اثر: گزارش می‌گوید چه چیزی رخ داده اما نمی‌گوید چرا اهمیت دارد.
- ناسازگاری با اسکوپ: دارایی خارج از محدوده است یا کلاس آسیبپذیری پذیرفته نمی‌شود — چیزی که با یک بار خواندن دقیق اسکوپ قابل پیشگیری بود.
پس معیار کیفیت گزارش را این‌گونه تعریف کنید: هزینهی زمانی که برای تریاژر ایجاد میکند. هر جمله‌ای که این هزینه را زیاد کند — حتی اگر فنی و درست باشد — به زیان شماست. همین منطق در گزارش تست نفوذ حرفه‌ای هم حاکم است.
آناتومی یک گزارش قابل‌اقدام
ترتیب زیر تصادفی نیست: از بالاترین سطح انتزاع به جزئیات می‌رود، تا تریاژر در سه خط اول بداند با چه چیزی روبروست.
| بخش | چه چیزی بنویسید | خطای رایج |
|---|---|---|
| عنوان | اثر + دارایی + کلاس آسیبپذیری، در یک خط | «یک باگ بحرانی پیدا کردم!» |
| خلاصه | دو تا سه جمله؛ چه چیزی، کجا، چه اثری | شروع مستقیم با پیلود |
| دارایی و اندپوینت | دامنه، مسیر کامل، متد و پارامتر آسیب‌پذیر | فقط نام دامنه |
| پیشنیازها | نقش‌های لازم، وضعیت اولیه‌ی داده، مرورگر یا ابزار | ذکر نشدن اینکه دو حساب لازم است |
| مراحل بازتولید | گام‌های عددگذاریشده و قطعی با مقادیر واقعی | «پارامتر را تغییر دهید» |
| شواهد | درخواست و پاسخ سانسورشده، تصویر یا ویدئوی کوتاه | تصویر بی‌زمینه بدون درخواست HTTP |
| اثر | پیامد به زبان کسبوکار و دامنه‌ی تأثیر | «میتواند خطرناک باشد» |
| شدت | بردار کامل CVSS + نسخه + استدلال کوتاه | نوشتن «Critical» بدون بردار |
| راهکار رفع | پیشنهاد فنی مشخص در سطح کد یا معماری | «یک WAF بگذارید» |
| ارجاعات | شناسه‌ی CWE، دستهی OWASP، آزمون WSTG | لینک به یک وبلاگ متفرقه |
درباره‌ی سطر «راهکار رفع» تأکید داریم: هرگز فایروال برنامه‌ی وب را بهعنوان راه‌حل یک باگ در کد پیشنهاد نکنید. WAF یک کنترل جبرانی و خریدار زمان است و در برابر نقص کنترل دسترسی ساختاراً نابیناست؛ پیشنهاد آن به‌جای اصلاح کد، نشانه‌ی ناآشنایی با موضوع تلقی میشود.
عنوان و مراحل بازتولید: دو بخشی که سرنوشت گزارش را می‌سازند
عنوان: اثر را بگو، نه نام باگ
عنوان تنها چیزی است که در فهرست گزارش‌ها دیده میشود و اولویت‌بندی اولیه بر پایهی آن انجام میشود. سه نمونه، از بد به خوب:
- ❌ «آسیبپذیری IDOR» — نه دارایی دارد، نه اثر.
- ⚠️ «IDOR در
/api/v2/invoices» — دارایی دارد، اثر ندارد. - ✅ «IDOR در
/api/v2/invoices/{id}: هر کاربر احراز هویت‌شده میتواند فاکتور و شماره تماس سایر کاربران را بخواند» — اثر، دامنه‌ی تأثیر و محل، همه در یک خط.
مراحل بازتولید
قاعده‌ی طلایی: گزارش را طوری بنویسید که یک نفر ناآشنا با یافته فقط با خواندن آن نتیجه را بازتولید کند:
- نقش کاربر هر گام را مشخص کنید («با حساب A وارد شوید»).
- مقادیر واقعی بنویسید، نه توصیف («شناسه‌ی
10432» نه «شناسه‌ی کاربر دیگر»). - هر گام یک کنش باشد و نتیجهی مورد انتظار را بنویسید.
- اگر ترتیب یا زمان‌بندی مهم است — مثل شرایط رقابتی — ابزار و روش هم‌زمان‌سازی را ذکر کنید؛ و اگر یافته غیرقطعی است، همین را بنویسید. پنهان‌کردنش فقط باعث بسته‌شدن گزارش میشود.
درخواست‌های HTTP را بهصورت متن خام بگذارید، نه تصویر: تریاژر باید بتواند آن‌ها را کپی و در Burp اجرا کند.
شواهد و اثبات مفهوم غیرتسلیحاتی
اثبات مفهوم (PoC) باید کمترین چیزی باشد که وجود مشکل را ثابت میکند — نه بیشترین چیزی که می‌توانید انجام دهید. این تفکیک، هم اخلاقی است و هم حقوقی: عبور از آن، مجوز شما را باطل میکند.
قواعدی که هر پژوهشگر حرفه‌ای رعایت میکند:
- حداقل داده: برای اثبات خواندن دادهی کاربر دیگر، یک رکورد کافی است. استخراج هزار رکورد اثبات قوی‌تری نیست؛ نقض اسکوپ است.
- سانسور دادهی شخصی: شماره تماس، کد ملی، ایمیل و شماره کارت را در شواهد ماسک کنید.
- بدون ماندگاری: شل معکوس، حساب پشتی یا فایل باقی‌مانده، هیچ‌کدام. اگر ناچار به نوشتن چیزی شدید، همان را در گزارش اعلام کنید تا پاک شود.
- بدون آسیب: نه تغییر دادهی تولیدی، نه آزمون منع سرویس، نه ارسال انبوه.
- هدف روی حساب خودتان و پیلود بی‌ضرر: برای XSS ذخیره‌شده پیلود را روی حساب آزمون خودتان بگذارید، نه در بخشی که به کاربران واقعی نمایش داده میشود؛ و از نشانگر بی‌خطر استفاده کنید، نه کدی که داده به بیرون ارسال میکند.
«هرچه دادهی بیشتری استخراج کنم، اثبات قوی‌تر و پاداش بیشتر است.» عکس آن درست است. استخراج انبوه داده تقریباً در همهی سیاست‌های باگ بانتی صریحاً ممنوع است، پوشش Safe Harbour را از بین می‌برد، میتواند به رخداد امنیتی گزارشپذیر برای سازمان تبدیل شود و شما را از حالت «پژوهشگر مجاز» به حالت «مهاجم» منتقل میکند. قواعد آزمون امن را در سیاست افشای مسئولانه ببینید.
اثر کسبوکاری: مهم‌ترین بخش گزارش
این تک‌عامل بیشترین تفاوت را در پاداش ایجاد میکند، چون تصمیم پرداخت را کسی می‌گیرد که ریسک را بر حسب پیامد سازمانی می‌سنجد، نه نام فنی باگ. برای نوشتن این بخش به چهار پرسش پاسخ دهید:
- مهاجم چه چیزی به دست می‌آورد؟ کدام داده، کدام قابلیت، کدام سطح دسترسی.
- مقیاس چقدر است؟ یک کاربر، همهی کاربران، یا همهی مستأجرها؟ خودکارسازی‌پذیر است؟
- پیش‌نیاز مهاجم چیست؟ کاربر بی‌نام، کاربر ثبت‌نام‌شده‌ی معمولی، یا نیازمند تعامل قربانی؟ اثر یک یافته با پیش‌نیاز «هر حساب رایگان» به‌مراتب بالاتر از یافته‌ای است که نیازمند دسترسی مدیر است.
- چه چیزی را میشود به آن زنجیر کرد؟ یک تغییر مسیر باز به‌تنهایی کم‌ارزش است، اما بهعنوان حلقه‌ای در سرقت کد مجوز OAuth یا دور زدن فیلتر SSRF، یافته‌ای جدی است. اگر زنجیره را نشان دهید، شدت واقعی را نشان داده‌اید.
مقایسه‌ی دو جمله برای یک یافتهی یکسان: «پارامتر id قابل تغییر است و اطلاعات کاربر دیگر برمی‌گردد» در برابر «هر حساب رایگان میتواند با شمارش عددی شناسه، فاکتور و شماره تماس همهی مشتریان را بخواند و این کار قابل خودکارسازی است». جمله‌ی دوم اطلاعات فنی بیشتری ندارد؛ فقط پیامد را قابل تصمیم‌گیری کرده است.
شدت: بردار CVSS و ذکر نسخه
نسخهی جاری CVSS نسخهی ۴٫۰ است که در نوامبر ۲۰۲۳ منتشر شد. با این حال در دادهی واقعی آسیبپذیریها همچنان v3.1 غالب است؛ در مجموعه‌داده‌ای که OWASP برای نسخهی ۲۰۲۵ فهرست Top 10 تحلیل کرد، از حدود ۲۲۰٬۰۰۰ رکورد CVE حدود ۱۵۶ هزار مورد امتیاز v3 داشتند و فقط حدود ۶ هزار مورد امتیاز v4. پس هر دو نسخه قابل دفاع است، به شرط آنکه صریحاً بنویسید از کدام استفاده کرده‌اید.
سه قاعده‌ی حرفه‌ای:
- بردار را بنویسید، نه فقط عدد. عدد بدون بردار قابل بازبینی نیست و اختلاف‌نظر را حل نمی‌کند.
- در v4.0 از نام‌گذاری رسمی استفاده کنید. اگر فقط سنجه‌های پایه را محاسبه کرده‌اید، آن را
CVSS-Bبنامید؛ افزودن سنجه‌های تهدید و محیطی، برچسب‌هایCVSS-BTوCVSS-BEرا می‌سازد. این نام‌گذاری دقیقاً برای پایان دادن به عادت ارائه‌ی امتیاز پایه به‌جای ارزیابی کامل معرفی شد. - سنجه‌های محیطی را برای سازمان بگذارید. اهمیت دارایی و کنترل‌های جبرانی اطلاعاتی است که شما ندارید؛ کار شما بردار پایهی درست و توضیح اثر است.
«شدت را بالاتر بنویسم تا پاداش بیشتری بگیرم.» بزرگ‌نمایی شدت سریعترین راه از دست دادن اعتبار نزد تیم تریاژ است و در برنامه‌های خصوصی، سابقه‌ی شما را خراب میکند. اگر بردار درست باشد و اثر خوب توضیح داده شده باشد، شدت خودش را بالا می‌برد. برای نگاشت یافته به دستهی درست، OWASP Top 10:2025 را مبنا بگیرید.
نمونه گزارش کامل: یک IDOR روی target.example
نمونه‌ی زیر بی‌نام‌سازی‌شده و روی دامنه‌ی نمونه‌ی target.example نوشته شده. یافته یک IDOR است؛ نمونه‌ای بی‌خطر برای آموزش، چون اثبات آن به هیچ کد سوءاستفاده‌ای نیاز ندارد.
عنوان
IDOR در GET /api/v2/invoices/{id}: هر کاربر احراز هویت‌شده میتواند فاکتور و شماره تماس سایر کاربران را بخواند
خلاصه
اندپوینت فاکتور، شناسه‌ی عددی مسیر را بدون بررسی مالکیت رکورد پردازش میکند. یک حساب معمولی میتواند با تغییر شناسه، فاکتور هر کاربر دیگری را دریافت کند. شناسه‌ها متوالی‌اند، بنابراین شمارش کامل امکان‌پذیر است.
دارایی و پیش‌نیاز
دارایی: https://target.example (داخل اسکوپ). پیش‌نیاز: دو حساب آزمون معمولی و بدون دسترسی ویژه؛ حساب A متعلق به آزمون‌گر و حساب B حساب آزمون دوم. هیچ تعاملی از سمت قربانی لازم نیست.
مراحل بازتولید
- با حساب B وارد شوید، یک سفارش ثبت کنید و شناسه‌ی فاکتور صادرشده را یادداشت کنید (در این آزمون:
10432). - از حساب B خارج شوید و با حساب A وارد شوید.
- درخواست زیر را با نشست حساب A ارسال کنید:
GET /api/v2/invoices/10432 HTTP/1.1 Host: target.example Cookie: session=<session-of-account-A> Accept: application/json - پاسخ
200 OKبا محتوای فاکتور حساب B بازگردانده میشود (مقادیر شخصی در شواهد ماسک شده‌اند):HTTP/1.1 200 OK Content-Type: application/json {"id":10432,"owner":"account-B", "phone":"0912*****"} - نتیجهی مورد انتظار در صورت پیاده‌سازی درست:
403 Forbiddenیا404 Not Found.
اثر
هر کاربر ثبت‌نام‌شده — از جمله حساب‌های رایگان — میتواند فاکتور، مبلغ و شماره تماس سایر مشتریان را بخواند. چون شناسه‌ها متوالی‌اند، این خواندن با یک اسکریپت ساده در مقیاس کل پایگاه مشتریان قابل خودکارسازی است. پیامد، افشای گسترده‌ی دادهی شخصی و تجاری است. در این آزمون فقط یک رکورد و آن هم متعلق به حساب آزمون دوم خوانده شد و هیچ داده‌ای نگه‌داری نشده است.
شدت
CVSS v3.1 — بردار AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N، امتیاز پایه ۶٫۵ (Medium). معادل v4.0 بهصورت CVSS-B با بردار AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N ارائه میشود. توجه: اگر دادهی افشاشده در طبقه‌بندی سازمان «حساس» باشد، سنجه‌های محیطی می‌توانند شدت مؤثر را بالاتر ببرند.
ارجاعات و راهکار رفع
CWE-639 (دور زدن مجوز از طریق کلید تحت کنترل کاربر) و CWE-862 (نبود بررسی مجوز)؛ دستهی A01:2025 در کنترل دسترسی شکسته. رفع: اعمال بررسی مالکیت در لایه‌ی دسترسی به داده و برای همهی متدها — الگوی WHERE id = ? AND owner_id = ? — به‌جای بررسی پس از واکشی؛ رد پیش‌فرض؛ و ثبت لاگ و هشدار برای شکست‌های مجوزدهی. تغییر شناسه به UUID به‌تنهایی راه‌حل نیست، چون بررسی مجوز اضافه نمی‌کند.
همان یافته، در قالب یک گزارش ضعیف
گزارش ضعیفی که برای همین یافته زیاد دیده میشود چنین چیزی است: «سلام. سایت شما IDOR دارد. در بخش فاکتورها می‌توانید id را عوض کنید و اطلاعات بقیه را ببینید. خیلی خطرناک و کریتیکال است. اسکرین‌شات پیوست است.»
| معیار | گزارش ضعیف | گزارش قوی |
|---|---|---|
| اندپوینت | «بخش فاکتورها» | متد و مسیر کامل |
| پیش‌نیاز | ذکر نشده | دو حساب معمولی، بدون تعامل قربانی |
| بازتولید | یک جمله‌ی توصیفی | گام‌های عددگذاریشده با مقادیر واقعی |
| شواهد | فقط تصویر | درخواست و پاسخ خام و سانسورشده |
| اثر | «خیلی خطرناک است» | دامنه‌ی تأثیر، خودکارسازی‌پذیری، نوع داده |
| شدت | «کریتیکال» | بردار کامل با ذکر نسخه |
| رفع | ذکر نشده | الگوی کد، رد پیش‌فرض و لاگ |
| نتیجهی محتمل | بسته‌شدن گزارش | تریاژ سریع و پاداش کامل |
گزارش ضعیف از نظر فنی غلط نیست؛ فقط غیرقابل‌اقدام است. تمرین ساختن این مهارت را در مسیر یادگیری باگ بانتی آورده‌ایم: برای هر آزمایشگاهی که حل می‌کنید یک گزارش کامل بنویسید، انگار مخاطبش یک تریاژر واقعی است.
Duplicate، Informative، اختلاف حرفه‌ای و زمان‌بندی افشا
هر وضعیت بسته‌شدن معنای متفاوتی دارد. Duplicate یعنی پیش‌تر ثبت شده بود؛ Informative یعنی مشاهده درست است اما اثر امنیتی قابل اتکایی ندارد (مثلاً افشای نسخه یا نبود یک هدر بدون مسیر بهرهبرداری)؛ Out of scope یعنی از ابتدا داخل محدوده نبوده؛ و Not applicable یعنی بازتولید نشد.
وقتی با تصمیم موافق نیستید
اختلاف‌نظر در تریاژ طبیعی است و روش حرفه‌ای برخورد با آن خودش سرمایه‌ی اعتباری می‌سازد:
- در همان رشتهی گزارش پاسخ دهید، نه در شبکه‌های اجتماعی.
- استدلال فنی جدید اضافه کنید، نه تکرار: سناریوی بهرهبرداری واقعی‌تر، زنجیره با یافتهی دیگر، یا نشان‌دادن اینکه پیش‌نیاز فرض‌شده لازم نیست.
- اگر بحث درباره‌ی شدت است، بردار خود را کنار بردار پیشنهادی آن‌ها بگذارید و دقیقاً بگویید کدام سنجه را متفاوت ارزیابی می‌کنید.
- اگر پلتفرم فرایند بازبینی دارد از همان مسیر استفاده کنید و لحن را حرفه‌ای نگه دارید؛ در برنامه‌های خصوصی، دعوت‌ها بر پایهی سابقه‌ی رفتاری هم صادر می‌شوند.
«اگر ۹۰ روز پاسخ ندادند، حق دارم گزارش را عمومی منتشر کنم.» هیچ مهلت خودکاری به شما حق افشا نمیدهد. مهلت افشا چیزی است که سیاست همان برنامه تعریف میکند، و انتشار پیش از مجوز میتواند نقض شرایط برنامه، از بین‌رفتن Safe Harbour و در مواردی مسئولیت حقوقی باشد — به‌ویژه اگر گزارش شامل دادهی واقعی باشد. مسیر درست: پیگیری از کانال رسمی، درخواست زمان‌بندی، و توافق کتبی برای انتشار پس از رفع.
و آخرین نکته: رایت‌آپ عمومیِ منتشرشده با مجوز، یکی از ارزشمندترین دارایی‌های حرفه‌ای شماست — نمونه‌ی کاری که در استخدام و در دعوت به برنامه‌های خصوصی به آن استناد میشود. برای انتخاب برنامه‌ای با سیاست افشای روشن، معیارهای ارزیابی پلتفرم‌ها و فهرست برنامه‌های باگ بانتی ایرانی را ببینید.
پرسش‌های متداول
نمونه گزارش باگ بانتی باید چه بخشهایی داشته باشد؟
عنوان بیانکنندهی اثر، خلاصهی کوتاه، دارایی و اندپوینت دقیق، پیشنیازها، مراحل بازتولید عددگذاریشده، شواهد سانسورشده، اثر کسبوکاری، شدت با بردار CVSS و ذکر نسخه، راهکار رفع، و ارجاع به CWE و دستهی OWASP. اگر یکی از اینها نباشد، تریاژ کند میشود.
چطور گزارش باگ بانتی بنویسم که سریع تأیید شود؟
معیار را «هزینهی زمانی تریاژر» بگذارید. مراحل را با مقادیر واقعی و نقش کاربر بنویسید، درخواست HTTP را بهصورت متن خام بگذارید نه تصویر، نتیجهی مورد انتظار را ذکر کنید، و اثر را به زبان کسبوکار توضیح دهید. گزارشی که بدون یک سؤال قابل بازتولید باشد، سریعترین مسیر تأیید را دارد.
در گزارش از CVSS نسخهی ۴ استفاده کنم یا ۳٫۱؟
هر دو قابل دفاع است؛ مهم این است که بنویسید کدام و بردار کامل را بیاورید. نسخهی ۴٫۰ استاندارد جاری است، اما دادهی واقعی آسیبپذیریها هنوز بیشتر با ۳٫۱ امتیازدهی شده و ابزار بعضی سازمانها هم بر پایهی ۳٫۱ کار میکند. اگر برنامه نسخهی مشخصی خواسته، از همان استفاده کنید.
برای اثبات آسیبپذیری چقدر داده میتوانم استخراج کنم؟
حداقل چیزی که وجود مشکل را ثابت میکند — معمولاً یک رکورد، ترجیحاً متعلق به حساب آزمون خودتان. استخراج انبوه داده در تقریباً همهی سیاستها ممنوع است، پوشش Safe Harbour را باطل میکند و میتواند برای سازمان به رخداد امنیتی گزارشپذیر تبدیل شود. دادهی شخصی را در شواهد ماسک کنید.
گزارشم Informative بسته شد، یعنی چه؟
یعنی مشاهدهی شما درست است اما برنامه اثر امنیتی قابل اتکایی برای آن نمیبیند — مثل افشای نسخه یا نبود یک هدر بدون مسیر بهرهبرداری. اگر مسیر بهرهبرداری واقعی یا زنجیرهای با یافتهی دیگر دارید، همان را بهعنوان استدلال جدید در همان رشتهی گزارش اضافه کنید؛ تکرار حرف قبلی نتیجهای ندارد.
کی میتوانم رایت آپ خودم را عمومی منتشر کنم؟
فقط پس از رفع آسیبپذیری و با مجوز صریح برنامه، و طبق سیاست افشای همان برنامه. هیچ مهلت زمانی خودکاری به شما حق انتشار نمیدهد. در متن منتشرشده هم دادهی واقعی، شناسههای داخلی و هر چیزی که راه بازسازی حمله را برای دیگران باز کند نباید بیاید.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهرهبرداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.