Як написати Bug Bounty Report англійською мовою

Звіт про помилку з нагородою має одну мету: переконати команду безпеки, швидко і однозначно, що існує реальна вразливість і її слід виправити. Неясні, погано структуровані звіти отримують знижений пріоритет або відкидаються назад з прояснюючими питаннями - марнуючи час з обох сторін і іноді втрачаючи репортерів їх виплату повністю. Незалежно від того, надсилаєте ви повідомлення через HackerOne, Bugcrowd або приватну програму, англійська мова, якою ви користуєтеся, безпосередньо впливає на те, наскільки серйозно і швидко буде розглянуто ваше повідомлення.

Ключовий словник

** Доказ концепції (PoC) ** — мінімальна, відтворювана демонстрація того, що вразливість дійсно працює, а не просто теоретичний опис. “Я долучив скрипт, що демонструє введення SQL проти кінцевої точки /search за допомогою одного підробленого параметра.”

** Кроки відтворення ** — точна, пронумерована послідовність дій, необхідних для створення вразливості, написана так, щоб будь- хто міг виконати їх без вгадування. “Кроки відтворення: 1) увійти як звичайний користувач, 2) перейти до /account/export, 3) перехопити запит і змінити user_id на ідентифікатор іншого облікового запису, 4) спостерігати, що відповідь повертає приватні дані цього облікового запису.”

** Вплив ** — чітке твердження про те, що атакуючий може насправді досягти, уникаючи як недооцінки, так і перебільшення. “Вплив: будь-який автентифікований користувач може прочитати історію розрахунків будь-якого іншого користувача, змінивши один числовий параметр — додаткові привілеї не потрібні.”

** Серйозність ** — ваша оцінка того, наскільки серйозною є проблема, ідеально, якщо вона буде підтримана визнаною системою, наприклад, CVSS, а не лише суб’ єктивною міткою. “Заснований на векторі CVSS 3.1, який я обчислив, це оцінка 8.1 (Висока) - в основному через низьку складність атаки і вплив конфіденційності.”

** Сценарій атаки ** — короткий опис того, яким чином справжній злочинець реалізує проблему, що допомагає розробнику, який не очікував цього конкретного класу помилок. “У реалістичному сценарії атаки, зловмисний користувач міг би перерахувати послідовні ідентифікатори і витягнути дані розрахунків для всієї клієнтської бази за кілька хвилин.”

** Пропозиція щодо виправлення ** — додатковий, необов’ язковий рекомендований спосіб виправлення проблеми, який буде цінуватись розробниками, навіть якщо вони не використовуватимуть вашу конкретну пропозицію. “Як пропозиція щодо виправлення, перевірка того, що user_id у запиті відповідає автентифікованому сеансу, закриє цей конкретний вектор.”

Структурування звітності

• Заголовок: однією рядком резюме, що вказує клас вразливості і зачеплений кінцевий пункт — «Небезпечний прямий посилання на об’єкт (IDOR) в /account/export дозволяє крос-обліковий запис доступу до даних.»
• ** Резюме **: два-три речення, що дають оглядачу загальну картину, перш ніж вони прочитають подробиці.
• ** Кроки відтворення **: пронумеровані, конкретні і повні — припустимо, що читач не має попереднього контексту у цій кінцевій точці.
• ** Вплив **: що отримує нападник, ясно сказано без хеджування або роздування.
• ** Рекомендована тяжкість **: ваш бал за CVSS або еквівалентний йому, з поясненням причин.
• ** Доказові докази **: знімок екрана, журнали запитів/відповідей або коротке відео — долучайте, а не просто описуйте.

Поширені помилки

• ** Перебільшення впливу **: “Це може призвести до краху всієї компанії” для проблеми низької тяжкості шкодить вашій репутації для майбутніх звітів. Знайти відповідність мови з реальним, продемонстрованим впливом.
• ** Неясні кроки відтворення **: « Спробуйте змінити ідентифікатор, і все буде добре » змушує програму відтворення відтворити ваші дії, що затримує або зупиняє роботу звітної програми.
• ** Пропуск доказу концепції **: звіт, який лише теоретично описує вразливість, не демонструючи її, набагато частіше буде позначено як « інформаційний » (не підлягає нагороді), ніж як « підтверджений »
• ** Використання агресивної або звинувачувальної мови **: « Ваша команда безпеки явно не перевіряла це » закликає до оборонної відповіді, а не до швидкого виправлення — дотримуйтесь нейтральної, фактичної мови.

Відкривається зразок звіту

Title: IDOR у /account/export надає змогу будь-якому автентифікованому користувачеві звантажити історію розрахунків іншого користувача

