سه اصل مرتبط با دوپلیکیت ها در باگ بانتی

مقدمه ای دربارۀ دوپلیکیت ها در باگ بانتی

یک دوپلیکیت (در دنیای باگ بانتی)، گزارشی است برای یک مشکل که قبلاً معروف بوده یا شناسایی شده است. با این حال، هنگام تصمیم گیری در مورد این که آیا یافتۀ مربوطه واقعاً دوپلیکیت است یا خیر، راه حل همیشه از قبل معلوم و قابل پیش بینی نیست. بسیاری از موقعیت ها به مقدار قابل توجهی از جزئیات و محتوا نیاز دارند. به منظور ساده تر کردن ارزیابی دوپلیکیت در چنین مواردی، یک راهنما برای تعدادی از سناریوهای رایج دوپلیکیت آماده کرده ایم که در آن ها توضیح می دهیم نگاه Bugcrowd نسبت به این موقعیت ها چگونه است و چگونه به مشتریان توصیه می کنیم با آنها برخورد کنند. با بررسی این سناریوها، سه اصل کلی را می بایست در نظر بگیریم:

  • کد را دستکاری کنید (تغییری ایجاد کنید)، پاداش آسیب پذیری را بدست بیاورید.
  • اگر یافته ای شما را وادار کند تا تغییری ایجاد نمایید، در اسکوپ باشد و جزء آسیب پذیری های مورد قبول برنامه باشد، باید در ازای آن پاداش پرداخت گردد.
  • مشابه != یکسان 
  • اگر یافته ای مشابه یافتۀ دیگری بوده، اما نیاز به تغییرات مجزایی داشته باشد، باید آن را به عنوان مشکلی منحصر به فرد در نظر گرفته و پاداش آن به شکلی مستقل پرداخت گردد.
  • زیاد =! وابسته به سیستم
  • تنها به دلیل این که تعداد زیادی از یک نوع آسیب پذیری خاص وجود دارد، به این معنی نیست که همۀ آن ها بخشی از یک مشکل ریشه ای یکسان هستند.

اهمیت محتوا و تفاوت های جزئی در ارزیابی دوپلیکیت

به عنوان یک نکتۀ سریع می بایست بگوییم که تریاژ مهندسی شدۀ Bugcrowd، همۀ موارد فوق را هنگام تریاژ یافته ها مدنظر قرار می دهد (نهایت سعی خود را در این زمینه انجام می دهیم، چرا که شرایط خاصی وجود دارند که ما برخی اوقات دیدی نسبت به آن ها نداریم). ما از سیستم تشخیص ضد دوپلیکیت مبتنی بر یادگیری ماشین، هوش زمینه ای نشات گرفته از داده هایی با ارزش بیش از یک دهه در مورد آسیب پذیری ها و اعتبارسنجی انسانی بهره می گیریم تا مرور کاملی بر تمامی یافته هایی که وارد این پلتفرم می شوند داشته باشیم. این کار با اهداف زیر انجام می شود:

  1. اطمینان از این که تمامی یافته ها به شکلی صحیح شناسایی می شوند.
  2. تمامی موارد منحصر به فرد برای بررسی توسط مشتری ارتقا داده می شوند.

سناریوی شماره یک: چندین آسیب پذیری SQLi

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

این رویکرد اشتباه است؛ چرا که آسیب پذیری های متعدد از یک کلاس آسیب پذیری یکسان به این معنی نیست که همۀ آن ها آسیب پذیری یکسانی هستند. مشاهدۀ تعداد زیادی از یک نوع کلاس آسیب پذیری یکسان بر روی یک دارایی خاص، امر نسبتاً رایجی است – هنگامی که یک یا دو مورد از یک نوع آسیب پذیری در یک اپلیکیشن یافته شود، معمولاً تعداد بیشتری از آنها نیز وجود دارد. علت این امر ممکن است آن باشد که توسعه دهندگان یکسان، اشتباه(های) مشابهی را در بخش های مختلف در سطح حمله انجام می دهند. همانند پرندگان که در آن ها، کرک‌های یک پر معمولاً با هم جمع می‌شوند.

