باگ هانتینگ Bug Bounty Hunting باگ هانتینگ چیست ؟ ( Bug Bounty Hunting )  باگ هانتینگ به آن معنی است که درخواست ایجاد بانتی از سوی سازمان ارئه نشده است و متخصص امنیتی ، هکر کلاه سفید ، باگ هانتر ( شکارچی باگ ) در صورتیکه یک باگ امنیتی در سامانه های تحت وب و موبایل سازمانهای خصوصی و استارتاپ های فعال در سطح مشاهده نماید، می تواند از طریق این پنل مخصوص پلتفرم قابل اطمینان هکر شواهد(POC) باگ را ثبت نماید. پلتفرم و مجموعه متخصص قابل اعتماد هکر شواهد تایید شده را به سازمان مورد نظر ارایه می نماید. در صورت موافقت سازمان، باگ ارزش گذاری می شود و پرداخت صورت می گیرد و معمولا مجموعه ای که هکر به آنها اعتماد کرده ( پلتفرم باگ هانتینگ )Bug Hunting کارمزدی را بابت برقراری ارتباط ، مذاکره با سازمان از مبلغ جایزه نهایی کم می کند . بازه این کارمزد از پاداش 10 تا 20 درصد بستگی به توافق متغیر است . نکات مهم برای روش باگ بانتی: ابتدا به دقت بخش قوانین و سیاست ها ( policy ) و محدوده ها ( Scope ) بخوانید. هک های اجتماعی، فیشینگ،‌ DDoS و حملاتی از این قبیل جزو برنامه باگ بانتی نیست. به لیست و پاداش های در نظر گرفته آسیب پذیری ها دقت کنید که سر تون کلاه نره الکی چیزی تست نکنید. سعی کنید Subdomains ها را شکار کنید ! ساب دامنه ها و کشف آنها همیشه در اولویت قرار دهید. همیشه CMS و زبان برنامه نویسی Back-end را با ابزار هایی مثل Builtwith ، Wappalyzer کشف کنید. گوگل دورک ( Google Dorks) خیلی خیلی می توانند مفید باشند. هر درخواست ( request ) و پاسخ ( response ) را در زمان اسکن به دقت بررسی و حالت های مختلف تست کنید. خلاق باشید و خارج از چارچوب فکر کنید. قوانین عمومی اکثر مسابقات باگ بانتی و امنیت : تست نفوذ مهندسی اجتماعی، فیشینگ،‌ DDoS و حملاتی از این قبیل جزو برنامه باگ بانتی نیست. در صورتی که فعالیت شما باعث اخلال در خدمات کارفرما شود،‌ فعالیت خود را متوقف کرده و کارفرما را در جریان قرار دهید. اطلاعات استخراج شده از سایت یا سرویس کارفرما باید در کمترین میزان ممکن باشد، به عنوان مثال هنگام تزریق دیتابیس ردیف های محدودی را دریافت کنید. در صورت کشف باگ، سریعا آن را برای بررسی ارسال کنید و از استخراج اطلاعات اضافه پرهیز کنید. گزارش باگ باید شامل مراحل بازتولید باگ به صورت کاملا شفاف باشد. تمام گزارش و اطلاعات مربوط به باگ های کشف شده باید از طریق پلتفرم باگ بانتی آپلود شود. از انتشار آن خارج این پلتفرم باگ بانتی جدا خودداری کنید. پاداش به اولین نفری که آسیب‌پذیری را گزارش کند تعلق می‌گیرد. برای انتشار آسیب پذیری سازمان و مجموعه ها حتما از آنها اجازه نامه دریافت کنید ، و اطمینان پیدا کنید آسیب پذیری رفع شده باشد ، زمان مناسب معمولا 30 روز پس از تایید آسیب پذیری است که بخواهید اقدام به انتشار عمومی آن در یوتیوب یا توییتر کنید آسيب‌پذيری‌ها‌ی غير قابل قبول: آسيب‌پذير‌ی‌های زير پذيرفته نمی‌شوند: حملات از كار اندازی سرويس (DoS) حملات مهندسی اجتماعی و Phishing آسيب‌پذيری در دامنه‌ها و آدرس‌های IP غير از آدرس هدف Best Practice ها، شامل حداقل طول كلمات عبور و نظایر آن آسیب‌پذیری‌ها و Best Practice های مربوط به SSL حمله Brute Force آسیب‌پذیری‌هایی که به تعامل با کاربر نیاز است آسیب‌پذیری‌های مربوط به مرورگرهای قدیمی نامه‌نگاری الکترونیکی جعلی (E-mail spoofing) حمله Self XSS هر موردی که مربوط به بدست آوردن نام‌های کاربری (Account/e-mail enumeration) باشد آسیب‌پذیری‌هایی که قبلاً توسط سایر متخصصین گزارش شده است آسیب‌پذیری‌های گزارش‌شده توسط اسکنرها و سایر ابزارهای اتوماتیک گزارش پایین‌بودن ورژن کتابخانه‌ها و نرم‌افزارهای به کار رفته در صورت عدم بهره‌برداری آسیب‌پذیری‌های مربوط به نشت اطلاعات سرور و پیکربندی نادرست آن مثل نسخه و نوع وب سرور

