Pisanie świetnych raportów

Znalezienie błędu to dopiero połowa pracy. To raport jest właściwym rezultatem, który Państwo dostarczają, i to on decyduje o wysokości nagrody. Świetna podatność opisana w słabym raporcie może otrzymać niższą ocenę lub zostać odrzucona.

• Weryfikatorzy analizują codziennie dziesiątki raportów
• Jasny i możliwy do odtworzenia raport oszczędza ich czas i buduje dobrą opinię
• Lepsze raporty otrzymują wyższe oceny wagi i szybciej prowadzą do wypłaty

Traktować pisanie raportów jako podstawową umiejętność, a nie czynność wykonywaną na końcu.

Dobry raport ma przewidywalną strukturę, którą weryfikator może szybko przejrzeć:

• Tytuł — typ podatności + dotknięty zasób + wpływ
• Podsumowanie — jedno lub dwa zdania
• Kroki odtworzenia — ponumerowane i dokładne
• Wpływ — co zyskuje atakujący
• Dowód koncepcji — żądania, zrzuty ekranu, nagranie
• Naprawa — jak usunąć problem

Tytuł jest pierwszym wrażeniem. Należy zadbać o jego konkretność i wskazanie wpływu, zamiast używać ogólników.

Dobry tytuł zawiera typ błędu, jego lokalizację oraz konsekwencję.

Najważniejszą sekcją są kroki odtworzenia. Weryfikator musi móc dokładnie je wykonać i zobaczyć błąd. Należy zachować precyzję.

Każdy krok powinien być ponumerowany oraz zawierać dokładne adresy URL, payloady i oczekiwane oraz rzeczywiste wyniki.

Waga, a tym samym wysokość nagrody, zależy od wpływu. Należy konkretnie opisać, co może osiągnąć atakujący.

• Czyje dane są ujawnione i w jakim zakresie?
• Czy może to prowadzić do przejęcia konta, RCE lub strat finansowych?
• Czy wymagane jest uwierzytelnienie? Czy istnieją warunki wstępne?

Należy podawać liczby: „każdy użytkownik może odczytać wszystkie 200 tys. faktur, iterując identyfikatory” jest znacznie mocniejsze niż „wyciek danych”.

PoC usuwa wszelkie wątpliwości. Należy dołączyć surowe żądania i odpowiedzi oraz dowody wizualne.

• Pełne żądanie i odpowiedź HTTP (należy zamazać własne sekrety)
• Zrzuty ekranu pokazujące rezultat
• Krótkie nagranie w przypadku złożonych, wieloetapowych błędów

W przypadku błędów możliwych do zautomatyzowania minimalny skrypt ułatwia weryfikatorowi odtworzenie problemu.

Wiele programów używa CVSS do przypisywania wagi. Zrozumienie wektora pomaga uzasadnić ocenę i uniknąć sporów.

• Wektor ataku, złożoność, wymagane uprawnienia, interakcja użytkownika
• Wpływ na poufność, integralność i dostępność

Należy zaproponować wynik CVSS wraz z uzasadnieniem, ale pozwolić, by przemawiały dowody, a nie zawyżone liczby.

Dołączenie zalecenia dotyczącego naprawy świadczy o profesjonalizmie i pomaga zespołowi szybko zareagować. Sposób naprawy należy powiązać z przyczyną źródłową.

• IDOR: egzekwować autoryzację na poziomie obiektu (sprawdzać własność po stronie serwera)
• XSS: kodować dane wyjściowe zależnie od kontekstu i stosować restrykcyjną CSP
• SSRF: stosować allowlistę hostów wychodzących i blokować adresy IP link-local/prywatne

Konkretne zalecenia dotyczące naprawy budują zaufanie i reputację.

Dwie rzeczy obniżają wartość zgłoszeń: duplikaty i fałszywe alarmy.

• Najpierw przeszukać znane problemy programu i własne wcześniejsze raporty
• Przed zgłoszeniem potwierdzić, że błąd działa niezawodnie
• Nie zgłaszać ustaleń informacyjnych wykluczonych przez zasady

Jeden dobrze udokumentowany, prawidłowy raport jest więcej wart niż dziesięć spekulatywnych.

Po wysłaniu raportu ważna jest profesjonalna komunikacja.

• Niezwłocznie odpowiadać na prośby o wyjaśnienia
• Zachować uprzejmość nawet w razie niezgody co do wagi; przedstawiać argumenty poparte dowodami
• Nie wysyłać spamu ani nie żądać szybszego rozpatrzenia

Dobre relacje z zespołem programu mogą prowadzić do prywatnych zaproszeń i dodatkowych nagród.

Ujawnianie informacji musi odbywać się zgodnie z zasadami programu i prawem.

• Nie publikować szczegółów, dopóki program nie zezwoli na ujawnienie
• Nigdy nie grozić ujawnieniem błędu w celu wywarcia presji na wypłatę; jest to wymuszenie
• Usuwać prawdziwe dane użytkowników z PoC i zrzutów ekranu

Odpowiedzialne ujawnianie chroni użytkowników i pozwala korzystać z ochrony safe harbor.

Nauczyli się Państwo przekształcać znaleziska w raporty, za które otrzymuje się nagrody.

• Stosować jasną strukturę: tytuł, podsumowanie, kroki możliwe do odtworzenia, wpływ, PoC, naprawa
• Pisać tytuły wskazujące wpływ i podawać konsekwencje w liczbach
• Przedstawiać solidny, surowy dowód koncepcji
• Uzasadniać wagę (np. za pomocą CVSS) dowodami, a nie zawyżaniem oceny
• Dbać o jakość zgłoszeń, komunikować się profesjonalnie i ujawniać informacje etycznie

To kończy kurs Bug Bounty Hunting. Wiedzą już Państwo, jak wybierać cele, skalować rozpoznanie, znajdować najważniejsze błędy i dobrze je raportować.