دسترسی به خوشه های آسیب پذیری و تعیین دوپلیکیت های واقعی

در چنین موقعیت هایی، درک این موضوع مهم است که اگر چه تعداد زیادی از یک نوع آسیب پذیری یکسان وجود دارد، این آسیب پذیری ها در قالب های متعدد در سراسر برنامه پخش شده اند. این بدان معنی است که بسیار بعید به نظر می رسید که تمامی این آسیب پذیری ها یک راه حل مشترک داشته باشند.

برخی از آن ها ممکن است دوپلیکیت های واقعی باشند. اگر با رفع یکی از این آسیب پذیری ها، دیگر نیازی به رفع سایر موارد نباشد، در این صورت به قانون شمارۀ یک مراجعه کنید: «کد را لمس کنید / تغییر ایجاد کنید، پاداش آسیب پذیری را پرداخت کنید». در صورتی که در نتیجۀ رفع یک آسیب پذیری، دیگر نیازی به لمس کد یا ایجاد تغییر برای رفع آسیب پذیری دیگری نباشد، در این صورت یافتۀ دوم به راستی تکراری بوده و دوپلیکیت یافتۀ اول محسوب می گردد.

تضمین شناخت و پاداش منصفانه برای یافته های منحصر به فرد

با این حال، این امر ضروری است که ما تنها چیزی را به عنوان دوپلیکیت علامت گذاری کنیم که واقعاً تکراری و دوپلیکیت باشد (برای مثال حالتی را در نظر بگیرید که برطرف نمودن یافتۀ والد، نیاز به برطرف کردن یافته های تکراری را از بین ببرد). در صورتی که ده آسیب پذیری SQLi در سراسر اپلیکیشن پراکنده شده باشد، اگر بخواهیم تنها یکی از این یافته ها را پاداش داده و بقیۀ موارد را دور بزنیم، معادل این گفته است که در پاسخ به این موارد، تنها یک تغییر در پایگاه کد ایجاد شده است. در صورتی که صادقانه به این وضعیت نگاه کنیم، اگر محقق فقط یکی از ده مشکل SQLi را گزارش کرده بود و آن مشکل برطرف می شد، احتمالاً حتی پس از برطرف کردن اولین آسیب پذیری نیز حداقل 9 آسیب پذیری دیگر در بخش های مختلف اپلیکیشن وجود داشت – چرا که هر کدام به یک روش رفع منحصر به فرد نیاز دارد. ممکن است وسوسه انگیز باشد که ادعا کنیم تمامی این آسیب پذیری ها یکسان هستند، اما در عمل به ندرت چنین حالتی پیش می آید.

نکاتی که باید به خاطر بسپارید