باگ بانتی و باگ هانتینگ Bug Bounty And Bug Bounty Hunting در این قسمت از آموزش قصد داریم شما را با باگ بانتی Bug Bounty و باگ هانتینگ Bug Bounty Hunting آشنا کنیم با ما همراه باشید . باگ بانتی چیست؟ ( Bug Bounty ) باگ بانتی ( Bug Bounty ) یا مسابقات کشف باگ و آسیب پذیری، برنامه‌هایی هستنتد که طی آن‌ها یک وب‌سایت یا اپلیکیشن و حتی سخت افزار، سازمان یا توسعه‌دهنده برای کشف باگ‌های سرویس خود، به خصوص رخنه‌ها و باگ‌های امنتی،‌ به افراد و هکرها پاداش و جایزه می‌دهد. هدف از این برنامه، کشف آسیب‌پذیری‌های امنیتی قبل از انتشار عمومی آن‌ها است. پاداش این مسابقات می‌تواند به صورت نقدی یا به رسمیت شناختن متخصصین این زمینه یا هر دو باشد. باگ هانتینگ چیست ؟ ( Bug Bounty Hunting ) باگ هانتینگ به آن معنی است که درخواست ایجاد بانتی از سوی سازمان ارئه نشده است و متخصص امنیتی ، هکر کلاه سفید ، باگ هانتر ( شکارچی باگ ) در صورتیکه یک باگ امنیتی در سامانه های تحت وب و موبایل سازمانهای خصوصی و استارتاپ های فعال در سطح مشاهده نماید، می تواند از طریق این پنل مخصوص پلتفرم قابل اطمینان هکر شواهد(POC) باگ را ثبت نماید. پلتفرم و مجموعه متخصص قابل اعتماد هکر شواهد تایید شده را به سازمان مورد نظر ارایه می نماید. در صورت موافقت سازمان، باگ ارزش گذاری می شود و پرداخت صورت می گیرد و معمولا مجموعه ای که هکر به آنها اعتماد کرده ( پلتفرم باگ هانتینگ )Bug Hunting کارمزدی را بابت برقراری ارتباط ، مذاکره با سازمان از مبلغ جایزه نهایی کم می کند . بازه این کارمزد از پاداش 10 تا 20 درصد بستگی به توافق متغیر است . نکات مهم برای روش باگ بانتی: ابتدا به دقت بخش قوانین و سیاست ها ( policy ) و محدوده ها ( Scope ) بخوانید. هک های اجتماعی، فیشینگ،‌ DDoS و حملاتی از این قبیل جزو برنامه باگ بانتی نیست. به لیست و پاداش های در نظر گرفته آسیب پذیری ها دقت کنید که سر تون کلاه نره الکی چیزی تست نکنید. سعی کنید Subdomains ها را شکار کنید ! ساب دامنه ها و کشف آنها همیشه در اولویت قرار دهید. همیشه CMS و زبان برنامه نویسی Back-end را با ابزار هایی مثل Builtwith ، Wappalyzer کشف کنید. گوگل دورک ( Google Dorks) خیلی خیلی می توانند مفید باشند. هر درخواست ( request ) و پاسخ ( response ) را در زمان اسکن به دقت بررسی و حالت های مختلف تست کنید. خلاق باشید و خارج از چارچوب فکر کنید. قوانین عمومی اکثر مسابقات باگ بانتی و امنیت : تست نفوذ مهندسی اجتماعی، فیشینگ،‌ DDoS و حملاتی از این قبیل جزو برنامه باگ بانتی نیست. در صورتی که فعالیت شما باعث اخلال در خدمات کارفرما شود،‌ فعالیت خود را متوقف کرده و کارفرما را در جریان قرار دهید. اطلاعات استخراج شده از سایت یا سرویس کارفرما باید در کمترین میزان ممکن باشد، به عنوان مثال هنگام تزریق دیتابیس ردیف های محدودی را دریافت کنید. در صورت کشف باگ، سریعا آن را برای بررسی ارسال کنید و از استخراج اطلاعات اضافه پرهیز کنید. گزارش باگ باید شامل مراحل بازتولید باگ به صورت کاملا شفاف باشد. تمام گزارش و اطلاعات مربوط به باگ های کشف شده باید از طریق پلتفرم باگ بانتی آپلود شود. از انتشار آن خارج این پلتفرم باگ بانتی جدا خودداری کنید. پاداش به اولین نفری که آسیب‌پذیری را گزارش کند تعلق می‌گیرد. برای انتشار آسیب پذیری سازمان و مجموعه ها حتما از آنها اجازه نامه دریافت کنید ، و اطمینان پیدا کنید آسیب پذیری رفع شده باشد ، زمان مناسب معمولا 30 روز پس از تایید آسیب پذیری است که بخواهید اقدام به انتشار عمومی آن در یوتیوب یا توییتر کنید آسيب‌پذيری‌ها‌ی غير قابل قبول: آسيب‌پذير‌ی‌های زير پذيرفته نمی‌شوند: حملات از كار اندازی سرويس (DoS) حملات مهندسی اجتماعی و Phishing آسيب‌پذيری در دامنه‌ها و آدرس‌های IP غير از آدرس هدف Best Practice ها، شامل حداقل طول كلمات عبور و نظایر آن آسیب‌پذیری‌ها و Best Practiceهای مربوط به SSL حمله Brute Force آسیب‌پذیری‌هایی که به تعامل با کاربر نیاز است آسیب‌پذیری‌های مربوط به مرورگرهای قدیمی نامه‌نگاری الکترونیکی جعلی (E-mail spoofing) حمله Self XSS هر موردی که مربوط به بدست آوردن نام‌های کاربری (Account/e-mail enumeration) باشد آسیب‌پذیری‌هایی که قبلاً توسط سایر متخصصین گزارش شده است آسیب‌پذیری‌های گزارش‌شده توسط اسکنرها و سایر ابزارهای اتوماتیک گزارش پایین‌بودن ورژن کتابخانه‌ها و نرم‌افزارهای به کار رفته در صورت عدم بهره‌برداری آسیب‌پذیری‌های مربوط به نشت اطلاعات سرور و پیکربندی نادرست آن مثل نسخه و نوع وب سرور