Pisanie wysokiej jakości raportów o błędach

Wysokiej jakości zgłoszenie jest szybciej poddawane triage, rzadziej zostaje oznaczone jako duplikat lub zgłoszenie informacyjne, otrzymuje trafną ocenę istotności i buduje reputację zgłaszającej osoby w programach. Słabe zgłoszenia — nawet dotyczące krytycznych błędów — mogą zostać odrzucone lub niedoszacowane.

Każde dobre zgłoszenie zawiera: tytuł podatności, ocenę istotności wraz z uzasadnieniem CVSS, wskazanie podatnego zasobu (URL/endpoint), opis problemu, instrukcję odtworzenia krok po kroku, proof of concept, ocenę wpływu oraz proponowane rozwiązanie.

Dobry tytuł jest konkretny i zawiera istotne informacje: „IDOR w /api/v2/users/{id} umożliwia każdemu uwierzytelnionemu użytkownikowi dostęp do prywatnych danych profilu” jest lepszy niż „Obejście autoryzacji”. W jednym zdaniu należy uwzględnić typ podatności, podatny endpoint i wpływ.

Instrukcję odtwarzania należy napisać tak, aby młodszy programista, który nigdy wcześniej nie widział tego błędu, mógł go odtworzyć. Każdy krok należy ponumerować. Należy dołączyć dokładne żądania HTTP (skopiowane z Burp Suite). Trzeba także uwzględnić wszelkie wymagane warunki wstępne (typ konta, ograniczenie geograficzne, pora dnia).

Należy dołączyć zrzuty ekranu, nagrania ekranu albo przechwycone w Burp Suite żądania i odpowiedzi HTTP, które potwierdzają istnienie podatności. W przypadku IDOR należy pokazać, że Konto A uzyskuje dostęp do danych Konta B za pomocą zmodyfikowanego żądania, a odpowiedź zawiera dane B.

Należy jasno wyjaśnić wpływ biznesowy: „Atakujący może uzyskać pełne imię i nazwisko, adres e-mail, numer telefonu i adres rozliczeniowy dowolnego użytkownika, iterując po identyfikatorach”. W miarę możliwości należy podawać konkretne wartości: „Tabela użytkowników zawiera 2 miliony rekordów, do których wszystkich można uzyskać dostęp”. Należy powiązać wpływ techniczny z ryzykiem biznesowym.

Wiele programów używa CVSS 3.1 do oceny istotności. Należy poznać sześć podstawowych metryk: AV (wektor ataku), AC (złożoność), PR (wymagane uprawnienia), UI (interakcja użytkownika), S (zakres) oraz C/I/A (wpływ). Trafna ocena CVSS świadczy o kompetencjach i przyspiesza triage.

Typowe błędy w zgłoszeniach to: brak załączonego PoC, brak warunków wstępnych w instrukcji odtwarzania, zaniżona ocena wpływu (nie należy określać przejęcia konta jako „niskiego”), teoretyczne podatności bez dowodu, że można je wykorzystać, oraz zgłaszanie duplikatów bez wcześniejszego sprawdzenia ujawnionych raportów.

Należy wkleić dokładne żądanie i odpowiedź HTTP (po zredagowaniu poufnych danych — nie należy dołączać danych osobowych innych użytkowników w zakresie większym, niż jest to konieczne). Funkcja „Copy as curl” w Burp Suite pozwala podać jednolinijkowe polecenie odtwarzające problem, które osoby weryfikujące mogą od razu uruchomić.

Na pytania osób przeprowadzających triage należy odpowiadać szybko. Jeśli poproszą o wyjaśnienie, należy go udzielić w ciągu 24–48 godzin. Profesjonalna i uprzejma komunikacja buduje długotrwałe relacje z zespołami bezpieczeństwa oraz zwiększa szanse na uznanie ponownego testowania i otrzymanie dodatkowych nagród.

Należy czytać najwyżej oceniane raporty na stronach ujawnień HackerOne i Bugcrowd. Warto analizować, jak najlepsi badacze strukturyzują raporty, wykazują wpływ i łączą podatności. Następnie należy odwzorować ich formatowanie i sposób opisywania wpływu we własnych zgłoszeniach.

Jaki jest najważniejszy element odróżniający wysokiej jakości raport podatności od słabego raportu?

Wysokiej jakości raporty łączą konkretny tytuł, jasną instrukcję odtwarzania, konkretny proof of concept, trafną ocenę CVSS i przekonującą ocenę wpływu biznesowego. Inwestowanie w jakość raportów maksymalizuje nagrody, buduje reputację i przyspiesza triage po stronie zespołów bezpieczeństwa.