نکاتی از گزارش باگ که کسی بهت نگفته!

سلام من بهروزم و می خوام نکاتی از گزارش باگ بگم که کسی بهت نگفته!

شما یک باگ پیدا کردید. احساس افتخار می‌کنید. یک گزارش ۱۰ خطی می‌نویسید، اسکرین‌شات می‌چسبانید، دکمه ارسال را می‌زنید و بعد… هیچ.

یا بدتر از آن: «اطلاعاتی، بدون پاداش.» اه.

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

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

خلاصه سریع (TL;DR): تریاژرها سه چیز می‌خواهند

• مراحل قابل بازتولید — بتوانم باگ شما را در ۵ دقیقه تکرار کنم.

• تأثیر روشن — چرا این موضوع برای کسب‌وکار مهم است، نه فقط برای شما.

• نویز کم — بدون اضافات، بدون کپی کردن لاگ‌های پر از رمز و داده.

اگر گزارش شما این سه مورد را داشته باشد، تریاژر آن را تا انتها می‌خواند. اگر نداشته باشد، سریع بسته می‌شود یا بدتر، نادیده گرفته می‌شود.

تریاژر کیست و با چه چیزهایی دست‌وپنجه نرم می‌کند؟

تریاژرها بین پژوهشگران و تیم‌های مهندسی قرار دارند. کارشان سخت و مدیریتی است:

• بررسی سریع گزارش (واقعی است یا نه؟)

• بازتولید باگ یا علامت‌گذاری آن به عنوان تکراری

• طبقه‌بندی شدت و تأثیر تجاری

• ارسال آن برای تیم مهندسی مناسب

• اطلاع‌رسانی وضعیت به پژوهشگر

• جلوگیری از ریسک حقوقی و عملیاتی

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

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

مدل ذهنی تریاژر: گزارش شما چطور سریع قضاوت می‌شود

تریاژرها گزارش را تقریباً به این ترتیب بررسی می‌کنند:

1. عنوان و خلاصه کوتاه — آیا فریاد می‌زند «قابل اقدام» یا «مبهم»؟

2. مراحل بازتولید (Repro Steps) — بخش حیاتی و تعیین‌کننده.

3. شواهد (PoC) — اسکرین‌شات، درخواست‌های curl، یا payloadهای حداقلی.

4. توضیح تأثیر — به زبان کسب‌وکار (افشای داده؟ جعل هویت؟ کنترل از راه دور؟)

5. دامنه و پیشنهاد رفع — نکات سریع برای هدایت گزارش به تیم درست.

6. موارد اضافی — لاگ‌ها، جزئیات محیط (در صورت نیاز).

اگر هرکدام از مراحل ۱ تا ۳ به سرعت شکست بخورند، تریاژر آن را کنار می‌گذارد یا با اولویت پایین علامت‌گذاری می‌کند.

دلایل رایج بسته شدن گزارش‌ها (و چطور از آن‌ها جلوگیری کنیم)

1. «Cannot reproduce» (قابل بازتولید نیست)

دلیل: مراحل مبهم‌اند، به حالت خاصی وابسته‌اند، یا هدر/کوکی جا افتاده.
راه‌حل: URL دقیق، متدها (GET/POST)، قطعات کامل درخواست/پاسخ (با سانسور داده حساس) را بنویسید. وضعیت دقیق کاربر را بگویید (مثلاً وارد شده به عنوان X، ادمین Y).

2. «Out of scope» (خارج از محدوده)

دلیل: روی دامنه‌ای تست کرده‌اید که در محدوده برنامه نیست.
راه‌حل: قبل از تست محدوده را بررسی کنید و در گزارش صراحتاً بنویسید که دامنه هدف در محدوده است (در صورت لزوم خط محدوده را کپی کنید).

3. «Duplicate» (تکراری)

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

4. «User error / Not a bug» (خطای کاربر / باگ نیست)

دلیل: سیستم همان‌طور که طراحی شده عمل می‌کند یا شرایط غیرواقعی لازم دارد.
راه‌حل: توضیح دهید چرا این رفتار مضر است (مثلاً: «این باعث تسخیر حساب بدون 2FA می‌شود چون X )

5. «Low impact / Informational» (کم‌اهمیت / صرفاً اطلاعاتی)

دلیل: کنترل ضعیف است اما دسترسی یا امتیازی نمی‌دهد.
راه‌حل: تأثیر را از دید کسب‌وکار بیان کنید: «مهاجم می‌تواند ایمیل‌های مشتریان را فهرست کند و فیشینگ هدفمند انجام دهد.» و برای آن زنجیره‌ی سوءاستفاده PoC بدهید.

6. «Unsafe to test / destructive» (ناایمن برای تست / مخرب)

