آن‌چه می‌خوانید نوشته‌ی رامین فرج‌پور، برنامه‌نویس و محقّق امنیتی، ست.

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

یکی از مشکلات رایجی که منجر به رد گزارش‌های آسیب پذیری می‌شود، عدم ذکر سناریوی مناسب و کافی در گزارش آسیب پذیری ست. در این بلاگ‌پست می‌خواهیم به بررسی نمونه‌ای در خصوص اهمیت "سناریو" بپردازیم؛ دو گزارش آسیب پذیری که به یک آسیب پذیری واحد برروی یک هدف در پلتفرم باگ بانتی راورو اشاره کرده‌اند و با فاصله‌ی زمانی برروی هدف یک میدان ثبت شده‌اند، اما نتیجه‌ی متفاوتی نصیب هرکدامشان شده است... .

آن‌چه در این بلاگ‌پست خواهید خواند:

• سناریو چیست؟

• اصل مطلب؛ دو گزارش آسیب پذیری ثبت‌شده از یک آسیب پذیری برروی یک هدف

• چه شد؟ چرا این‌طور شد؟

• از داور راورو به شما نصیحت

سناریو چیست؟

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

اصل مطلب:

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

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

توجه شما را به این دو گزارش جلب می‌کنیم:

گزارش اول

تاریخ ثبت: بهمن ۱۴۰۰

وضعیت: ردشده توسط میدان

متن گزارش آسیب‌پذیری:

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

عکس برای اثبات پیوست گردید.

ممنون.

پاسخ میدان:

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

گزارش دوم

تاریخ ثبت: تیر ۱۴۰۱

سرانجام: پذیرفته‌شده توسط میدان

بانتی اختصاص‌یافته: ۵ میلیون تومان

متن گزارش آسیب پذیری:

در قسمت مدیریت سایت این امکان وجود دارد که با تغییر سطح دسترسی‌ای که برای هر کاربر تعیین می‌شود، تمامی اطلاعات کاربران توسط کاربر عادی دیگر قابل‌مشاهده است. و در این‌جا مدیریت سطح دسترسی در سمت سرور به درستی انجام نشده است. این مشکل، این امکان را برای مهاجم فراهم می‌آورد که با در دست داشتن ایمیل کاربران از سایت شما ( که شناسایی این ایمیل در دیگر قسمت سایت شما قابل بهره‌برداری ست و در ویدئو چگونگی این موضوع نشان داده شده است.) علاوه‌بر اطلاعات کاربر که شامل نام، نام خانوادگی، آدرس ایمیل و شماره همراه می‌شود، یک city id هم در این قسمت وجود دارد که ID شهر کاربر برمی‌گردد. در این‌جا مهاجم می‌تواند با بررسی بیشتر در یک API دیگری با ارسال این ID، به آدرس دقیق همه‌ی کاربران دسترسی یابد.

سناریو:

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

ویدئو برای این گزارش ارسال شد.

پاسخ میدان:

سلام. ممنون بابت وقتی که گذاشتید. گزارش شما مورد تایید است.

چه شد؟ چرا این‌طور شد؟

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

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

از داور راورو به شما نصیحت

کاظم فلاحی، هم‌بنیان‌گذار راورو و عضو سابق تیم داوری راورو، می‌گوید:

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

هم‌چنین تجربه نشان می‌دهد که هرچه سناریوی بهتری ارائه دهید، کم‌تر ممکن است پاسخ " این باگ نیست، فیچر است" را از میدان بشنوید! چراکه با توضیح سناریو، میدان به‌طور دقیق‌تری متوجه مسئله و جنبه‌ی امنیتی آن می‌شود.

سخن آخر:

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

بلاگ‌پست‌های مرتبط:

چگونه یک گزارش آسیب‌پذیری بنویسیم؟

چرا باید حتما قبل از شکار آسیب پذیری، قوانین هدف را بخوانیم؟

از باگ تا بانتی؛ ۴ مرحله‌ای که هر گزارش آسیب‌پذیری در راورو طی می‌کند