برنامه‌ها و پلتفرم‌های باگ بانتی ایرانی

یک برنامه‌ی باگ‌بانتی دقیقاً چطور کار می‌کند؟

از بیرون ساده به‌نظر می‌رسد: باگ پیدا کن، گزارش بده، پاداش بگیر. در عمل یک چرخه‌ی چند مرحله‌ای است که دانستنش هم برای شکارچی و هم برای صاحب برنامه تعیین‌کننده است.

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

نکته‌ای که تازه‌واردها دیر می‌فهمند: پاداش به «پیدا کردن» تعلق نمی‌گیرد، به «اثبات کردن» تعلق می‌گیرد. گزارشی که اثر را نشان ندهد — چه اتفاقی برای داده یا کاربر می‌افتد — حتی اگر فنی درست باشد، معمولاً با شدت پایین بسته می‌شود. نمونه‌های عملی این تفاوت در رایت‌آپ‌های باگ‌بانتی آمده است.

VDP، باگ‌بانتی و تست نفوذ سه چیز متفاوت‌اند

این سه مدام با هم اشتباه گرفته می‌شوند، در حالی که هر کدام مسئله‌ی متفاوتی را حل می‌کنند و ترتیب پیاده‌سازی‌شان اهمیت دارد:

• VDP (سیاست افشای آسیب‌پذیری). ساده‌ترین و ارزان‌ترین لایه: یک مسیر رسمی برای اینکه هر کسی بتواند آسیب‌پذیری‌ای را که تصادفی دیده گزارش کند، به‌همراه تعهد سازمان به برخورد غیرخصمانه با گزارش‌دهنده‌ی حسن‌نیت. پاداشی در کار نیست. هر سازمانی که سامانه‌ی عمومی دارد باید این را داشته باشد — نمونه‌ی خودمان در صفحه‌ی افشای مسئولانه است.
• باگ‌بانتی. لایه‌ی پیوسته و مبتنی بر نتیجه. تنوع دیدگاه ده‌ها شکارچی را می‌آورد و هزینه‌اش به یافته گره خورده است، اما پوشش را تضمین نمی‌کند: هیچ‌کس تعهد نمی‌دهد همه‌ی مسیرهای برنامه آزموده شود، و ممکن است هفته‌ها هیچ گزارش معتبری نیاید. هزینه هم پیش‌بینی‌ناپذیر است.
• تست نفوذ. لایه‌ی دوره‌ای و مبتنی بر پوشش. دامنه مکتوب است، متدولوژی مشخص است، خروجی گزارش فنی و مدیریتی به‌همراه تست مجدد است و هزینه از پیش معلوم. در مقابل، عکسی از یک لحظه است و میان دو ارزیابی، تغییرات کد بدون پوشش می‌مانند.

ترتیب درست معمولاً همین است: اول VDP، بعد تست نفوذ، و باگ‌بانتی در آخر. سازمانی که هنوز ارزیابی مستقلی انجام نداده و برنامه‌ی باگ‌بانتی باز می‌کند، در هفته‌ی اول با انبوهی از یافته‌های پایه‌ای روبه‌رو می‌شود که هم پرهزینه‌اند و هم می‌شد با یک ارزیابی معمولی و ارزان‌تر پیدایشان کرد. تفاوت‌ها را با جزئیات بیشتر در باگ‌بانتی چیست؟ نوشته‌ایم.

از دید شکارچی

اگر تازه شروع کرده‌اید، چهار چیز بیشترین تأثیر را روی نتیجه‌ی شما دارد:

• اسکوپ را کامل بخوانید، دو بار. آزمون روی دارایی خارج از دامنه نه‌تنها پاداش ندارد، بلکه شما را از پوشش حقوقی برنامه بیرون می‌گذارد. مرز مجاز، همان چیزی است که در متن برنامه نوشته شده — نه چیزی که «منطقی به‌نظر می‌رسد».
• تکراری بودن را بپذیرید. در برنامه‌های شناخته‌شده، آسیب‌پذیری‌های سطحی معمولاً قبلاً گزارش شده‌اند. مسیر منطقی، رفتن به سراغ منطق کسب‌وکار، مسیرهای کم‌رفت‌وآمد و ترکیب چند ضعف کوچک است — همان جایی که ابزار خودکار نمی‌رسد.
• گزارش را جدی بگیرید. عنوان دقیق، محیط و پیش‌شرط‌ها، مراحل بازتولید گام‌به‌گام، اثبات مفهوم در کمترین شکل ممکن، و توضیح روشن اثر. ساختار مرجع را در گزارش تست نفوذ ببینید؛ همان اصول در گزارش باگ‌بانتی هم جواب می‌دهد.
• حداقل اثر را وارد کنید. برای اثبات دسترسی به داده، یک نمونه‌ی پوشانده‌شده کافی است. استخراج انبوه داده‌ی واقعی، حتی با نیت اثبات، مرز حسن‌نیت را رد می‌کند و می‌تواند گزارش شما را به یک پرونده تبدیل کند.

مسیر یادگیری از صفر تا اولین گزارش پذیرفته‌شده را در یادگیری باگ‌بانتی و مقایسه‌ی پلتفرم‌ها را در پلتفرم‌های باگ‌بانتی آورده‌ایم.

از دید صاحب برنامه

باز کردن یک برنامه، تصمیم فنی نیست؛ تصمیم عملیاتی است. پیش از انتشار، این پنج پیش‌شرط را داشته باشید:

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

و یک انتظار واقع‌بینانه: باگ‌بانتی جایگزین فرایند امن توسعه نیست. اگر یافته‌ها الگوی تکرارشونده‌ای نشان می‌دهند، مسئله در کد نیست، در عادت تیم است — و آنجا آموزش توسعه‌ی امن نتیجه‌ی به‌مراتب پایدارتری می‌دهد.