دلیل: در محیط تولید تست مخرب انجام داده‌اید.
راه‌حل: هیچ‌گاه تست‌های مخرب را در محیط زنده انجام ندهید. اگر باگ نیازمند آن است، از تریاژ اجازه بگیرید و PoC ایمن و غیرمخرب ارائه دهید.

چگونه گزارشی بنویسید که تریاژر دوست دارد: دستورالعمل دقیق

از عنوان واضح و عملی شروع کنید

بد:

“Possible issue in search”

خوب:

“Authenticated SQLi in /api/search allows full DB dump via q parameter”

با خلاصه‌ای ۱–۲ جمله‌ای ادامه دهید

مثال:

Summary: تزریق SQL احراز هویت‌شده در /api/search (پارامتر q) اجازه استخراج ردیف‌های دلخواه پایگاه‌داده را می‌دهد. قابل بازتولید به عنوان کاربر behrouz. شامل داده‌های PII کاربران (ایمیل، تلفن) و می‌تواند به تسخیر حساب منجر شود.

مراحل بازتولید: حداقلی ولی دقیق (طلایی)

مراحلی به صورتی باشد که تریاژر بتواند کپی/پیست کند:

• با Password1 وارد alice@example.com شوید.

curl -i 'https://api.example.com/api/search?q=1' -H 'Authorization: Bearer <token>'

• مقدار q=1 را با عبارت زیر جایگزین کنید.

q=1' UNION SELECT username, password FROM users-- -

• مشاهده کنید که پاسخ JSON شامل فیلدهای username و password است.

درخواست/پاسخ کامل (با حذف اطلاعات حساس)، فرمان‌های curl یا raw از Burp Repeater را اضافه کنید.

شواهد: PoC حداقلی

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

تأثیر: به زبان کسب‌وکار

تأثیر فنی را به تأثیر تجاری ترجمه کنید:

• «افشای اطلاعات شخصی کاربران (ایمیل، تلفن) → خطر قانونی و نقض حریم خصوصی.»

• «امکان تصاحب حساب → از بین رفتن اعتماد کاربر و احتمال تقلب.»

• «اجرای کد از راه دور روی سرور → نقض کامل محرمانگی و تمامیت.»

پیشنهاد شدت بدهید ولی با لحن راهنمایی: «احتمالاً بالا، چون استخراج داده ممکن است.»

محیط و تأیید دامنه

جزئیات هدف را بنویسید:

• هدف: https://api.example.com (در محدوده طبق صفحه برنامه)

• حساب تست: alice@example.com (ایجادشده در 2025-10-01)

• User-Agent، IP و زمان (اختیاری، مفید در صورت درخواست لاگ‌ها)

پیشنهاد رفع

مراحل قابل اجرا برای مهندسان:

• از کوئری‌های پارامتری و Prepared Statement استفاده شود.

• ورودی‌ها در سمت سرور اعتبارسنجی شوند.

• اعتبارنامه‌های افشا‌شده چرخانده شوند و اصل کمترین دسترسی اعمال شود.

 

اختیاری: README و فایل‌های ضمیمه

اگر اسکریپت PoC دارید، آن را به صورت فایل کوچک با README بفرستید، نحوه اجرای امن را توضیح دهید، و از افشای رمز جلوگیری کنید.

قالب آماده برای گزارش (همیشه از این استفاده کنید)

Title: [نوع آسیب‌پذیری] خلاصه کوتاه از تأثیر و اندپوینت

Summary:
۱–۲ جمله: چه چیزی، کجا، و چرا مهم است.

Steps to reproduce:

1. (مرحله دقیق ۱)

2. (مرحله دقیق ۲ + curl یا raw در صورت نیاز)

3. (نتیجه مورد انتظار در مقابل نتیجه واقعی)

PoC / Evidence:

• قطعه پاسخ یا اسکرین‌شات (با سانسور)

• زمان: 2025-10-04T13:22Z

• حساب تست: alice@example.com

نحوه تعیین شدت (و چرا نباید بحث کنید)

تریاژرها اغلب شدت را با مدل‌های داخلی (CVSS + بستر تجاری) تعیین می‌کنند. کار شما اطلاع‌رسانی است، نه دیکته کردن. شدت را این‌طور بیان کنید:

• احتمال: چقدر آسان قابل سوءاستفاده است؟ (پایین/متوسط/زیاد)

• تأثیر: چه چیزی از بین می‌رود؟ (اطلاعات / دسترسی / اجرای کد)

مثال:

احتمال: متوسط (نیازمند کاربر احراز هویت‌شده)
تأثیر: زیاد (افشای داده‌های شخصی)
پیشنهاد: High

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

 