در بعضی موارد، برخی ممکن است ادعا کنند که اجرای یک WAF (یا یک قانون و رول WAF) می تواند به عنوان تنها «روش رفع» محسوب گردد. برای مثال، می توان یک قانون WAF پیاده سازی نمود که هر گونه تزریق کوتیشن دوتایی را (که برای آسیب پذیری SQLi موردنیاز است)، مسدود نماید. با انجام این کار، دیگر تمام مشکلات SQLi مورد سوء استفاده قرار نگرفته و در نتیجه مشکل «رفع» می گردد. هر چند که از دیدگاه Bugcrowd، به یافته ها باید از منظر نحوه اصلاح آن ها در پایگاه کد زیربنایی (و نه در لایه (WAF پاداش تعلق گیرد. افزودن یک رول WAF یا هر مکانیزم مسدودسازی مشابهی، یک روش نصف و نیمه است که همواره در آینده حفره ای در خود داشته و در لایه های زیرین، اپلیکیشنی را که هنوز آسیب پذیر است در معرض خطر قرار می دهد. محققان مکانیزم های خلاقانه و روش های متعددی برای دور زدن WAF و سر و کله زدن با این کنترل ها پیدا کرده اند و از این رو:

  1. هر گونه اصلاح و برطرف سازی همواره می بایست در لایۀ اپلیکیشن آغاز گردد.
  2. پاداش ها می بایست بر اساس اصلاح های صورت پذیرفته در پایگاه کد مدیریت شوند نه بر اساس WAF

 

سناریوی شماره دو: آسیب پذیری های Reflected XSS با پارامترهای مشترک

  • یک محقق، 15 آسیب پذیری cross site scripting (XSS) را در تعدادی از صفحات اپلیکیشن شما شناسایی می کند هرچند که این آسیب پذیری ها معمولاً به یکی از این سه پارامتر ختم می شوند: “page=” و “id=”  و “utm=”. با توجه به این که آن ها روی صفحات منحصر به فردی هستند (برای مثال /view، /news و…) و ما قبلاً در مورد اهمیت پرداخت برای تمامی موارد منحصر به فرد صحبت کردیم، شما تصمیم می گیرید برای هر یافته به طور مستقل هزینه کنید.

این گفته تا حدودی درست و تا حدودی نادرست است. از آن جهت درست است که با توجه به اینکه به نظر می رسد این مسائل از سه پارامتر منحصر به فرد سرچشمه می گیرند، ما می خواهیم و نیاز داریم که به تمامی یافته های منحصر به فرد پاداش دهیم. در این جا معمول ترین نتیجه این است که سه یافتۀ منحصر به فرد وجود داشته باشد (یک عدد به ازای هر پارامتر آسیب پذیر)، و بقیه موارد به عنوان دوپلیکیت مورد اولیه برای هر پارامتر علامت گذاری گردد.

درک کردن دوپلیکیت ها در سناریوهای آسیب پذیری چند پارامتری

اما همیشه این مسئله صادق نیست. گاهی اوقات ممکن است یک نام پارامتر یکسان توسط صفحات مختلف به طور متفاوتی مدیریت شود – این مسئله را می توان با بررسی این که تزریق در کجای صفحه اتفاق می افتد و این که آیا برای همۀ پارامترها این محل یکسان است یا خیر ارزیابی نمود. اگر این حالت پیش آمده باشد، به این معنی است که علی رغم ظاهر شدن مشکل مربوطه در URLهای مختلف، یک مورد/تابع زیربنایی یکسان روی صفحات مختلف اعمال شده است. در چنین حالاتی، رفع مشکل تابع زیربنایی، مشکل را در هر صفحه ای که تابع مذکور در آن فراخوانی شده است برطرف می نماید، و از این رو Bugcrowd به طور اتوماتیک هر یافتۀ اولیه را به ازای هر پارامتر، منحصر به فرد علامت گذاری کرده و سپس تمامی موارد بعدی برای این پارامترها به عنوان دوپلیکیت علامت گذاری می نماید.

نکاتی که باید به خاطر بسپارید

شایان ذکر است که در بسیاری از موارد، در صورتی که پارامترهای متعدد، در عمل بخشی از یک مشکل باشند، به عنوان دوپلیکیت پارامترهای دیگر در یک صفحۀ مشترک یا چند صفحه خواهند بود. مثالی خوب از این موضوع مربوط به زمانی است که url صفحه در محتوای صفحه پرینت می شود. در چنین مواردی، url می تواند 30 پارامتر داشته باشد، یا حتی یک پارامتر جعلی اضافه شده به آن، که همه از طریق همان تابع backend در صفحه منعکس شوند – که در این صورت نیز برای برطرف شدن مشکل فقط به یک اصلاح نیاز خواهد داشت و در نتیجه فرد گزارش دهنده در ازای همۀ پارامترها و صفحاتی که آن مشکل را داشته باشند، فقط سزاوار دریافت یک پاداش خواهد بود.

در انجام این کار، ما به اصولی که قبلاً در موردش صحبت کردیم پایبندیم: پرداخت پاداش برای تمامی جاهایی که در آن کد تغییر یافته است (یک بار به ازای هر تابع اساسی که به ازای هر پارامتر اصلاح خواهد شد) و همچنین به یاد داشته باشید که «مشابه =! یکسان» (مشابه بودن به معنی یکسان بودن نیست).

 

سناریوی شماره 3: یافته های CSRF در صفحات/اندپوینت های متعدد

  • به علت نبود توکن anti-CSRF در هیچ بخشی از اپلیکیشن، یک محقق 50 یافتۀ cross site request forgery (CSRF / XSRF) را به ازای هر صفحه/اندپوینت موجود در اپلیکیشن سابمیت می کند. با توجه به این که محقق مربوطه 50 نقطۀ مشکل دار را شناسایی کرده، آیا باید به ازای تمامی این 50 مورد پاداش دریافت کند؟

اینجاست که اصل سوم ما در رابطه با دوپلیکیت ها مطرح می شود: «زیاد =! سیستمیک». همانطور که در مثال اول و دوم مشاهده کردیم، وجود تعداد زیادی مشکل از یک کلاس آسیب پذیری خاص به این معنی نیست که این مورد به طور خودکار سیستمی بوده و یا باید به عنوان فقط یک یافته خلاصه گردد. با این حال، در خصوص برخی کلاس های آسیب پذیری، ممکن است مشکلات سیستمی وجود داشته باشد – آسیب پذیری CSRF مثالی بارز از همین موضوع است.

شفاف سازی آسیب پذیری های سیستمی و تاثیر آن ها بر پرداخت ها

اگر اپلیکیشنی 50 بخش مختلف داشت که در 45 بخش از آن ها، دارای محافظت anti-CSRF بوده و فقط در 5 بخش دیگر فاقد این محافظت باشد، در این صورت هر نمونه از عدم وجود محافظت CSRF، یک نمونۀ منحصر به فرد محسوب می گردد. این بدان معنی است که محافظت در مقابل این آسیب پذیری در این اپلیکیشن موجود بوده، ولی بر روی این اندپوینت های به خصوص اعمال نشده است. با این حال از آنجایی که در مثال ما در هیچ بخش از برنامه، محافظت anti-CSRF وجود نداشت، این امکان وجود دارد که به محض فعال کردن این نوع محافظت (به ویژه در فریم ورک های مدرن)، به طور اتوماتیک بر روی تمامی صفحات/اندپوینت های اپلیکیشن اعمال شده و تنها با یک تغییر در کد، تمامی مشکلات رفع گردد. قضیه همیشه این گونه نیست، ولی این مسئله بسیار رایج است (به خصوص در مورد CSRF). در چنین مواقعی، ما مورد مربوطه را به عنوان «سیستمی» نشانه گذاری می کنیم، به اولین گزارش پاداش داده و گزارش های بعدی را به عنوان دوپلیکیت علامت گذاری می کنیم.

نکاتی که می بایست به خاطر بسپارید

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

به عنوان مثال دیگری از موارد سیستمی می توان به زیردامنه هایی اشاره داشت که در آن ها توازن بار انجام گرفته یا به یک هاست یکسان ریزالو می شوند. اینجاست که گزارش یکی از این موارد، به طور اتوماتیک بر همۀ ساب دامین های دیگری که پایگاه کد، هاست و… مشترکی دارند، قابل اعمال است. البته موارد گفته شده، یک فهرست جامع نیست – فقط چند نمونه از این مسئله است که چگونه / کجا آسیب‌پذیری ها می‌توانند سیستمی باشند.

پیمایش دوپلیکیت ها با اطمینان

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

  • کد را دستکاری کنید (یا تغییری ایجاد نمایید)، پاداش آسیب پذیری را دریافت کنید.
  • مشابه =! یکسان (مشابه بودن به معنی یکسان بودن نیست)
  • زیاد =! وابسته به سیستم(زیاد بودن یک مورد به معنی سیستمی بودن نیست)

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

در نهایت، فارغ از هر چیزی همیشه به یاد داشته باشید، یافتۀ مربوطه چه موجب به روزرسانی اسناد باشد چه پایگاه کد، «کد را دستکاری کرده یا تغییری ایجاد کردید، پاداش آسیب پذیری را دریافت کنید».

موفق باشید و هانت خوبی داشته باشید.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *