باگ‌هانتینگ چیست و از کجا شروع کنیم

واژهٔ «باگ‌هانتینگ» در فارسی تقریباً همیشه یک معنی مشخص دارد: شکار آسیب‌پذیری‌های امنیتی — نه دیباگ کردن کد خودتان. باگ‌هانتر کسی است که در سیستم‌های دیگران دنبال ضعف امنیتی می‌گردد، آن را مسئولانه گزارش می‌دهد و گاهی بابتش پاداش می‌گیرد.

این مقاله معرفی همان حوزه است: چطور کار می‌کند، از کجا شروع کنید، و مرزهای قانونی‌اش کجاست.

تفاوت باگ و آسیب‌پذیری

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

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

همین تمایز، ذهنیت متفاوتی می‌خواهد. توسعه‌دهنده می‌پرسد «آیا این کار می‌کند؟» و باگ‌هانتر می‌پرسد «چطور می‌شود این را شکست؟»

Bug Bounty چیست

برنامهٔ پاداش باگ، توافقی است که شرکت اعلام می‌کند: اگر آسیب‌پذیری پیدا کردید و طبق قواعد ما گزارش دادید، پاداش می‌دهیم و پیگرد قانونی نمی‌کنیم.

هر برنامه سه چیز را مشخص می‌کند:

• دامنهٔ مجاز. کدام دامنه‌ها و سرویس‌ها را می‌توانید تست کنید. خارج شدن از این محدوده، از تحقیق امنیتی به نفوذ غیرمجاز تبدیل می‌شود.
• روش‌های ممنوع. تقریباً همیشه شامل حملهٔ منع سرویس، مهندسی اجتماعی روی کارکنان، و هر کاری که به دادهٔ کاربران واقعی آسیب بزند.
• جدول پاداش. معمولاً بر اساس شدت.

هشدار قانونی — این بخش را جدی بگیرید

تست امنیتی روی سیستمی که اجازهٔ صریح ندارید، در بسیاری از کشورها از جمله ایران، جرم است. «قصد خیر داشتم» و «فقط می‌خواستم کمک کنم» دفاع قانونی نیستند.

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

برای تمرین، محیط‌هایی وجود دارند که عمداً آسیب‌پذیر ساخته شده‌اند و تمرین روی آن‌ها کاملاً قانونی است — برنامه‌های آموزشی مثل OWASP Juice Shop یا DVWA که روی سیستم خودتان نصب می‌شوند، و پلتفرم‌های آموزشی که محیط ایزوله در اختیارتان می‌گذارند.

آسیب‌پذیری‌هایی که باید بشناسید

XSS — تزریق اسکریپت

وقتی سایت ورودی کاربر را بدون پاک‌سازی در صفحه نمایش می‌دهد. مهاجم می‌تواند کدی تزریق کند که در مرورگر بازدیدکنندگان دیگر اجرا شود و مثلاً نشستشان را بدزدد. همچنان یکی از رایج‌ترین‌هاست.

SQL Injection

وقتی ورودی کاربر مستقیم در کوئری دیتابیس قرار می‌گیرد. با اینکه راه‌حلش دهه‌هاست شناخته شده — استفاده از کوئری پارامتری — هنوز پیدا می‌شود، معمولاً در کدهای قدیمی.

CSRF — جعل درخواست

سایت مخرب کاری می‌کند که مرورگر شما درخواستی به سایتی که در آن وارد شده‌اید بفرستد. چون کوکی‌ها خودکار ارسال می‌شوند، سرور فکر می‌کند خودتان بوده‌اید. چرا مرورگر جلوی ارسال این درخواست را نمی‌گیرد، در توضیح CORS آمده است: محدودیت روی خواندن پاسخ است، نه ارسال درخواست.

مشکلات کنترل دسترسی

کم‌هیجان‌ترین دسته و اغلب پرتکرارترین: کاربری که با تغییر یک شناسه در آدرس، به دادهٔ کاربر دیگری دسترسی پیدا می‌کند. پیدا کردنش نیازی به ابزار خاصی ندارد — فقط دقت.

افشای اطلاعات

کلید API در کد فرانت‌اند، فایل پیکربندی در دسترس عموم، پیام خطایی که ساختار دیتابیس را لو می‌دهد.

ابزارهای کار

ابزار جای دانش را نمی‌گیرد، ولی چند مورد پایه‌ای هستند که تقریباً هر باگ‌هانتری استفاده می‌کند:

• پروکسی رهگیر مثل Burp Suite یا OWASP ZAP. قلب کار: هر درخواست را می‌بینید، تغییر می‌دهید و دوباره می‌فرستید. نسخهٔ رایگان هر دو برای شروع کافی است.
• ابزار توسعهٔ خود مرورگر. دست‌کم گرفته می‌شود، ولی تب Network و Storage بخش بزرگی از یافته‌های ساده را نشان می‌دهند.
• ابزار شناسایی زیردامنه. بسیاری از آسیب‌پذیری‌ها در سرویس‌های فراموش‌شده‌اند، نه در سایت اصلی.
• یک دفترچه. غیرفنی‌ترین و یکی از مهم‌ترین‌ها: هر چیزی که امتحان کردید و نتیجه‌اش را بنویسید، وگرنه بعد از چند ساعت نمی‌دانید کجا را گشته‌اید.

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

انتظارات واقع‌بینانه

تصویری که در شبکه‌های اجتماعی از این حوزه ساخته می‌شود گمراه‌کننده است. واقعیت:

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

ماه‌های اول معمولاً بی‌نتیجه است. این طبیعی است و به این معنی نیست که استعدادش را ندارید. مهارت این کار با تکرار می‌آید.

پاداش‌ها بسیار متغیرند. از چند ده دلار برای موارد کم‌شدت تا مبالغ قابل توجه برای موارد بحرانی — ولی موارد بحرانی نادرند.

برای بیشتر افراد این یک درآمد جانبی است، نه شغل. ارزش واقعی‌اش برای اکثریت، مهارتی است که در کار اصلی‌شان به‌عنوان توسعه‌دهنده یا مهندس امنیت به کار می‌آید.

گزارش خوب چه شکلی است

کیفیت گزارش، بیشتر از خود یافته، تعیین می‌کند که جدی گرفته شوید و پاداش بگیرید:

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

و اینکه چه چیزی نباید بکنید: از دادهٔ کاربران واقعی استفاده نکنید، بیشتر از حد لازم برای اثبات جلو نروید، و پیش از رفع شدن مسئله عمومی‌اش نکنید. اصولش با گزارش باگ خوب یکی است؛ فقط تحلیل اثر به آن اضافه می‌شود.

افشای مسئولانه

اگر آسیب‌پذیری‌ای در سیستمی پیدا کردید که برنامهٔ پاداش ندارد، مسیر متعارف این است: از طریق راه ارتباطی رسمی (معمولاً security@ یا فرم تماس) گزارش دهید، مهلت معقولی — معمولاً ۹۰ روز — برای رفع بدهید، و در این مدت عمومی‌اش نکنید.

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

از کجا شروع کنیم

• پایه را یاد بگیرید. بدون درک HTTP، کوکی، نشست و مدل امنیتی مرورگر، ابزارها به دردتان نمی‌خورند.
• OWASP Top 10 را بخوانید. فهرست استاندارد رایج‌ترین دسته‌های آسیب‌پذیری وب.
• روی محیط تمرینی کار کنید تا الگوها را بشناسید.
• گزارش‌های عمومی را بخوانید. بسیاری از گزارش‌های پذیرفته‌شده بعد از رفع منتشر می‌شوند و بهترین منبع یادگیری‌اند.
• از یک برنامهٔ رسمی شروع کنید و دامنه‌اش را دقیق بخوانید.

و اگر آن طرف میز نشسته‌اید

اگر صاحب محصولید نه شکارچی، دو نتیجهٔ عملی از این مقاله بگیرید:

یک راه ارتباطی امنیتی داشته باشید. یک آدرس ایمیل و یک صفحهٔ کوتاه که بگوید چطور آسیب‌پذیری گزارش کنند. نبودش یعنی کسی که چیزی پیدا کرده، یا رهایش می‌کند یا عمومی‌اش می‌کند.

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

منابع و مطالعهٔ بیشتر

• OWASP Top 10 — فهرست استاندارد رایج‌ترین آسیب‌پذیری‌های وب
• Web Security Academy — PortSwigger — آموزش و محیط تمرین رایگان و قانونی
• OWASP ZAP — پروکسی رهگیر متن‌باز
• RFC 9116 — security.txt — استاندارد اعلام راه ارتباطی امنیتی یک سایت