ارتباط: لحن، زمان‌بندی و پیگیری‌ها

• مؤدب و خلاصه باشید. لحن شما نشانه‌ی همکاری آینده است.

• اسپم نکنید. اگر گفتند زمان می‌خواهد، صبر کنید.

• اگر مجبورید پیگیری کنید، مدرک جدید بیاورید. تکرار درخواست بدون داده جدید، تریاژ را آزار می‌دهد.

• اگر باگ رفع شد، تأیید کنید و با تشکر ببندید.
  بگویید: «رفع را در staging در 2025-10-05 تأیید کردم. ممنون، تیکت را می‌بندم.»

نکته حرفه‌ای: یادداشت کوتاهی در پروفایل خود برای تریاژرها بنویسید تا حرفه‌ای‌بودن شما را ببینند، شهرت خوب سرعت بررسی را بالا می‌برد.

نحوه برخورد با تکراری‌ها و رد شدن‌ها

• اگر تکراری علامت خورد: گزارش مرجع را بررسی کنید. اگر تأثیر متفاوتی دارد، تفاوت‌ها را روشن و ارزش افزوده را توضیح دهید.

• اگر به‌عنوان informational بسته شد: مؤدبانه بپرسید چه چیزی باعث می‌شد قابل بازتولید یا دارای پاداش باشد؛ یاد بگیرید و اصلاح کنید.

• اگر خارج از محدوده رد شد: بپذیرید و ادامه دهید، اما اگر محدوده مبهم است، با پشتیبانی برنامه تماس بگیرید.

به یاد داشته باشید: تیم‌های تریاژ گاهی صدها گزارش دریافت می‌کنند. صبر برنده است.

 

نکات پیشرفته که با شهرت، دستتان را بازتر می‌کند

• کد رفع (غیرمخرب) ضمیمه کنید — تریاژرها عاشق این هستند.

• تست‌هایی ارائه دهید که تیم‌های CI بتوانند اضافه کنند (تست واحد برای اطمینان از رفع باگ).

• PoC مرحله‌ای ارائه دهید: یکی غیرمخرب، و در صورت درخواست، نسخه‌ی عمیق‌تر با هماهنگی تریاژ.

• ثبات: گزارش‌های باکیفیت در طول زمان شهرت می‌سازند؛ دعوت‌نامه‌های خصوصی براساس همین موارد ارسال می‌شوند.

 

چک‌لیست تریاژر: روندی که دنبال می‌کنند (تا شما هم منطبق شوید)

اگر می‌خواهید گزارشی بنویسید که دقیقاً با این جریان منطبق باشد، آن را طوری طراحی کنید که از این مراحل عبور کند:

1. عنوان و خلاصه کوتاه → وضوح فوری

2. مراحل بازتولید → قابل کپی/پیست

3. PoC حداقلی → شواهد واضح

4. تأثیر → به زبان تجاری

5. تأیید در محدوده و جزئیات محیط

6. پیشنهاد رفع عملی

7. ضمیمه اسکریپت‌ها/اسکرین‌شات‌ها (سانسور شده)

8. تماس و پیشنهاد کمک برای بازتولید

بعد از هر ارسال، این چک‌لیست را مثل پرچم بالا بگیرید.

 

یک داستان واقعی کوتاه (درسی که سخت آموختم)

روزی گزارشی از SQLi ارسال کردم که جدول کامل کاربران را در محیط توسعه برمی‌گرداند. گزارشی مختصر با dumpهای خام فرستادم. تریاژر آن را به‌عنوان «اطلاعاتی» بست و سریع ارجاع نداد. چرا؟ چون تأثیر تجاری را توضیح نداده بودم و گزارش را با داده‌ی خام پر کرده بودم (نویز زیاد).

درس: گزارش را تمیز، توضیح‌دار و با PoC مختصر بنویس.
وقتی دوباره همان باگ را با توضیح کوتاه و تأثیر واضح («افشای PII و هش رمزها → خطر تصاحب حساب») ارسال کردم، در چند روز بررسی و رفع شد. محتوا مهم بود، اما نحوه ارائه، تفاوت را ایجاد کرد.

فکر پایانی: نوشتن، بخشی از هک کردن است

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

نکته حرفه‌ای:

«گزارش را طوری بنویس که انگار فقط ۹۰ ثانیه وقت دارد بخواند و باید بدون تماس با تو بتواند باگ را رفع کند.»
اگر بتواند، شما برنده‌اید.

اگر به دنیای باگ بانتی علاقه دارید پیشنهاد میکنم دوره خصوصی کلوپ امنیت ۱ و پیشرفته رو از دست ندی.

“نکاتی از گزارش باگ که کسی بهت نگفته!”