درآمد دلاری از باگ بانتی در ایران ۲۰۲۶؛ راهنمای کسب درآمد دلاری Bug Bounty
باگ بانتی چیست و چرا شرکت‌ها برای پیدا کردن باگ پول می‌دهند؟
باگ بانتی (Bug Bounty) برنامه‌ای است که شرکت‌ها، وب‌سایت‌ها و پلتفرم‌های آنلاین برای پیدا کردن آسیب‌پذیری‌های امنیتی محصولات خود برگزار می‌کنند. در این برنامه‌ها، متخصصان امنیت و هکرهای کلاه‌سفید با رعایت محدوده و قوانین مشخص‌شده، سرویس‌های شرکت را بررسی می‌کنند و اگر یک آسیب‌پذیری واقعی پیدا کنند، آن را به‌صورت محرمانه گزارش می‌دهند. در صورت تأیید گزارش، شرکت می‌تواند متناسب با اهمیت و شدت باگ، پاداش مالی یا Bounty پرداخت کند.
دلیل شکل‌گیری چنین برنامه‌هایی ساده است؛ حتی تیم‌های امنیتی قدرتمند نیز نمی‌توانند تمام سناریوهای حمله را پیش‌بینی کنند. یک سرویس بزرگ ممکن است هزاران صفحه، API، اپلیکیشن موبایل، سیستم ورود، پنل کاربری و قابلیت مختلف داشته باشد. حضور تعداد زیادی Security Researcher مستقل باعث می‌شود محصول از زاویه‌هایی بررسی شود که شاید در تست‌های داخلی شرکت دیده نشده باشند.
برای مثال ممکن است یک باگ باعث شود کاربر به اطلاعات حساب شخص دیگری دسترسی پیدا کند، محدودیت‌های دسترسی را دور بزند یا کنترل بخشی از یک حساب را به دست آورد. چنین آسیب‌پذیری‌هایی در صورت سوءاستفاده می‌توانند خسارت بسیار بیشتری از مبلغی که شرکت به Bug Hunter پرداخت می‌کند ایجاد کنند. به همین دلیل پرداخت چندصد یا حتی چند هزار دلار برای کشف مسئولانه یک Vulnerability می‌تواند برای شرکت کاملاً منطقی باشد.
خدمات احرازچی
- احراز هویت در کلیه سایت های باگ بانتی
- افتتاح حساب در برترین سایت های خارجی
- وریفای تضمینی کاربران ایرانی
- احراز هویت در کمتر از 72 ساعت
مقدار درآمد باگ بانتی نیز ثابت نیست. ارزش یک گزارش به عواملی مانند شدت آسیب‌پذیری، میزان Impact، سرویس آسیب‌دیده، امکان سوءاستفاده، کیفیت گزارش و قوانین همان Bug Bounty Program بستگی دارد. یک آسیب‌پذیری کم‌خطر ممکن است پاداش محدودی داشته باشد، در حالی که یک باگ Critical با تأثیر جدی می‌تواند پاداش بسیار بالاتری دریافت کند.
نکته مهم این است که Bug Bounty مجوز هک آزادانه اینترنت نیست. هر برنامه دارای Scope و قوانین مشخصی است و Researcher فقط باید دارایی‌هایی را آزمایش کند که شرکت برای تست مجاز اعلام کرده است. آزمایش خارج از Scope یا انجام اقداماتی که قوانین برنامه اجازه نداده‌اند، دیگر بخشی از فعالیت استاندارد Bug Bounty محسوب نمی‌شود.
به فردی که به‌صورت تخصصی در این حوزه فعالیت می‌کند معمولاً Bug Bounty Hunter، Bug Hunter یا Security Researcher گفته می‌شود. پلتفرم‌هایی مانند HackerOne، Bugcrowd، Intigriti و YesWeHack نیز ارتباط میان شرکت‌ها و پژوهشگران امنیتی را ساده‌تر کرده‌اند و تعداد زیادی برنامه امنیتی در آنها برگزار می‌شود.
همین مدل باعث شده Bug Bounty برای افراد علاقه‌مند به امنیت سایبری به یک مسیر واقعی برای کسب تجربه و درآمد تبدیل شود؛ مسیری که در آن مهارت پیدا کردن آسیب‌پذیری، تحلیل اثر آن و نوشتن یک گزارش حرفه‌ای مستقیماً روی شانس دریافت پاداش تأثیر می‌گذارد. برای کاربران ایرانی نیز سؤال مهم بعدی دقیقاً از همین‌جا شروع می‌شود: آیا با وجود محدودیت‌های بین‌المللی واقعاً می‌توان از باگ بانتی در ایران درآمد دلاری داشت؟
آیا واقعاً می‌توان از باگ بانتی در ایران درآمد دلاری داشت؟
بله، کسب درآمد از باگ بانتی برای یک متخصص امنیت ایرانی از نظر مهارتی امکان‌پذیر است؛ اما فعالیت از داخل ایران با فعالیت یک Bug Hunter در کشورهای بدون محدودیت مالی و تحریمی تفاوت مهمی دارد. چالش اصلی معمولاً پیدا کردن باگ نیست، بلکه انتخاب برنامه‌ای است که کاربر از نظر کشور محل اقامت، احراز هویت و دریافت پاداش شرایط شرکت در آن را داشته باشد.
در Bug Bounty، محل زندگی شما تأثیری روی توانایی فنی پیدا کردن آسیب‌پذیری ندارد. یک متخصص ایرانی نیز می‌تواند Web Security، API Security، Recon، Authentication، Access Control و سایر مهارت‌های مورد نیاز را یاد بگیرد و روی برنامه‌هایی که اجازه فعالیت دارد کار کند. حتی برای شروع، بسیاری از آزمایشگاه‌های آموزشی و منابع تمرینی بدون نیاز به ورود مستقیم به برنامه‌های دارای پاداش قابل استفاده هستند.
موضوع زمانی پیچیده‌تر می‌شود که یک آسیب‌پذیری واقعی پیدا شده و نوبت به دریافت Bounty می‌رسد. پلتفرم‌ها و شرکت‌ها ممکن است قبل از پرداخت، اطلاعات هویتی، Country of Residence، اطلاعات مالیاتی یا روش دریافت وجه را بررسی کنند. علاوه بر قوانین خود پلتفرم، هر Bug Bounty Program نیز می‌تواند شرایط جغرافیایی مستقلی داشته باشد. به همین دلیل داشتن حساب در یک پلتفرم به این معنی نیست که کاربر ایرانی اجازه شرکت در تمام برنامه‌های موجود در آن را دارد.
برای یک Bug Hunter ایرانی باید سه مرحله را از یکدیگر جدا کرد: امکان شرکت در برنامه، امکان تکمیل KYC و امکان دریافت Reward. ممکن است Researcher بتواند در یک پلتفرم حساب ایجاد کند، اما یک برنامه خاص کاربران بعضی کشورها را از دریافت پاداش مستثنا کرده باشد. همچنین ممکن است خود برنامه مشکلی نداشته باشد، اما روش پرداخت ارائه‌شده برای محل اقامت Researcher قابل استفاده نباشد.
⚡ احراز هویت پلتفرم‌های Bug Bounty
احرازچی خدمات احراز هویت و KYC پلتفرم‌های معتبر باگ بانتی را ارائه می‌دهد. برای بررسی شرایط پلتفرم و دریافت مشاوره قبل از اقدام، با کارشناسان ما در ارتباط باشید.
این موضوع یکی از دلایلی است که قبل از صرف چندین روز برای بررسی یک Target باید قوانین همان برنامه با دقت مطالعه شود. بخش‌های Eligibility، Scope، Disclosure Policy، Reward Table و Payment Conditions اهمیت زیادی دارند. اگر برنامه برای Country شما پاداش پرداخت نمی‌کند، پیدا کردن یک آسیب‌پذیری Critical نیز الزاماً به معنی دریافت پول نخواهد بود.
استفاده از کشور غیرواقعی، هویت شخص دیگر یا اطلاعات نادرست نیز راه مطمئنی برای حل این مشکل نیست. بسیاری از پلتفرم‌ها هنگام پرداخت یا احراز هویت می‌توانند اطلاعات Account و Payment را بررسی کنند و اختلاف اطلاعات ممکن است باعث ایجاد مشکل در KYC یا Reward شود. برای فعالیت بلندمدت، بهتر است از ابتدا روی برنامه‌هایی تمرکز شود که شرایط آنها با وضعیت واقعی Researcher سازگار است.
از طرف دیگر، درآمد باگ بانتی حقوق ماهانه نیست. ممکن است یک Hunter مدتی هیچ گزارش قابل پرداختی نداشته باشد و سپس یک Vulnerability باارزش پیدا کند. ممکن است گزارش دیگری Duplicate شود یا شدت آن کمتر از چیزی باشد که Researcher تصور می‌کرد. به همین دلیل مخصوصاً در شروع کار نباید Bug Bounty را یک درآمد ثابت و تضمین‌شده در نظر گرفت.
برای کاربران ایرانی مسیر منطقی این است که ابتدا مهارت فنی را تقویت کنند، سپس پلتفرم‌ها و برنامه‌های قابل استفاده را شناسایی کنند و قبل از شروع Hunting، وضعیت Country Eligibility، KYC و Payout را بررسی کنند. با این روش زمان روی Targetهایی صرف می‌شود که علاوه بر امکان پیدا کردن باگ، مسیر مشخصی برای دریافت پاداش نیز دارند.
درآمد باگ بانتی چقدر است؟ از اولین ۵۰ دلار تا پاداش‌های چند هزار دلاری
یکی از مهم‌ترین سؤالات افرادی که قصد ورود به این حوزه را دارند این است که درآمد باگ بانتی چقدر است؟ برخلاف یک شغل ثابت در حوزه امنیت سایبری، Bug Bounty حقوق ماهانه مشخصی ندارد و میزان درآمد یک Bug Bounty Hunter به تعداد گزارش‌های تأییدشده، شدت آسیب‌پذیری، تأثیر واقعی باگ، نوع برنامه و مقدار پاداش تعیین‌شده توسط شرکت بستگی دارد. در برخی برنامه‌ها یک آسیب‌پذیری ساده و کم‌خطر ممکن است تنها چند ده یا چند صد دلار پاداش داشته باشد، در حالی که باگ‌های High و Critical می‌توانند چند هزار دلار یا حتی مبالغ بسیار بالاتری ارزش داشته باشند. البته پاداش‌های بزرگ را نباید درآمد عادی یک فرد تازه‌کار در نظر گرفت؛ رسیدن به چنین مبالغی معمولاً به دانش فنی، تجربه، انتخاب درست Target و توانایی پیدا کردن آسیب‌پذیری‌های با Impact بالا نیاز دارد.
شرکت‌ها برای تعیین پاداش باگ بانتی فقط به نام آسیب‌پذیری نگاه نمی‌کنند. ممکن است دو محقق امنیتی یک نوع Vulnerability مشابه پیدا کنند اما مبالغ متفاوتی دریافت کنند، زیرا میزان دسترسی ایجادشده، حساسیت اطلاعات، تعداد کاربران تحت تأثیر، امکان سوءاستفاده واقعی، شدت آسیب‌پذیری و کیفیت گزارش در تعیین Reward نقش دارند. گزارش حرفه‌ای که مراحل بازتولید، شرایط ایجاد مشکل و Impact را به‌وضوح نشان دهد، ارزش بسیار بیشتری برای تیم امنیتی شرکت دارد.
از طرف دیگر، تمام گزارش‌ها منجر به درآمد نمی‌شوند. ممکن است باگی که پیدا کرده‌اید قبلاً توسط Researcher دیگری گزارش شده باشد و به‌عنوان Duplicate بسته شود، شدت کافی برای دریافت پاداش نداشته باشد، Informative تشخیص داده شود یا اصلاً خارج از Scope برنامه باشد. به همین دلیل ممکن است یک Hunter مدتی فعالیت کند و درآمدی نداشته باشد و سپس با پیدا کردن یک آسیب‌پذیری مهم، پاداش قابل‌توجهی دریافت کند.
افراد حرفه‌ای معمولاً فقط به دنبال تعداد بیشتر باگ نیستند؛ آنها یاد می‌گیرند برنامه‌های مناسب را انتخاب کنند، Scope را دقیق بررسی کنند، بخش‌های کمتر بررسی‌شده یک سرویس را پیدا کنند و زمان خود را روی آسیب‌پذیری‌هایی بگذارند که Impact واقعی دارند. همین تجربه می‌تواند تفاوت بزرگی میان فردی که گهگاه چند صد دلار پاداش دریافت می‌کند و Researcher حرفه‌ای که Bug Bounty را به یکی از منابع جدی درآمد خود تبدیل کرده است ایجاد کند.
برای فردی که تازه وارد این حوزه شده، هدف منطقی در ابتدا رسیدن به اولین گزارش معتبر و اولین Bounty است، نه انتظار درآمد چند هزار دلاری در مدت کوتاه. با افزایش تجربه، شناخت بهتر برنامه‌ها و تقویت مهارت در پیدا کردن آسیب‌پذیری‌های باارزش، شانس دریافت پاداش‌های بزرگ‌تر نیز افزایش پیدا می‌کند. سؤال مهم بعدی این است که وقتی یک Bug Hunter از مرحله مبتدی عبور می‌کند.
درآمد یک Bug Bounty Hunter حرفه‌ای چقدر می‌تواند باشد؟
درآمد یک Bug Bounty Hunter حرفه‌ای می‌تواند با درآمد فردی که به‌تازگی وارد این حوزه شده تفاوت زیادی داشته باشد، اما برای آن نمی‌توان حقوق ماهانه ثابتی تعیین کرد. یک پژوهشگر امنیتی حرفه‌ای ممکن است در یک ماه چند آسیب‌پذیری باارزش گزارش کند و درآمد قابل‌توجهی داشته باشد، در حالی که در ماه دیگری تعداد گزارش‌های پذیرفته‌شده او کمتر باشد. به همین دلیل بهتر است درآمد باگ بانتی را بر اساس عملکرد و پاداش گزارش‌های معتبر بررسی کرد، نه مانند یک شغل با حقوق ثابت.
یکی از مهم‌ترین تفاوت‌های Hunterهای حرفه‌ای با افراد تازه‌کار، نحوه استفاده از زمان است. فرد باتجربه معمولاً ساعت‌ها بدون هدف یک وبسایت را بررسی نمی‌کند؛ ابتدا Scope، ساختار برنامه، Reward Table، دارایی‌های موجود و نوع آسیب‌پذیری‌های مورد پذیرش را مطالعه می‌کند و سپس روی قسمت‌هایی تمرکز می‌کند که احتمال پیدا کردن یک Vulnerability با Impact واقعی در آنها بیشتر است. همین موضوع می‌تواند باعث شود ارزش زمانی که برای Hunting صرف می‌کند بسیار بیشتر شود.
درآمد Bug Bounty Hunter
سابقه فعالیت نیز اهمیت زیادی دارد. Researcherهایی که گزارش‌های معتبر بیشتری ثبت کرده‌اند، به‌مرور در تحلیل منطق برنامه‌ها، APIها، سیستم‌های احراز هویت و کنترل دسترسی سریع‌تر می‌شوند و بهتر تشخیص می‌دهند کدام یافته ارزش ادامه بررسی دارد. بعضی از پژوهشگران حرفه‌ای همچنین ممکن است به Private Bug Bounty Programs دعوت شوند؛ برنامه‌هایی که تعداد شرکت‌کنندگان محدودتری دارند و در برخی موارد رقابت برای گزارش یک آسیب‌پذیری نسبت به برنامه‌های کاملاً عمومی کمتر است.
البته دیدن درآمدهای بسیار بالا یا پاداش‌های چند ده هزار دلاری نباید این تصور را ایجاد کند که هر فردی پس از یادگیری چند آسیب‌پذیری می‌تواند سریعاً به چنین درآمدی برسد. پشت بسیاری از درآمدهای قابل‌توجه، سال‌ها تجربه در Web Security، API Security، Recon، منطق تجاری، تحلیل Access Control و نوشتن گزارش‌های حرفه‌ای وجود دارد. حتی یک Hunter باتجربه نیز ممکن است با Duplicate شدن گزارش یا رد شدن یک یافته مواجه شود.
برای کاربران ایرانی یک عامل دیگر نیز به این محاسبه اضافه می‌شود. درآمد بالقوه زمانی ارزش واقعی پیدا می‌کند که Researcher از ابتدا مطمئن شود برنامه موردنظر از نظر Country Eligibility، احراز هویت و Payout با شرایط او سازگار است. صرف پیدا کردن یک باگ ارزشمند تضمین نمی‌کند که هر پلتفرم یا شرکتی امکان پرداخت پاداش به هر کشور را داشته باشد.
به همین دلیل مسیر حرفه‌ای شدن در Bug Bounty بیشتر از اینکه به «تعداد ساعت کار» وابسته باشد، به کیفیت مهارت، انتخاب هوشمندانه برنامه و توانایی کشف آسیب‌پذیری‌های واقعی وابسته است. یکی از مهم‌ترین تصمیم‌ها برای رسیدن به این مرحله نیز انتخاب پلتفرم مناسب است؛ زیرا HackerOne، Bugcrowd، Intigriti، YesWeHack و پلتفرم‌های تخصصی دیگر از نظر تعداد برنامه‌ها، نوع اهداف و شرایط دریافت پاداش یکسان نیستند.
بهترین سایت‌های باگ بانتی برای کسب درآمد دلاری
برای کسب درآمد از Bug Bounty، انتخاب پلتفرم مناسب تقریباً به اندازه مهارت پیدا کردن آسیب‌پذیری اهمیت دارد. HackerOne، Bugcrowd، Intigriti، YesWeHack، HackenProof و Immunefi از نام‌های شناخته‌شده این حوزه هستند، اما نوع برنامه‌ها، میزان رقابت، نحوه پرداخت پاداش و شرایط فعالیت در هرکدام متفاوت است. به همین دلیل نمی‌توان یک سایت را بدون توجه به سطح مهارت و نوع تخصص، بهترین گزینه برای همه Bug Hunterها دانست.
HackerOne یکی از شناخته‌شده‌ترین پلتفرم‌های Bug Bounty در جهان است و تعداد زیادی برنامه امنیتی عمومی و خصوصی را در خود جای داده است. حضور شرکت‌ها و سازمان‌های مختلف باعث شده این پلتفرم برای Researcherهایی که روی Web Security، API و سرویس‌های آنلاین فعالیت می‌کنند اهمیت زیادی داشته باشد. در مقابل، محبوبیت بالای HackerOne به معنی حضور تعداد زیادی Hunter حرفه‌ای نیز هست و در برنامه‌های عمومی رقابت می‌تواند بالا باشد.
Bugcrowd یکی دیگر از پلتفرم‌های مهم این صنعت است که علاوه بر Bug Bounty، برنامه‌های Vulnerability Disclosure و پروژه‌های امنیتی مختلفی ارائه می‌کند. Researcherها می‌توانند بر اساس Scope و شرایط هر برنامه، اهداف مجاز را بررسی کرده و در صورت پیدا کردن آسیب‌پذیری معتبر گزارش خود را ارسال کنند. سابقه و کیفیت گزارش‌های یک Researcher نیز می‌تواند در مسیر فعالیت حرفه‌ای او اهمیت پیدا کند.
Intigriti در میان جامعه امنیت سایبری اروپا شناخته‌شده است و مجموعه‌ای از برنامه‌های عمومی و خصوصی را ارائه می‌دهد. برای کاربران ایرانی، مطالعه قوانین هر برنامه در این پلتفرم اهمیت ویژه‌ای دارد؛ زیرا Country Eligibility و محدودیت‌های مربوط به پرداخت می‌تواند بین برنامه‌ها متفاوت باشد و صرف داشتن حساب کاربری به معنی امکان دریافت Reward از تمام برنامه‌ها نیست.
YesWeHack نیز یک پلتفرم بین‌المللی برای ارتباط میان سازمان‌ها و Security Researcherها است و برنامه‌های مختلفی در حوزه کشف و گزارش مسئولانه آسیب‌پذیری ارائه می‌کند. هنگام انتخاب Target در این پلتفرم نیز باید Scope، Out of Scope، Reward Table و شرایط دریافت پاداش قبل از شروع بررسی شود.
برای افرادی که بیشتر به امنیت بلاکچین، Smart Contract، DeFi و Web3 علاقه دارند، Immunefi مسیر متفاوتی ایجاد می‌کند. در این حوزه آسیب‌پذیری‌های Critical می‌توانند خسارت مالی بسیار بزرگی ایجاد کنند و به همین دلیل بعضی برنامه‌های Web3 پاداش‌های بسیار بالایی برای گزارش‌های مهم تعیین می‌کنند. البته شکار چنین آسیب‌پذیری‌هایی معمولاً به دانش تخصصی در Smart Contract Security، معماری بلاکچین و منطق پروتکل‌های مالی نیاز دارد و نباید صرفاً به دلیل مشاهده Bountyهای بزرگ وارد آن شد.
HackenProof نیز از پلتفرم‌هایی است که برنامه‌های Bug Bounty و پروژه‌های مرتبط با امنیت سایبری و Web3 را ارائه می‌کند و می‌تواند برای Researcherهایی که قصد بررسی گزینه‌های بیشتری خارج از پلتفرم‌های بسیار شلوغ را دارند قابل توجه باشد.
نکته مهم این است که بالاترین Bounty الزاماً به معنی بهترین سایت باگ بانتی برای شما نیست. یک برنامه با جایزه بسیار بالا ممکن است هزاران Researcher فعال داشته باشد، در حالی که یک برنامه کوچک‌تر با رقابت کمتر بتواند فرصت مناسب‌تری برای پیدا کردن اولین گزارش معتبر ایجاد کند. قبل از انتخاب هر برنامه باید نوع Target، میزان رقابت، Scope، سابقه پرداخت، قوانین گزارش‌دهی و سطح مهارت موردنیاز بررسی شود.
این موضوع برای کاربران داخل ایران یک مرحله مهم دیگر هم دارد. پیش از صرف زمان روی یک Target باید مشخص شود که پلتفرم و خود برنامه از نظر کشور محل اقامت، KYC و دریافت Payout چه شرایطی دارند. ممکن است یک سایت از نظر فنی بسیار مناسب باشد، اما محدودیت‌های جغرافیایی یا پرداخت باعث شود گزینه مناسبی برای Researcher ساکن ایران نباشد.
کدام سایت باگ بانتی برای کاربران ایرانی مناسب‌تر است؟
انتخاب بهترین سایت باگ بانتی برای ایرانیان فقط با مقایسه تعداد برنامه‌ها یا مقدار Bounty امکان‌پذیر نیست. یک پلتفرم ممکن است صدها Target جذاب و پاداش‌های بالایی داشته باشد، اما اگر Researcher ساکن ایران در مرحله احراز هویت، Country Eligibility یا دریافت Payout با محدودیت مواجه شود، عملاً گزینه مناسبی برای کسب درآمد نخواهد بود. به همین دلیل کاربران ایرانی باید قبل از شروع Hunting چهار موضوع را جداگانه بررسی کنند: امکان ساخت حساب، اجازه شرکت در برنامه موردنظر، امکان تکمیل KYC و امکان دریافت پاداش.
پلتفرم‌هایی مانند HackerOne، Bugcrowd، Intigriti، YesWeHack، HackenProof و Immunefi هرکدام ساختار و قوانین متفاوتی دارند و حتی داخل یک پلتفرم نیز ممکن است شرایط دو Bug Bounty Program یکسان نباشد. برای مثال، امکان مشاهده یا حتی شرکت در یک برنامه الزاماً به معنی واجد شرایط بودن برای دریافت Reward نیست. بعضی شرکت‌ها در قوانین برنامه مشخص می‌کنند که پرداخت پاداش به ساکنان برخی کشورها یا مناطق امکان‌پذیر نیست و این محدودیت می‌تواند مستقل از قوانین عمومی خود پلتفرم باشد.
موضوع احراز هویت یا KYC نیز برای Researcher ایرانی اهمیت زیادی دارد. در برخی پلتفرم‌ها ممکن است اطلاعات هویتی هنگام فعال‌سازی بعضی قابلیت‌ها یا پیش از پرداخت پاداش بررسی شود. نام و نام خانوادگی، کشور محل اقامت، مدرک هویتی و اطلاعات مرتبط با روش پرداخت می‌توانند بخشی از این فرایند باشند. به همین دلیل بهتر است قبل از صرف چند روز یا چند هفته روی یک Target، شرایط فعلی احراز هویت و پرداخت همان برنامه بررسی شود.
روش دریافت درآمد نیز باید از ابتدا در نظر گرفته شود. حتی اگر گزارش امنیتی Valid شناخته شود و شرکت برای آن Bounty تعیین کند، Researcher هنوز باید بتواند از روش پرداخت پشتیبانی‌شده استفاده کند. محدودیت سرویس‌های مالی بین‌المللی برای کاربران داخل ایران باعث می‌شود Payout یکی از مهم‌ترین معیارهای انتخاب پلتفرم باشد، نه موضوعی که بعد از پیدا کردن باگ به آن فکر شود.
در این میان نباید برای عبور از محدودیت‌ها از هویت جعلی، اطلاعات متعلق به شخص دیگر یا کشور غیرواقعی استفاده کرد. مغایرت اطلاعات حساب با مدارک KYC یا اطلاعات پرداخت می‌تواند هنگام بررسی حساب یا برداشت پاداش مشکل ایجاد کند. برای فعالیت حرفه‌ای و بلندمدت، انتخاب برنامه‌ای که شرایط آن با وضعیت واقعی Researcher سازگار باشد مسیر مطمئن‌تری است.
همچنین نمی‌توان یک پلتفرم را برای همیشه به‌عنوان «بهترین سایت باگ بانتی برای کاربران ایرانی» معرفی کرد؛ قوانین شرکت‌ها، محدودیت کشورها، الزامات KYC و روش‌های Payout ممکن است تغییر کنند. معیار درست این است که Researcher قبل از انتخاب هر Target، قوانین همان برنامه را در همان زمان بررسی کند و سپس بر اساس سطح مهارت، میزان Bounty، رقابت، Country Eligibility و امکان دریافت پاداش تصمیم بگیرد.
بعد از مشخص شدن این معیارها، مقایسه چند پلتفرم اصلی بسیار ساده‌تر می‌شود. در بخش بعدی، HackerOne، Bugcrowd، Intigriti و YesWeHack را از نظر نوع برنامه‌ها، سطح رقابت، فرصت درآمد و شرایط فعالیت با یکدیگر مقایسه می‌کنیم تا مشخص شود هرکدام برای چه نوع Bug Hunter مناسب‌تر هستند.
مقایسه HackerOne، Bugcrowd، Intigriti و YesWeHack؛ از کجا شروع کنیم؟
اگر قصد دارید فعالیت در Bug Bounty را جدی دنبال کنید، احتمالاً نام HackerOne، Bugcrowd، Intigriti و YesWeHack را بیشتر از سایر پلتفرم‌ها خواهید دید. هر چهار پلتفرم برای ارتباط میان شرکت‌ها و Security Researcherها طراحی شده‌اند، اما تفاوت در نوع برنامه‌ها، جامعه پژوهشگران، میزان رقابت و ساختار فعالیت باعث می‌شود انتخاب مناسب برای هر Bug Hunter متفاوت باشد.
./compare --platforms=4
برای شروع فقط به بالاترین Bounty نگاه نکنید؛ Scope، سطح رقابت، مهارت موردنیاز، KYC و امکان Payout معیارهای مهم‌تری برای انتخاب برنامه هستند.
HackerOne یکی از شناخته‌شده‌ترین نام‌های این حوزه است و به دلیل حضور تعداد زیادی سازمان و برنامه امنیتی، معمولاً یکی از اولین گزینه‌هایی است که افراد تازه‌وارد با آن آشنا می‌شوند. تنوع Targetها فرصت خوبی برای یادگیری ایجاد می‌کند، اما همین محبوبیت باعث شده بسیاری از برنامه‌های عمومی آن رقابت بالایی داشته باشند. در چنین محیطی احتمال Duplicate شدن گزارش نیز موضوع مهمی است؛ مخصوصاً زمانی که Researcher روی Targetهای شناخته‌شده و قسمت‌های واضح یک سرویس تمرکز می‌کند.
Bugcrowd نیز یکی از بازیگران اصلی بازار Crowdsourced Security است و علاوه بر Bug Bounty، برنامه‌های امنیتی مختلفی را مدیریت می‌کند. برای Researcherهایی که قصد دارند فعالیت خود را به‌صورت منظم ادامه دهند، شناخت دقیق Scope و قوانین هر برنامه در Bugcrowd اهمیت زیادی دارد. کیفیت گزارش، سابقه فعالیت و توانایی ارائه یک Vulnerability قابل بازتولید می‌تواند مسیر فعالیت حرفه‌ای Researcher را تحت تأثیر قرار دهد.
Intigriti گزینه مهم دیگری است که حضور قابل‌توجهی در اکوسیستم امنیت سایبری اروپا دارد. این پلتفرم برای افرادی که به دنبال Targetها و برنامه‌های متفاوت از دو پلتفرم بزرگ‌تر هستند می‌تواند جذاب باشد. با این حال، Country Eligibility و شرایط قانونی هر برنامه باید جداگانه بررسی شود؛ مخصوصاً برای کاربران ایرانی که امکان دریافت Reward به اندازه امکان شرکت فنی در برنامه اهمیت دارد.
YesWeHack نیز میزبان برنامه‌های Vulnerability Disclosure و Bug Bounty است و می‌تواند گزینه دیگری برای گسترش Targetهای یک Security Researcher باشد. محدود کردن فعالیت به یک پلتفرم همیشه بهترین استراتژی نیست؛ زیرا ممکن است برنامه‌ای با Scope مناسب مهارت شما در پلتفرم دیگری وجود داشته باشد که تعداد Researcherهای فعال روی آن کمتر باشد.
برای یک فرد تازه‌کار، انتخاب پلتفرمی با بیشترین جایزه الزاماً تصمیم مناسبی نیست. در شروع مسیر بهتر است به دنبال برنامه‌ای با Scope قابل فهم، قوانین شفاف، سطح فنی متناسب با مهارت و تعداد مناسبی از دارایی‌های قابل بررسی باشید. یک Target کوچک که ساختار آن را به‌خوبی درک می‌کنید می‌تواند ارزش آموزشی بیشتری از یک سرویس بسیار بزرگ با هزاران Hunter فعال داشته باشد.
Researcherهای باتجربه نیز معمولاً فقط نام پلتفرم را معیار انتخاب قرار نمی‌دهند. آنها Reward Table، تعداد و نوع Assetها، تغییرات جدید محصول، سطح رقابت، شرایط Disclosure و احتمال پیدا کردن Attack Surface جدید را بررسی می‌کنند. گاهی یک برنامه کمتر شناخته‌شده می‌تواند فرصت بهتری از یک برنامه بسیار محبوب ایجاد کند.
برای کاربران ایرانی یک معیار دیگر نیز باید به این مقایسه اضافه شود: KYC، Country Eligibility و Payout. ممکن است یک پلتفرم از نظر Target و میزان Bounty بسیار جذاب باشد، اما قوانین همان برنامه امکان پرداخت Reward به Researcher ساکن ایران را محدود کند. این شرایط نیز ثابت نیست و باید پیش از شروع فعالیت بر اساس قوانین فعلی برنامه بررسی شود.
برای شروع باگ بانتی چه مهارت‌هایی لازم است؟
برای شروع Bug Bounty لازم نیست از همان روز اول یک متخصص حرفه‌ای امنیت سایبری باشید، اما بدون شناخت اصول وب و امنیت، پیدا کردن آسیب‌پذیری واقعی بسیار دشوار خواهد بود. مسیر درست این است که ابتدا بفهمید یک وبسایت یا اپلیکیشن چگونه کار می‌کند و سپس یاد بگیرید چه اشتباهاتی در طراحی، برنامه‌نویسی یا کنترل دسترسی می‌توانند به Vulnerability تبدیل شوند. به همین دلیل یادگیری HTML و JavaScript در حد کاربردی، ساختار Request و Response، متدهای HTTP، Headerها، Cookie، Session، Token، API و نحوه عملکرد سیستم‌های Login و Authentication پایه مهمی برای ورود به این حوزه محسوب می‌شود.
پس از یادگیری این مفاهیم، باید با آسیب‌پذیری‌های رایج وب آشنا شوید. مواردی مانند XSS، SQL Injection، IDOR، Broken Access Control، Authentication Flaws، SSRF، CSRF، File Upload Vulnerabilities و Security Misconfiguration از مفاهیمی هستند که یک Bug Hunter باید سازوکار و Impact آنها را در محیط‌های آموزشی و مجاز درک کند. هدف فقط حفظ کردن نام آسیب‌پذیری‌ها نیست؛ Researcher باید بتواند رفتار غیرعادی یک سیستم را تشخیص دهد و بفهمد آیا این رفتار واقعاً می‌تواند امنیت کاربر یا سرویس را تحت تأثیر قرار دهد.
یکی از مهارت‌های بسیار مهم دیگر، کار با API است. بسیاری از سرویس‌های امروزی بخش قابل‌توجهی از ارتباط میان Front-End، اپلیکیشن موبایل و سرور را از طریق API انجام می‌دهند. شناخت REST API، JSON، پارامترها، Authentication Token و کنترل سطح دسترسی می‌تواند Attack Surface بسیار گسترده‌تری در اختیار Researcher قرار دهد. مخصوصاً مشکلات مربوط به Authorization و دسترسی یک کاربر به منابع کاربر دیگر از موضوعات مهم در بررسی امنیت برنامه‌های مدرن هستند.
یک Bug Bounty Hunter همچنین باید بتواند با ابزارهای پایه تحلیل ترافیک وب کار کند. ابزارهایی مانند Burp Suite برای مشاهده و بررسی Request و Response، تغییر پارامترها و تحلیل رفتار برنامه کاربرد زیادی دارند. در کنار ابزارها، آشنایی اولیه با Linux، Command Line، DNS، Subdomain، Domain، IP و مفاهیم پایه شبکه نیز باعث می‌شود Researcher در مراحل بعدی، مخصوصاً هنگام یادگیری Recon، درک بهتری از ساختار Target داشته باشد.
برنامه‌نویسی نیز می‌تواند سرعت پیشرفت را افزایش دهد. لازم نیست برای شروع یک Software Developer حرفه‌ای باشید، اما آشنایی با زبان‌هایی مانند Python و JavaScript کمک می‌کند منطق برنامه‌ها را بهتر درک کنید و در مراحل پیشرفته‌تر بعضی فعالیت‌های تکراری را برای اهداف مجاز خودکار کنید. توانایی خواندن کد نیز در پیدا کردن مشکلات منطقی و درک رفتار Front-End و API بسیار مفید است.
با این حال، یکی از مهم‌ترین مهارت‌هایی که افراد تازه‌کار کمتر به آن توجه می‌کنند تفکر تحلیلی است. ابزار امنیتی می‌تواند اطلاعات زیادی نمایش دهد، اما این Researcher است که باید تشخیص دهد چه چیزی غیرعادی است. سؤال‌هایی مانند «آیا کاربر A می‌تواند به اطلاعات کاربر B دسترسی پیدا کند؟»، «اگر ترتیب این فرایند تغییر کند چه اتفاقی می‌افتد؟» یا «آیا سرور واقعاً سطح دسترسی را کنترل می‌کند؟» همان نوع تفکری است که می‌تواند یک رفتار ساده را به یک گزارش امنیتی ارزشمند تبدیل کند.
در کنار مهارت فنی، توانایی نوشتن گزارش نیز اهمیت دارد. پیدا کردن یک Vulnerability زمانی ارزشمند است که بتوانید آن را به شکلی واضح، قابل بازتولید و همراه با Impact واقعی به تیم امنیتی توضیح دهید. Bug Bounty ترکیبی از دانش فنی، کنجکاوی، تحلیل رفتار سیستم، صبر و گزارش‌نویسی حرفه‌ای است؛ ترکیبی که با تمرین روی محیط‌های قانونی و آزمایشگاهی به‌مرور تقویت می‌شود.
مهم‌ترین آسیب‌پذیری‌هایی که Bug Hunterها از آنها درآمد کسب می‌کنند
همه آسیب‌پذیری‌ها در Bug Bounty ارزش یکسانی ندارند و صرف پیدا کردن یک رفتار غیرعادی به معنی دریافت پاداش نیست. شرکت‌ها معمولاً زمانی Bounty بیشتری پرداخت می‌کنند که یک Vulnerability بتواند تأثیر امنیتی واقعی روی کاربران، اطلاعات حساس یا زیرساخت سرویس ایجاد کند. به همین دلیل یک Bug Bounty Hunter حرفه‌ای به‌جای تمرکز صرف روی تعداد گزارش‌ها، تلاش می‌کند آسیب‌پذیری‌هایی را پیدا کند که Impact واقعی و قابل اثبات داشته باشند.
یکی از مهم‌ترین گروه‌ها، آسیب‌پذیری‌های مربوط به Broken Access Control و IDOR است. در چنین مشکلاتی ممکن است سیستم سطح دسترسی کاربران را به‌درستی کنترل نکند و یک کاربر بتواند به اطلاعات یا عملیاتی دسترسی پیدا کند که متعلق به حساب دیگری است. ارزش چنین باگی کاملاً به نوع اطلاعات و سطح دسترسی ایجادشده بستگی دارد؛ مشاهده یک داده عمومی با دسترسی غیرمجاز به اطلاعات خصوصی یا قابلیت‌های حساس حساب قابل مقایسه نیست.
مشکلات Authentication و Account Takeover نیز از یافته‌های مهم Bug Bounty هستند. نقص در فرایند ورود، بازیابی رمز عبور، مدیریت Session یا سایر مکانیزم‌های امنیتی حساب می‌تواند در شرایط خاص امنیت حساب کاربران را تحت تأثیر قرار دهد. اگر یک آسیب‌پذیری واقعاً امکان تصاحب حساب یا دسترسی غیرمجاز جدی ایجاد کند، معمولاً Impact بالاتری نسبت به مشکلات ظاهری و کم‌خطر خواهد داشت.
Cross-Site Scripting یا XSS نیز یکی از شناخته‌شده‌ترین آسیب‌پذیری‌های وب است. با این حال وجود XSS به‌تنهایی مقدار پاداش را مشخص نمی‌کند. محل آسیب‌پذیری، کاربران تحت تأثیر و پیامد واقعی آن اهمیت زیادی دارند. یک XSS محدود با شرایط پیچیده ممکن است شدت پایینی داشته باشد، در حالی که آسیب‌پذیری مشابه در بخش حساس یک سرویس می‌تواند اهمیت بیشتری پیدا کند.
SQL Injection همچنان یکی از آسیب‌پذیری‌های جدی در امنیت وب محسوب می‌شود، زیرا در صورت وجود شرایط مناسب می‌تواند امنیت اطلاعات سمت سرور را تحت تأثیر قرار دهد. البته سرویس‌های مدرن از روش‌های دفاعی مختلفی استفاده می‌کنند و پیدا کردن SQL Injection معتبر در بسیاری از Targetهای بزرگ به سادگی گذشته نیست. شدت نهایی نیز بر اساس میزان دسترسی و Impact واقعی تعیین می‌شود.
از دیگر دسته‌های مهم می‌توان به SSRF، File Upload Vulnerabilities، Security Misconfiguration و Business Logic Flaws اشاره کرد. مخصوصاً باگ‌های Business Logic اهمیت زیادی دارند، زیرا همیشه با یک ابزار یا اسکنر آماده پیدا نمی‌شوند. گاهی Researcher با درک عمیق فرایند خرید، پرداخت، اعتبار حساب، تخفیف، سطح دسترسی یا سایر منطق‌های یک سرویس متوجه می‌شود که ترکیب چند رفتار عادی می‌تواند نتیجه‌ای ایجاد کند که توسعه‌دهنده انتظار آن را نداشته است.
در APIها نیز مشکلات Authorization و Authentication اهمیت زیادی دارند. اپلیکیشن‌های امروزی برای بسیاری از قابلیت‌های خود به API متکی هستند و اگر کنترل دسترسی در سمت سرور به‌درستی اجرا نشده باشد، ممکن است داده یا عملکرد حساسی در اختیار کاربر غیرمجاز قرار گیرد. همین موضوع باعث شده API Security به یکی از مهارت‌های ارزشمند برای Bug Hunterهای امروزی تبدیل شود.
مقدار Bounty هیچ‌کدام از این آسیب‌پذیری‌ها از قبل تضمین‌شده نیست. تیم امنیتی معمولاً عواملی مانند Severity، Exploitability، تعداد کاربران تحت تأثیر، حساسیت اطلاعات، Scope و Impact واقعی را بررسی می‌کند. به همین دلیل ممکن است دو گزارش با نام فنی مشابه، پاداش کاملاً متفاوتی دریافت کنند.
از صفر تا اولین باگ؛ نقشه راه شروع Bug Bounty برای مبتدی‌ها
شروع Bug Bounty برای بسیاری از افراد در ابتدا پیچیده به نظر می‌رسد، زیرا با مجموعه بزرگی از اصطلاحات، آسیب‌پذیری‌ها و ابزارهای امنیتی روبه‌رو می‌شوند. اشتباه رایج این است که فرد تلاش می‌کند همه چیز را هم‌زمان یاد بگیرد؛ در حالی که مسیر مؤثرتر این است که ابتدا پایه‌های وب را بشناسد، سپس چند آسیب‌پذیری مشخص را عمیق یاد بگیرد و بعد وارد برنامه‌های واقعی و مجاز Bug Bounty شود.
نقطه شروع مناسب، یادگیری نحوه عملکرد وب است. باید بدانید Browser چگونه با Server ارتباط برقرار می‌کند، Request و Response چیست، HTTP Methodها چه کاربردی دارند و Cookie، Session، Token، Header، Parameter و API چگونه کار می‌کنند. بدون درک این مفاهیم، استفاده از ابزارهای امنیتی بیشتر شبیه اجرای دستورهای آماده خواهد بود تا تحلیل واقعی یک سیستم.
پس از تسلط نسبی بر این پایه‌ها، بهتر است به‌جای مطالعه سطحی ده‌ها Vulnerability، ابتدا روی چند موضوع مهم مانند Broken Access Control، IDOR، Authentication، XSS و API Security تمرکز کنید. تمرین باید در آزمایشگاه‌ها و محیط‌هایی انجام شود که صراحتاً برای آموزش و تست امنیتی طراحی شده‌اند. هدف این مرحله فقط حل Lab نیست؛ باید بفهمید آسیب‌پذیری چرا ایجاد شده، چه Impactی دارد و توسعه‌دهنده چگونه می‌توانسته از ایجاد آن جلوگیری کند.
مرحله بعدی یادگیری ابزارهای موردنیاز است. Burp Suite یکی از ابزارهای مهم برای مشاهده و تحلیل ارتباط میان مرورگر و سرور است و یادگیری آن می‌تواند درک Requestها، Responseها، Cookieها، Tokenها و پارامترهای API را بسیار ساده‌تر کند. در کنار آن، آشنایی با Browser Developer Tools، Linux و Command Line نیز در ادامه مسیر کاربرد زیادی خواهد داشت. ابزار باید مکمل دانش Researcher باشد، نه جایگزین آن.
زمانی که بتوانید رفتار یک برنامه وب را تحلیل کنید، می‌توانید یک Bug Bounty Program مجاز متناسب با سطح خود انتخاب کنید. قبل از هر آزمایش باید Scope و Out of Scope را کامل بخوانید و فقط دارایی‌هایی را بررسی کنید که برنامه اجازه داده است. برای شروع بهتر است به‌جای انتخاب معروف‌ترین Target با بیشترین Bounty، برنامه‌ای با Scope واضح و ساختاری انتخاب کنید که بتوانید منطق آن را درک کنید.
در اولین Huntingها بهتر است یک قابلیت مشخص را انتخاب کرده و همان قسمت را عمیق بررسی کنید. برای مثال می‌توان روی منطق حساب کاربری، سطح دسترسی، مدیریت Session یا رفتار API تمرکز کرد. بررسی هدفمند معمولاً نتیجه بهتری از حرکت تصادفی بین ده‌ها صفحه و اجرای تعداد زیادی ابزار مختلف دارد. Bug Hunter باید یاد بگیرد از خودش بپرسد سیستم در حالت عادی چه رفتاری دارد و چه تغییری می‌تواند باعث رفتاری شود که توسعه‌دهنده انتظار آن را نداشته است.
اولین گزارش نیز لزوماً به اولین درآمد منجر نمی‌شود. Duplicate، Informative و Not Applicable شدن گزارش بخشی از فرایند یادگیری Bug Bounty است. به‌جای کنار گذاشتن مسیر، باید دلیل بسته شدن گزارش را بررسی کرد. اگر گزارش Duplicate شده، احتمالاً Researcher باید روی Attack Surfaceهای جدیدتر یا قسمت‌های کمتر بررسی‌شده تمرکز کند. اگر Impact کافی نداشته، باید درک خود از اهمیت امنیتی یافته‌ها را تقویت کند.
هدف یک فرد تازه‌کار نباید پیدا کردن یک Critical در هفته اول باشد. رسیدن از صفر به اولین گزارش معتبر نقطه عطف بسیار مهم‌تری است، زیرا نشان می‌دهد فرد توانسته دانش تئوری را روی یک سیستم واقعی و در محدوده مجاز به کار بگیرد. پس از آن، با هر Target و هر گزارش، سرعت تحلیل و توانایی تشخیص رفتارهای غیرعادی افزایش پیدا می‌کند.
چگونه یک برنامه باگ بانتی سودآور انتخاب کنیم؟
یکی از تفاوت‌های مهم میان یک Bug Hunter تازه‌کار و Researcher باتجربه، نحوه انتخاب Bug Bounty Program است. بسیاری از افراد فقط برنامه‌هایی را انتخاب می‌کنند که بیشترین Bounty را تبلیغ کرده‌اند، در حالی که بالا بودن حداکثر پاداش الزاماً به معنی فرصت درآمد بهتر نیست. برنامه‌ای با جایزه ۲۰ هزار دلاری ممکن است هزاران Researcher فعال داشته باشد و پیدا کردن یک آسیب‌پذیری جدید در آن بسیار دشوار باشد؛ در مقابل، یک برنامه کوچک‌تر با Attack Surface گسترده‌تر یا قابلیت‌های تازه می‌تواند فرصت واقعی‌تری برای کشف Vulnerability ایجاد کند.
اولین چیزی که باید بررسی شود Scope برنامه است. تعداد Domainها، Subdomainها، APIها، اپلیکیشن‌های موبایل و سایر Assetهای مجاز مشخص می‌کند چه فضای قانونی برای بررسی در اختیار Researcher قرار دارد. برنامه‌ای که چندین محصول و سرویس مختلف دارد می‌تواند Attack Surface بزرگ‌تری ایجاد کند، اما مهم‌تر از تعداد Assetها این است که Researcher بتواند ساختار آنها را درک کند و متناسب با مهارت خود روی آنها تمرکز داشته باشد.
موضوع بعدی Reward Table است. قبل از شروع Hunting باید مشخص باشد برنامه برای آسیب‌پذیری‌های Low، Medium، High و Critical چه سیاستی دارد و آیا تمام Assetها از یک ساختار پرداخت استفاده می‌کنند یا خیر. بعضی برنامه‌ها برای سرویس‌های حساس‌تر پاداش بیشتری در نظر می‌گیرند و برخی یافته‌ها نیز ممکن است اصلاً واجد شرایط Bounty نباشند. مطالعه این قسمت کمک می‌کند ارزش زمانی که قرار است روی Target صرف شود بهتر ارزیابی شود.
رقابت نیز عامل مهمی است. Targetهای مشهور معمولاً Researcherهای بیشتری جذب می‌کنند و احتمال اینکه یک یافته قبلاً گزارش شده باشد افزایش پیدا می‌کند. به همین دلیل شکارچیان باتجربه فقط به معروف بودن شرکت نگاه نمی‌کنند؛ آنها تغییرات جدید محصول، APIهای تازه، قابلیت‌های جدید، Assetهای اضافه‌شده به Scope و بخش‌هایی را که احتمالاً کمتر مورد بررسی قرار گرفته‌اند نیز دنبال می‌کنند. گاهی یک قابلیت تازه‌منتشرشده ارزش بررسی بیشتری از قسمت اصلی یک سرویس قدیمی دارد.
قوانین Out of Scope نیز باید قبل از هر آزمایش مطالعه شوند. ممکن است یک نوع Vulnerability از نظر فنی معتبر باشد اما برنامه آن را واجد شرایط پاداش نداند. همچنین برخی روش‌های تست می‌توانند ممنوع باشند. نادیده گرفتن این قوانین نه‌تنها زمان Researcher را هدر می‌دهد، بلکه ممکن است باعث نقض Policy برنامه شود. تمام بررسی‌ها باید دقیقاً در محدوده مجاز انجام شوند.
برای کاربران ایرانی، سودآور بودن برنامه یک شرط اضافه نیز دارد. پیش از شروع باید Country Eligibility، KYC و Payout بررسی شود. یک Critical با پاداش بالقوه بالا زمانی ارزش اقتصادی دارد که Researcher طبق قوانین برنامه واجد شرایط دریافت آن باشد. به همین دلیل بررسی محدودیت کشور و روش پرداخت باید قبل از Hunting انجام شود، نه بعد از تأیید گزارش.
یک Bug Hunter حرفه‌ای در واقع قبل از بررسی فنی، ارزش Target را ارزیابی می‌کند: آیا Scope مناسبی دارد؟ آیا برنامه فعال و شفاف است؟ آیا نوع آسیب‌پذیری‌های مورد قبول با تخصص او هماهنگ است؟ رقابت چقدر است؟ آیا قابلیت یا Asset جدیدی وجود دارد؟ و آیا در صورت پیدا کردن باگ امکان دریافت Reward وجود خواهد داشت؟ پاسخ همین سؤالات می‌تواند مشخص کند چند ساعت یا چند روز زمان روی یک برنامه ارزش صرف کردن دارد.
بعد از انتخاب Target مناسب، مرحله‌ای شروع می‌شود که بسیاری از Hunterهای حرفه‌ای اهمیت زیادی برای آن قائل هستند: Recon. در بخش بعدی بررسی می‌کنیم Recon در Bug Bounty چیست و چگونه شناخت درست Attack Surface می‌تواند Researcher را به قسمت‌هایی از یک Target برساند که کمتر مورد توجه قرار گرفته‌اند.
Recon در باگ بانتی چیست و چرا شکار باگ از اینجا شروع می‌شود؟
Recon یا Reconnaissance در Bug Bounty به فرایند شناخت و نقشه‌برداری از سطح حمله یا Attack Surface یک هدف گفته می‌شود. قبل از اینکه Bug Hunter به دنبال یک آسیب‌پذیری مشخص بگردد، باید بداند شرکت چه سرویس‌ها، دامنه‌ها، Subdomainها، APIها و سایر Assetهای مجازی در محدوده مجاز برنامه دارد و کدام بخش‌ها ارزش بررسی بیشتری دارند. Recon خوب می‌تواند تفاوت میان بررسی همان قسمت‌هایی که صدها Researcher قبلاً دیده‌اند و پیدا کردن یک Asset کمترشناخته‌شده را ایجاد کند.
در برنامه‌های بزرگ، دامنه اصلی معمولاً فقط بخش کوچکی از زیرساختی است که در Scope قرار دارد. ممکن است شرکت سرویس‌های مختلفی برای کاربران، توسعه‌دهندگان، API، پنل مدیریت، نسخه‌های آزمایشی یا محصولات جانبی داشته باشد. Researcher با بررسی دارایی‌هایی که برنامه صراحتاً اجازه تست آنها را داده است، تلاش می‌کند تصویر واضح‌تری از ساختار Target ایجاد کند و بفهمد کدام قسمت‌ها احتمالاً Attack Surface بیشتری دارند.
هدف Recon اجرای تعداد زیادی ابزار و جمع‌آوری هزاران نتیجه نیست. حجم بالای داده زمانی ارزش دارد که بتوان اطلاعات مهم را از نویز جدا کرد. یک Bug Hunter حرفه‌ای ممکن است از میان تعداد زیادی Asset تنها چند مورد را برای بررسی عمیق انتخاب کند؛ برای مثال سرویسی که به‌تازگی اضافه شده، API متفاوتی دارد، از Authentication مستقلی استفاده می‌کند یا رفتار آن با سایر قسمت‌های محصول متفاوت است.
Recon می‌تواند شامل بررسی اطلاعات عمومی و دارایی‌هایی باشد که طبق Scope برنامه مجاز هستند؛ از شناخت ساختار Domain و Subdomain گرفته تا بررسی Endpointهای قابل مشاهده، APIها و فناوری‌های مورد استفاده. در این مرحله نیز قوانین Bug Bounty Program اولویت دارند و Researcher نباید به بهانه Recon از محدوده تعیین‌شده عبور کند یا روی Assetهایی که برنامه اجازه نداده آزمایش امنیتی انجام دهد.
یکی از مزایای مهم Recon، کاهش احتمال Duplicate است. در Targetهای بسیار محبوب، صفحات اصلی و قابلیت‌های واضح معمولاً بارها توسط Hunterهای مختلف بررسی شده‌اند. شناخت بهتر Attack Surface می‌تواند Researcher را به قابلیت‌های جدیدتر یا قسمت‌هایی هدایت کند که توجه کمتری دریافت کرده‌اند. البته کمتر دیده شدن یک Asset تضمینی برای وجود Vulnerability نیست، اما می‌تواند فضای تحقیق متفاوتی ایجاد کند.
Recon همچنین یک فعالیت یک‌باره نیست. محصولات آنلاین دائماً تغییر می‌کنند؛ قابلیت جدید منتشر می‌شود، API تازه‌ای اضافه می‌شود یا Scope برنامه تغییر می‌کند. به همین دلیل Researcherهای باتجربه معمولاً تغییرات مجاز Target را نیز دنبال می‌کنند. گاهی همان سرویسی که چند ماه قبل به‌خوبی بررسی شده، پس از یک تغییر مهم دوباره ارزش تحلیل پیدا می‌کند.
چگونه باگ‌های کم‌رقابت و باارزش پیدا کنیم؟
یکی از بزرگ‌ترین چالش‌های Bug Bounty این است که هزاران Security Researcher ممکن است هم‌زمان روی برنامه‌های عمومی فعالیت کنند. اگر همه افراد دقیقاً صفحات اصلی، فرم ورود و قابلیت‌های شناخته‌شده یک Target را بررسی کنند، احتمال پیدا کردن Vulnerability جدید کاهش پیدا می‌کند و حتی یک یافته معتبر ممکن است قبلاً توسط فرد دیگری گزارش شده باشد. به همین دلیل یکی از مهارت‌های مهم Bug Hunterهای باتجربه، پیدا کردن Attack Surfaceهایی است که کمتر مورد توجه قرار گرفته‌اند اما همچنان در Scope برنامه قرار دارند.
کم‌رقابت بودن الزاماً به معنی پیدا کردن یک وبسایت ناشناخته نیست. گاهی در یک برنامه بسیار معروف، قابلیت تازه‌ای منتشر شده، API جدیدی اضافه شده یا محصول جانبی جدیدی وارد Scope شده است. چنین تغییراتی می‌توانند فرصت تحقیق ایجاد کنند، زیرا ممکن است هنوز به اندازه قسمت‌های قدیمی سرویس توسط Researcherها بررسی نشده باشند. دنبال کردن تغییرات مجاز Target و مطالعه به‌روزرسانی‌های Scope به همین دلیل اهمیت دارد.
یکی دیگر از روش‌های مؤثر، انتخاب یک بخش مشخص و بررسی عمیق منطق آن است. به‌جای حرکت سریع میان ده‌ها صفحه، Researcher می‌تواند نحوه عملکرد یک قابلیت را از ابتدا تا انتها درک کند؛ اینکه چه اطلاعاتی دریافت می‌شود، چه سطح دسترسی‌هایی وجود دارد، API چگونه رفتار می‌کند و سرور در مراحل مختلف چه تصمیمی می‌گیرد. این نوع بررسی عمیق مخصوصاً برای پیدا کردن Business Logic Flaws و Access Control Issues ارزشمند است، زیرا بسیاری از این مشکلات با اسکن خودکار قابل تشخیص نیستند.
تخصصی شدن نیز می‌تواند رقابت را کاهش دهد. فردی که فقط آسیب‌پذیری‌های بسیار معروف را جست‌وجو می‌کند با تعداد زیادی Hunter دیگر رقابت خواهد داشت، اما Researcherی که در حوزه مشخصی مانند API Security، Authorization، Authentication یا Business Logic مهارت عمیق‌تری پیدا کرده است، می‌تواند رفتارهایی را تشخیص دهد که برای افراد کم‌تجربه عادی به نظر می‌رسند.
عامل مهم دیگر، انتخاب Target بر اساس مهارت است نه صرفاً مبلغ Bounty. یک برنامه با Critical Reward بسیار بالا ممکن است جذاب به نظر برسد، اما اگر ساختار آن خارج از تخصص شما باشد، احتمال پیدا کردن گزارش معتبر پایین خواهد بود. گاهی برنامه‌ای با پاداش متوسط که معماری و منطق آن را بهتر درک می‌کنید، از نظر زمانی انتخاب سودآورتری است.
در این مسیر نباید کم‌رقابت بودن را با خروج از محدوده برنامه اشتباه گرفت. تمام تحقیقات باید روی Assetها و روش‌هایی انجام شوند که Bug Bounty Program اجازه داده است. پیدا کردن یک Subdomain یا سرویس جدید نیز به‌تنهایی به معنی مجاز بودن تست آن نیست؛ Scope همیشه مرجع اصلی تعیین محدوده آزمایش است.
هدف یک Hunter حرفه‌ای این نیست که بیشتر از دیگران درخواست ارسال کند؛ هدف این است که قسمت متفاوت و ارزشمندتری از سیستم را بهتر از دیگران درک کند. همین نگاه می‌تواند احتمال رسیدن به گزارش‌های باکیفیت را افزایش دهد و تعداد Duplicateها را کاهش دهد.
چرا بیشتر باگ‌های شما Duplicate یا Informative می‌شوند؟
یکی از ناامیدکننده‌ترین تجربه‌ها برای افراد تازه‌وارد به Bug Bounty این است که پس از چند ساعت یا حتی چند روز بررسی یک Target، گزارش ارسال‌شده با وضعیت Duplicate، Informative، Not Applicable یا Out of Scope بسته شود. این اتفاق الزاماً به معنی ضعیف بودن Researcher نیست؛ بلکه بخشی طبیعی از فعالیت در برنامه‌های باگ بانتی است. تفاوت Bug Hunter باتجربه با فرد تازه‌کار در این است که از دلیل بسته شدن گزارش برای اصلاح روش Hunting خود استفاده می‌کند.
آسیب‌پذیری معتبر است، اما Researcher دیگری زودتر همان مشکل یا Root Cause را گزارش کرده است.
رفتار گزارش‌شده وجود دارد، اما ریسک امنیتی قابل‌توجه یا اثر عملی کافی برای دریافت Bounty نشان داده نشده است.
یافته بر اساس Policy و معیارهای امنیتی برنامه، آسیب‌پذیری قابل قبول محسوب نشده است.
Asset یا نوع تست انجام‌شده در محدوده مجاز Bug Bounty Program قرار نداشته است.
وضعیت Duplicate معمولاً زمانی ثبت می‌شود که آسیب‌پذیری موردنظر قبلاً توسط Researcher دیگری گزارش شده باشد. این مشکل در برنامه‌های عمومی و Targetهای محبوب بیشتر دیده می‌شود، زیرا تعداد زیادی Hunter روی یک Attack Surface مشترک فعالیت می‌کنند. حتی ممکن است گزارش شما کاملاً صحیح و باکیفیت باشد، اما Researcher دیگری چند ساعت یا چند روز زودتر همان Root Cause را گزارش کرده باشد. در چنین شرایطی معمولاً اولویت با گزارش قبلی است و گزارش بعدی Bounty جداگانه‌ای دریافت نمی‌کند.
برای کاهش Duplicate، تمرکز صرف روی قسمت‌های واضح یک سرویس همیشه بهترین روش نیست. قابلیت‌های جدید، Assetهای تازه اضافه‌شده به Scope، APIها و بخش‌های کمتر بررسی‌شده می‌توانند فرصت متفاوتی ایجاد کنند. سرعت در گزارش یک یافته معتبر نیز اهمیت دارد؛ اگر Vulnerability را به‌طور کافی تأیید کرده‌اید، نگه داشتن غیرضروری گزارش برای چند روز می‌تواند احتمال Duplicate شدن آن را افزایش دهد.
Informative شرایط متفاوتی دارد. ممکن است رفتار گزارش‌شده واقعاً وجود داشته باشد، اما تیم امنیتی Impact قابل‌توجهی برای آن تشخیص ندهد یا یافته به‌تنهایی ریسک امنیتی کافی ایجاد نکند. یکی از اشتباهات رایج تازه‌کارها این است که وجود یک رفتار غیرعادی را مستقیماً برابر با Vulnerability می‌دانند. در Bug Bounty سؤال مهم این نیست که «آیا این رفتار عجیب است؟» بلکه باید مشخص شود این رفتار چه خطر واقعی برای کاربر یا شرکت ایجاد می‌کند؟
وضعیت Not Applicable نیز معمولاً نشان می‌دهد گزارش بر اساس معیارهای برنامه به‌عنوان آسیب‌پذیری قابل قبول شناخته نشده است. گاهی Researcher بدون مطالعه Policy، موردی را گزارش می‌کند که شرکت قبلاً آن را در فهرست یافته‌های غیرقابل قبول قرار داده است. بررسی دقیق Scope، Out of Scope و Known Issues قبل از شروع Hunting می‌تواند بخش قابل‌توجهی از چنین گزارش‌هایی را حذف کند.
کیفیت گزارش نیز تأثیر زیادی دارد. اگر مراحل بازتولید نامشخص باشند، توضیح Impact ضعیف باشد یا تیم امنیتی نتواند نتیجه گزارش را بازتولید کند، حتی یک یافته بالقوه مهم نیز ممکن است زمان بیشتری برای بررسی نیاز داشته باشد. یک گزارش حرفه‌ای باید به تیم Triager کمک کند در کوتاه‌ترین زمان بفهمد مشکل چیست، چگونه ایجاد می‌شود و چرا اهمیت دارد.
بهترین رویکرد این است که هر گزارش بسته‌شده را به یک داده آموزشی تبدیل کنید. اگر Duplicate زیاد دارید، احتمالاً باید Target و Attack Surface خود را تغییر دهید. اگر Informative زیاد دریافت می‌کنید، روی درک Impact و Severity بیشتر کار کنید. اگر گزارش‌های شما Out of Scope هستند، قبل از Hunting زمان بیشتری برای مطالعه Policy اختصاص دهید. کاهش گزارش‌های ناموفق بیشتر از افزایش تعداد گزارش‌ها می‌تواند نشانه پیشرفت واقعی یک Bug Bounty Hunter باشد.
چگونه گزارش باگ حرفه‌ای بنویسیم تا شانس دریافت Bounty بیشتر شود؟
پیدا کردن یک آسیب‌پذیری فقط نیمی از کار یک Bug Bounty Hunter است؛ نیمه دیگر این است که بتوانید یافته خود را به شکلی دقیق، قابل فهم و قابل بازتولید به تیم امنیتی منتقل کنید. یک Bug Report حرفه‌ای باید به Triager کمک کند در کوتاه‌ترین زمان متوجه شود مشکل چیست، کدام قسمت سرویس تحت تأثیر قرار دارد، چگونه می‌توان آن را بازتولید کرد و مهم‌تر از همه، این آسیب‌پذیری چه Impact واقعی برای کاربران یا سازمان ایجاد می‌کند. گزارش‌های مبهم، طولانی و بدون ساختار می‌توانند بررسی یک یافته معتبر را نیز دشوار کنند.
عنوان گزارش باید کوتاه اما دقیق باشد. نوشتن عباراتی مانند «Critical Bug Found» یا «Security Issue» اطلاعات مفیدی به تیم امنیتی نمی‌دهد. عنوان مناسب بهتر است نوع آسیب‌پذیری، قسمت تحت تأثیر و نتیجه اصلی آن را مشخص کند. Triager باید با مشاهده عنوان، تصویر اولیه‌ای از موضوع گزارش به دست آورد و بداند قرار است چه مشکلی را بررسی کند.
پس از عنوان، باید محل آسیب‌پذیری و شرایط لازم برای بازتولید آن توضیح داده شود. اگر مشکل مربوط به یک Endpoint، قابلیت حساب کاربری یا API مشخص است، این موضوع باید واضح باشد. سپس مراحل بازتولید باید به ترتیب نوشته شوند؛ به شکلی که فرد بررسی‌کننده بتواند بدون حدس زدن مراحل، همان رفتار را در محیط مجاز مشاهده کند. حذف جزئیات ضروری یا اضافه کردن توضیحات نامرتبط هر دو می‌توانند بررسی گزارش را کند کنند.
یکی از مهم‌ترین قسمت‌های گزارش، Impact است. بسیاری از افراد فقط توضیح می‌دهند که چه اتفاقی افتاده، اما مشخص نمی‌کنند چرا این اتفاق از نظر امنیتی اهمیت دارد. برای مثال، صرف تغییر یک Parameter لزوماً آسیب‌پذیری محسوب نمی‌شود؛ باید مشخص شود این تغییر چه دسترسی غیرمجازی ایجاد می‌کند، چه داده‌ای ممکن است در معرض خطر قرار گیرد یا چه مرز امنیتی‌ای شکسته می‌شود. هرچه ارتباط میان Vulnerability و پیامد واقعی آن واضح‌تر باشد، تیم امنیتی راحت‌تر می‌تواند Severity را ارزیابی کند.
استفاده از Screenshot یا Video کوتاه نیز در بعضی گزارش‌ها می‌تواند مفید باشد، مخصوصاً زمانی که رفتار آسیب‌پذیری با متن به‌تنهایی به‌راحتی قابل توضیح نیست. با این حال مدرک تصویری جای توضیحات دقیق را نمی‌گیرد. گزارش باید حتی بدون تماشای یک ویدیوی طولانی نیز ساختار قابل فهمی داشته باشد و از قرار دادن اطلاعات حساس غیرضروری خودداری شود.
Researcher همچنین نباید Severity را با اغراق افزایش دهد. استفاده از عباراتی مانند Critical یا Account Takeover زمانی ارزش دارد که Impact گزارش واقعاً چنین سطحی را پشتیبانی کند. بزرگ‌نمایی می‌تواند اعتبار گزارش را کاهش دهد. بهتر است شواهد فنی و پیامد واقعی به‌وضوح ارائه شوند و ارزیابی نهایی Severity طبق سیاست برنامه و بررسی تیم امنیتی انجام شود.
سرعت ارسال گزارش نیز مهم است، اما نباید باعث ارسال یک گزارش ناقص شود. زمانی که Vulnerability به اندازه کافی و در محدوده مجاز تأیید شده است، بهتر است گزارش واضح و مستند ارسال شود. آزمایش‌های غیرضروری برای اثبات بیشتر Impact ممکن است نه‌تنها لازم نباشند، بلکه از محدوده مجاز برنامه عبور کنند. همیشه Policy برنامه مشخص می‌کند Researcher تا چه اندازه اجازه تست دارد.
CVSS و شدت باگ چیست؟ چرا یک باگ ۱۰۰ دلار و دیگری ۱۰,۰۰۰ دلار می‌ارزد؟
یکی از مهم‌ترین سؤال‌ها در Bug Bounty این است که چرا دو آسیب‌پذیری که در نگاه اول مشابه به نظر می‌رسند، ممکن است پاداش‌های کاملاً متفاوتی داشته باشند. ممکن است یک گزارش تنها چندصد دلار Bounty دریافت کند، در حالی که Vulnerability دیگری چند هزار یا حتی ده‌ها هزار دلار ارزش‌گذاری شود. دلیل اصلی این تفاوت فقط نام آسیب‌پذیری نیست؛ Severity، Impact واقعی، شرایط سوءاستفاده، اهمیت Asset و Reward Policy برنامه همگی در تعیین ارزش یک گزارش نقش دارند.
یکی از استانداردهای شناخته‌شده برای ارزیابی شدت آسیب‌پذیری‌ها CVSS یا Common Vulnerability Scoring System است. CVSS تلاش می‌کند ویژگی‌های فنی یک Vulnerability را به یک امتیاز عددی از 0 تا 10 تبدیل کند. در تقسیم‌بندی رایج CVSS v3.1، امتیاز 0 در سطح None، امتیاز 0.1 تا 3.9 در سطح Low، امتیاز 4.0 تا 6.9 در سطح Medium، امتیاز 7.0 تا 8.9 در سطح High و امتیاز 9.0 تا 10 در سطح Critical قرار می‌گیرد. البته برنامه‌های Bug Bounty الزاماً مبلغ پاداش را مستقیماً از روی همین عدد تعیین نمی‌کنند.
در محاسبه Severity عواملی مانند امکان Exploit شدن آسیب‌پذیری از راه دور یا نیاز به دسترسی محلی، پیچیدگی حمله، نیاز یا عدم نیاز به سطح دسترسی قبلی، نیاز به تعامل کاربر و میزان تأثیر روی محرمانگی، صحت و دسترس‌پذیری اطلاعات بررسی می‌شوند. به همین دلیل دو آسیب‌پذیری از یک خانواده می‌توانند امتیازهای متفاوتی داشته باشند.
برای مثال، یک XSS محدود که تنها در شرایط خاص و با تعامل زیاد کاربر قابل استفاده است ممکن است Impact نسبتاً پایینی داشته باشد، در حالی که یک آسیب‌پذیری دیگر در همان خانواده اگر بتواند تعداد زیادی کاربر یا بخش حساس‌تری از سرویس را تحت تأثیر قرار دهد، ارزیابی متفاوتی خواهد داشت. در مشکلات Access Control نیز دسترسی به اطلاعات کم‌اهمیت با دسترسی غیرمجاز به اطلاعات حساس تعداد زیادی کاربر از نظر Severity یکسان نیست.
در Bug Bounty مفهوم Business Impact نیز بسیار مهم است. CVSS بیشتر یک چارچوب استاندارد برای ارزیابی فنی است، اما شرکت ممکن است اهمیت تجاری Asset، حساسیت اطلاعات، تعداد کاربران تحت تأثیر و پیامد احتمالی سوءاستفاده را نیز در نظر بگیرد. به همین علت امتیاز CVSS بالا به‌تنهایی تضمین نمی‌کند که Researcher حتماً بالاترین Bounty موجود در Reward Table را دریافت کند.
مبلغ پاداش همچنین به سیاست همان برنامه بستگی دارد. یک شرکت ممکن است برای Critical Vulnerability سقف چند هزار دلاری تعیین کرده باشد و برنامه دیگری برای آسیب‌پذیری با Impact مشابه Reward بسیار بیشتری ارائه دهد. به همین دلیل هنگام انتخاب Target باید علاوه بر Scope، جدول Reward یا Bounty Table برنامه نیز بررسی شود. اعدادی مانند 100 یا 10,000 دلار مثال‌هایی برای نشان دادن اختلاف احتمالی پاداش هستند و نرخ ثابتی برای تمام برنامه‌های Bug Bounty محسوب نمی‌شوند.
Researcher حرفه‌ای نیز نباید برای افزایش Bounty تلاش کند Severity گزارش را به‌صورت مصنوعی بزرگ‌تر نشان دهد. رویکرد بهتر این است که Vulnerability، شرایط لازم برای بازتولید و Impact واقعی آن دقیق توضیح داده شود. اگر یک زنجیره امنیتی واقعاً وجود دارد، ارتباط مراحل باید مستند باشد؛ اما سناریوهای غیرواقعی یا فرض‌های دور از دسترس معمولاً ارزش گزارش را افزایش نمی‌دهند.
شناخت CVSS به Bug Hunter کمک می‌کند قبل از ارسال گزارش بهتر متوجه شود یافته او تقریباً در چه سطحی قرار دارد، اما چیزی که یک گزارش را واقعاً باارزش می‌کند اثر امنیتی قابل اثبات آن است. یک باگ ساده با Impact جدی می‌تواند بسیار مهم‌تر از یک یافته پیچیده بدون پیامد واقعی باشد.
احراز هویت سایت‌های باگ بانتی برای ایرانیان چگونه است؟
برای کاربران ایرانی، انتخاب یک پلتفرم Bug Bounty فقط به تعداد برنامه‌ها یا میزان Bounty محدود نمی‌شود. قبل از صرف زمان برای پیدا کردن Vulnerability باید مشخص شود آیا Researcher امکان شرکت در برنامه موردنظر، تکمیل KYC یا احراز هویت و دریافت قانونی پاداش را دارد یا خیر. ممکن است ساخت حساب کاربری در یک پلتفرم امکان‌پذیر باشد، اما این موضوع به‌تنهایی به معنی امکان شرکت در تمام برنامه‌ها یا دریافت Reward نیست.
KYC مخفف Know Your Customer است و پلتفرم‌ها ممکن است برای تأیید هویت Researcher، فعال‌سازی برخی قابلیت‌ها یا انجام پرداخت از آن استفاده کنند. بسته به پلتفرم و شرایط حساب، اطلاعاتی مانند نام و نام خانوادگی واقعی، کشور محل اقامت، مدرک شناسایی معتبر، اطلاعات مالیاتی یا اطلاعات مرتبط با روش پرداخت ممکن است درخواست شود. نوع مدارک و زمان انجام Verification نیز می‌تواند بین پلتفرم‌ها متفاوت باشد.
موضوع مهم برای کاربران ایرانی تفاوت میان Platform Verification و Program Eligibility است. حتی اگر حساب یک Researcher در پلتفرم تأیید شود، ممکن است یک Bug Bounty Program مشخص محدودیت جغرافیایی یا Compliance جداگانه‌ای داشته باشد. به همین دلیل قوانین همان برنامه، Country Eligibility، شرایط پرداخت و Policy پلتفرم باید پیش از شروع Hunting بررسی شوند.
موضوع بعدی Payout Eligibility است. هدف فعالیت در یک برنامه دارای Bounty دریافت Reward پس از پذیرش گزارش است؛ به همین دلیل بررسی روش پرداخت باید قبل از صرف ساعت‌ها زمان روی Target انجام شود. ممکن است Researcher از نظر فنی امکان مشاهده یا بررسی یک برنامه را داشته باشد، اما هنگام پرداخت با الزامات دیگری مانند Identity Verification، اطلاعات پرداخت یا بررسی‌های Compliance مواجه شود.
شرایط پلتفرم‌های بین‌المللی نیز ثابت نیست. سیاست‌های KYC، کشورهای پشتیبانی‌شده، روش‌های پرداخت و محدودیت‌های هر Bug Bounty Program ممکن است در طول زمان تغییر کنند. به همین دلیل نمی‌توان یک فهرست قدیمی را مبنای قطعی قرار داد و گفت یک پلتفرم همیشه برای کاربران ایرانی قابل استفاده یا غیرقابل استفاده است. بررسی شرایط فعلی پلتفرم و برنامه در زمان فعالیت اهمیت بیشتری دارد.
استفاده از هویت جعلی، مدارک غیرواقعی یا اطلاعات نادرست درباره کشور محل اقامت نیز می‌تواند ریسک مسدود شدن حساب، رد شدن Verification یا ایجاد مشکل هنگام دریافت Bounty را افزایش دهد. برای فعالیت حرفه‌ای، اطلاعات هویتی و شرایط استفاده باید با قوانین جاری پلتفرم و برنامه موردنظر سازگار باشند.
یک Bug Bounty Hunter ایرانی بهتر است قبل از انتخاب Target چهار موضوع را جداگانه بررسی کند: امکان استفاده از پلتفرم، Eligibility برنامه، الزامات KYC و امکان دریافت Payout. این بررسی ساده می‌تواند مانع از شرایطی شود که Researcher یک Vulnerability ارزشمند پیدا کند اما بعداً متوجه شود برای دریافت پاداش با محدودیت مواجه است.
برای احراز هویت Bug Bounty نیاز به راهنمایی دارید؟
برای بررسی شرایط KYC و احراز هویت پلتفرم‌های Bug Bounty و دریافت مشاوره متناسب با پلتفرم موردنظر، با کارشناسان احرازچی در ارتباط باشید.
چگونه درآمد باگ بانتی را در ایران دریافت کنیم؟
دریافت درآمد Bug Bounty برای یک Researcher ایرانی می‌تواند به اندازه پیدا کردن خود Vulnerability اهمیت داشته باشد. زمانی که یک گزارش معتبر تأیید می‌شود و برنامه برای آن Bounty تعیین می‌کند، پرداخت پاداش بر اساس قوانین همان پلتفرم یا شرکت انجام خواهد شد. به همین دلیل بهتر است روش دریافت پاداش، الزامات KYC و محدودیت‌های جغرافیایی قبل از شروع Hunting بررسی شوند، نه زمانی که چندصد یا چند هزار دلار پاداش در حساب Researcher قرار گرفته است.
روش پرداخت در تمام سایت‌های باگ بانتی یکسان نیست. بسته به پلتفرم، کشور محل اقامت و سیاست برنامه، ممکن است گزینه‌هایی مانند انتقال بانکی یا سایر سرویس‌های پرداخت مورد تأیید پلتفرم ارائه شوند. در بعضی برنامه‌های حوزه Web3 نیز ساختار Reward می‌تواند متفاوت باشد. Researcher باید روش‌هایی را ملاک قرار دهد که در همان زمان به‌صورت رسمی در بخش Payment یا Payout حساب و قوانین برنامه نمایش داده می‌شوند، زیرا گزینه‌های پرداخت و کشورهای پشتیبانی‌شده ممکن است تغییر کنند.
برای کاربران داخل ایران، مهم‌ترین مسئله محدودیت دسترسی به بعضی زیرساخت‌های مالی بین‌المللی و الزامات Compliance است. ممکن است یک روش پرداخت در یک کشور قابل استفاده باشد اما برای کشور یا حساب دیگری ارائه نشود. حتی وجود یک گزینه در پلتفرم به‌تنهایی به معنی قابل استفاده بودن آن برای تمام Researcherها نیست و شرایط حساب، احراز هویت و کشور واجد شرایط نیز می‌تواند بررسی شود.
به همین دلیل باید سه مرحله تأیید گزارش، واجد شرایط بودن برای دریافت Reward و برداشت Payout از یکدیگر تفکیک شوند. معتبر شناخته شدن یک Vulnerability الزاماً تمام مراحل مالی را تکمیل نمی‌کند. ممکن است قبل از پرداخت اطلاعات هویتی، اطلاعات پرداخت یا سایر موارد موردنیاز پلتفرم درخواست شوند. شناخت این مراحل قبل از انتخاب Target می‌تواند از مشکلات بعدی جلوگیری کند.
نکته مهم دیگر، هزینه‌های جانبی دریافت درآمد است. مبلغ Bounty اعلام‌شده همیشه الزاماً برابر با مبلغی نیست که Researcher پس از فرایند انتقال و تبدیل ارز در اختیار خواهد داشت. کارمزد روش پرداخت، هزینه انتقال، نرخ تبدیل ارز و هزینه سرویس واسط قانونی ـ در صورتی که استفاده از آن طبق قوانین مربوطه مجاز باشد ـ می‌تواند مبلغ نهایی را تغییر دهد. برای پاداش‌های کوچک، همین هزینه‌ها ممکن است درصد قابل‌توجهی از درآمد را تشکیل دهند.
استفاده از اطلاعات هویتی غیرواقعی، حساب‌های اجاره‌ای یا روش‌هایی که برخلاف قوانین پلتفرم باشند می‌تواند ریسک مسدود شدن حساب یا ایجاد مشکل در دریافت Reward را افزایش دهد. اگر یک پلتفرم یا Bug Bounty Program برای کشور محل اقامت Researcher محدودیت مشخصی تعیین کرده است، بهتر است قبل از صرف زمان روی Target، Eligibility و شرایط رسمی آن بررسی شود.
برای یک Bug Bounty Hunter ایرانی، بهترین برنامه لزوماً برنامه‌ای نیست که بزرگ‌ترین عدد را در Reward Table نوشته باشد. برنامه‌ای ارزشمندتر است که علاوه بر تناسب با مهارت Researcher، Scope مناسب، قوانین روشن و مسیر پرداخت قابل استفاده و قانونی برای شرایط او داشته باشد. بررسی این موارد قبل از شروع می‌تواند بخشی از مدیریت حرفه‌ای درآمد در Bug Bounty باشد.
درآمد باگ بانتی در ایران؛ مسیری که با مهارت ساخته می‌شود
درآمد باگ بانتی در ایران می‌تواند یکی از مسیرهای کسب درآمد دلاری برای متخصصان امنیت سایبری باشد، اما نباید آن را یک روش سریع و تضمینی برای پول‌درآوردن تصور کرد. در Bug Bounty خبری از حقوق ثابت ماهانه نیست؛ درآمد زمانی ایجاد می‌شود که Researcher بتواند یک آسیب‌پذیری معتبر، داخل Scope و دارای Impact واقعی پیدا کند و گزارش آن نیز طبق قوانین برنامه پذیرفته شود.
مسیر یک Bug Bounty Hunter حرفه‌ای از یادگیری اصول Web Security، HTTP، API، Authentication و Access Control شروع می‌شود و با مهارت‌هایی مانند Recon، شناخت Attack Surface، تحلیل Business Logic، انتخاب Target مناسب و نوشتن گزارش حرفه‌ای ادامه پیدا می‌کند. هرچه این مهارت‌ها عمیق‌تر شوند، Researcher کمتر به جست‌وجوی تصادفی وابسته خواهد بود و می‌تواند زمان خود را روی قسمت‌هایی متمرکز کند که ارزش تحقیق بیشتری دارند.
میزان درآمد نیز به عوامل مختلفی بستگی دارد. Severity و Impact آسیب‌پذیری، Reward Table برنامه، کیفیت گزارش، Duplicate نبودن یافته و سیاست‌های همان پلتفرم می‌توانند مبلغ Bounty را تغییر دهند. به همین دلیل نمی‌توان برای درآمد باگ بانتی یک عدد ثابت تعیین کرد؛ ممکن است یک Hunter مدت زیادی پاداشی دریافت نکند و Researcher دیگری با پیدا کردن یک Vulnerability مهم، Bounty قابل‌توجهی به دست آورد.
برای کاربران ایرانی یک مرحله دیگر نیز اهمیت ویژه‌ای دارد: Eligibility، احراز هویت و روش دریافت پاداش. پیش از شروع فعالیت روی HackerOne، Bugcrowd، Intigriti، YesWeHack، Immunefi یا هر پلتفرم دیگری باید قوانین فعلی برنامه، محدودیت‌های جغرافیایی، شرایط KYC و روش‌های Payout بررسی شوند. امکان ایجاد حساب کاربری به‌تنهایی تضمین‌کننده امکان شرکت در تمام برنامه‌ها یا دریافت Reward نیست.
اگر قصد دارید Bug Bounty را جدی دنبال کنید، هدف اولیه خود را «درآمد چند هزار دلاری» قرار ندهید. رسیدن به اولین گزارش معتبر، یادگیری از Duplicate و Informative، ساختن Reputation و پیدا کردن حوزه تخصصی می‌تواند هدف واقع‌بینانه‌تری باشد. اولین Bounty شاید بزرگ نباشد، اما نشان می‌دهد توانسته‌اید دانش امنیت سایبری خود را به یک نتیجه واقعی تبدیل کنید.
Bug Bounty بیشتر از آنکه مسابقه اجرای ابزارها باشد، مسابقه درک بهتر سیستم‌هاست. Researcherی که بتواند رفتار یک محصول را دقیق‌تر تحلیل کند، نقاط کمتر دیده‌شده را بشناسد و Impact یک آسیب‌پذیری را به‌درستی اثبات کند، شانس بیشتری برای تبدیل مهارت امنیتی خود به درآمد خواهد داشت.
سوالات متداول
درآمد باگ بانتی ثابت نیست و به شدت آسیب‌پذیری، کیفیت گزارش، پلتفرم و Reward Table هر برنامه بستگی دارد. یک باگ ممکن است چند ده یا چند صد دلار پاداش داشته باشد، در حالی که آسیب‌پذیری‌های مهم‌تر می‌توانند چند هزار دلار یا بیشتر ارزش‌گذاری شوند.
از نظر مهارتی بله، اما کاربران ایرانی باید پیش از فعالیت، Country Eligibility، قوانین KYC و روش دریافت پاداش هر پلتفرم و برنامه را بررسی کنند. امکان ساخت حساب لزوماً به معنی امکان دریافت Bounty نیست.
HackerOne، Bugcrowd، Intigriti و YesWeHack از پلتفرم‌های شناخته‌شده هستند. در حوزه Web3 نیز Immunefi شناخته شده است. بهترین انتخاب به تخصص شما، نوع Target، میزان رقابت و شرایط دریافت پاداش بستگی دارد.
برای شروع لازم نیست برنامه‌نویس حرفه‌ای باشید، اما آشنایی با HTTP، وب، JavaScript، API، Authentication و Access Control بسیار مهم است. یادگیری برنامه‌نویسی نیز به مرور می‌تواند قدرت تحلیل شما را افزایش دهد.
زمان ثابتی وجود ندارد. دانش امنیتی، میزان تمرین، انتخاب Target و کیفیت Hunting تعیین‌کننده هستند. ممکن است یک Researcher نسبتاً سریع به اولین گزارش معتبر برسد و فرد دیگری برای رسیدن به همان مرحله به ماه‌ها تمرین نیاز داشته باشد.
بله، برخی Security Researcherها به‌صورت حرفه‌ای در این حوزه فعالیت می‌کنند؛ با این حال Bug Bounty معمولاً حقوق ثابت ماهانه ندارد و درآمد به تعداد و ارزش گزارش‌های پذیرفته‌شده وابسته است.
Duplicate زمانی اتفاق می‌افتد که همان آسیب‌پذیری یا Root Cause قبلاً توسط Researcher دیگری گزارش شده باشد. بررسی Attack Surfaceهای کمتر اشباع‌شده و توجه به قابلیت‌ها و Assetهای جدید می‌تواند احتمال Duplicate را کاهش دهد.