• Нет, не надо ** Резюме **: Кінечна точка /account/export?user_id=X не перевіряє, чи відповідає сеанс запитуючого користувача параметру user_id. Зміна цього значення дозволить будь- якому розпізнаному користувачеві звантажити повний журнал розрахунків іншого облікового запису, зокрема суми рахунків і останні чотири цифри способу оплати.
• Нет, не надо ** Кроки для відтворення **: 1. Ввійти за будь- яким стандартним обліковим записом (обліковий запис A). 2. Надіслати запит GET на адресу /account/export?user_id=<Account A's ID> і зауважити, що відповідь буде містити ваші власні дані. 3. Змінити user_id на послідовний сусідній ідентифікатор (обліковий запис B). 4. Спостерігаємо, як відповідь повертає історію розрахунків рахунка B без жодних помилок авторизації.

Професійні поради

1. Відкривай резюме, а не історію дослідження. Триагери читають десятки звітів на день — дійте до суті в перших двох реченнях, перш ніж розповісти, як ви знайшли його.
2. ** Завжди долучайте докази, навіть для « очевидних » помилок. ** Знімок екрану або журнал запитів вилучають будь- які неоднозначності і значно прискорюють сортування.
3. ** Визначте чітко свої припущення. ** Якщо ваш тест залежав від певного рівня облікового запису або певного переглядача, скажіть про це — це збереже час, який витрачався на роз’ яснення питань.

Практичні вправи

1. Переписати цей неясний висновок у структурований звіт: « кінцева точка експорту витікає дані інших людей, якщо ви зміните ідентифікатор у адресі URL. »
2. Напишіть опис у двох реченнях вразливості у вигляді крос- сайтового скрипту (XSS), знайденої у публічній формі коментарів.
3. Створити ввічливе повідомлення з проханням про оновлення стану звіту, надісланого три тижні тому, на який не було отримано відповіді.

Зв’язані ресурси

• Як написати відповідне повідомлення про розголошення англійською мовою
• Як описати англійською мовою результати досліджень безпеки
• Архітектурний словник

Національний гімн: «Слово про свободу»

Погляньмо правді в очі - створення звіту про винагороду за помилку не просто про опис технічної проблеми. Це ефективне спілкування з командою, яка часто перебуває під величезним тиском, що має справу з потенційно критичним уразливостями. Як розробник, ваша мета полягає в тому, щоб ваш звіт був ясним, коротким і дієвим, а це означає розуміння того, як професійна англійська використовується в контекстах безпеки. Погано сформулований звіт може бути відхилений, затримуючи важливі зусилля по усуненню. І навпаки, добре структурований звіт демонструє професіоналізм, повагу до часу команди і справжнє бажання поліпшити стан безпеки.

Один з поширених сценаріїв включає отримання зворотнього зв’язку під час перегляду коду, пов’язаного з вразливістю, про яку ви повідомили. Уявіть це повідомлення Slack: «Щодо вашого звіту про помилку — добре, що ви визначили цю потенційну проблему з потоком автентифікації. Однак, в описі не вистачає деталей про точні кроки для відтворення вразливості і не чітко зазначено вплив. “Це не критика; це конструктивний зворотній зв’язок, наданий професійною мовою. Ключовим тут є усвідомлення того, що команди безпеки шукають подробиці – а не просто загальне твердження про те, що «щось погане трапилося». Краще було б відповісти: «Зрозуміло. Я додав детальну інформацію про кроки відтворення і кількісно оцінив потенційний вплив на основі [згадайте конкретний сценарій – наприклад, «неавтентифікований доступ до даних користувача»]. Я також включив скріншоти, що демонструють вразливість.” Зауважте зміну тону - визнання зворотнього зв’язку і негайно описуйте, як ви його вирішуєте.

Іншим критичним елементом є створення PR-описів, які чітко повідомляють про проблему. Замість того, щоб просто сказати «Потенційна вразливість X», кращим підходом було б: «Звітована вразливість — Потенціал для несанкціонованого доступу до даних профілю користувача через недостатню перевірку вводу на кінцевій точці /profile. Це може дозволити злочинцю ввести шкідливий код за допомогою [пояснити вектор введення]. Кроки для відтворення детально описані в долученому звіті і включають скріншоти, що демонструють експлойт. ” Ця фраза негайно встановлює серйозність проблеми – “потенціал для несанкціонованого доступу” – і надає контекст про те, чому це проблема (вектор введення). Він також направляє рецензента до повного звіту для отримання докладних відомостей. Використання точної термінології, наприклад, « перевірка введення », демонструє ваше розуміння принципів безпеки, збільшує довіру до команди, що переглядає.

Нарешті, пам’ятайте, що чіткість є найважливішою. Уникайте жаргонних або надто технічних слів, якщо це не абсолютно необхідно, і завжди визначайте їх, якщо ви це робите. Будь конкретним; замість «порушення в системі», описуй в точностях, що є порушенням і як його можна використати. Сформулюйте ваш звіт як спільну роботу — ви визначили проблему, тепер працюйте з командою, щоб ефективно її вирішити.