고품질 버그 보고서 작성

품질이 높은 보고서는 더 빠르게 초기 검토를 받고, 중복 또는 정보 제공성 보고서로 분류될 가능성이 낮으며, 정확한 심각도 평가를 받고, 프로그램과의 평판을 쌓는 데 도움이 됩니다. 품질이 낮은 보고서는 치명적인 버그를 다루더라도 거부되거나 보상 가치가 낮게 평가될 수 있습니다.

품질이 높은 모든 보고서에는 취약점 제목, CVSS 근거를 포함한 심각도 평가, 영향을 받는 자산(URL/종단점), 문제 설명, 단계별 재현 절차, 개념 증명, 영향 평가, 권장 수정 방법이 포함됩니다.

좋은 제목은 구체적이고 유용한 정보를 담고 있어야 합니다. "인증된 모든 사용자가 비공개 프로필 데이터에 접근할 수 있도록 하는 /api/v2/users/{id}의 IDOR"가 "권한 부여 우회"보다 낫습니다. 한 문장에 취약점 유형, 영향을 받는 종단점, 영향을 포함하십시오.

이 버그를 한 번도 본 적 없는 초급 개발자도 재현할 수 있도록 재현 절차를 작성하십시오. 각 단계에 번호를 매기십시오. 정확한 HTTP 요청을 포함하십시오(버프 스위트에서 복사). 필요한 사전 조건(계정 유형, 지역 제한, 시간대)도 포함하십시오.

취약점이 존재한다는 사실을 입증하는 스크린샷, 화면 녹화 또는 버프 스위트의 HTTP 요청 및 응답 캡처를 포함하십시오. IDOR의 경우, 수정된 요청을 사용해 계정 A가 계정 B의 데이터에 접근하고 응답에 B의 데이터가 표시되는 모습을 보여주십시오.

비즈니스 영향을 명확히 설명하십시오. "공격자는 ID를 차례로 대입하여 모든 사용자의 전체 이름, 이메일, 전화번호, 청구 주소에 접근할 수 있습니다." 가능한 경우 수치로 표현하십시오. "사용자 테이블에는 200만 개의 레코드가 있으며 모두 접근할 수 있습니다." 기술적 영향을 비즈니스 위험과 연결하십시오.

많은 프로그램이 심각도를 평가할 때 CVSS 3.1을 사용합니다. 기본 지표 6가지를 익히십시오. AV(공격 경로), AC(복잡성), PR(필요 권한), UI(사용자 상호작용), S(범위), C/I/A(영향)입니다. CVSS를 정확하게 산정하면 전문성을 보여 주고 초기 검토를 신속하게 진행하는 데 도움이 됩니다.

보고서에서 흔히 발생하는 실수는 다음과 같습니다. 개념 증명을 첨부하지 않음, 재현 절차에 사전 조건이 빠짐, 영향을 축소해 설명함(계정 탈취를 "낮음"이라고 표현하지 마십시오), 악용 가능하다는 증거가 없는 이론적 취약점을 제시함, 공개된 보고서를 먼저 확인하지 않고 중복 제출함입니다.

정확한 HTTP 요청과 응답을 붙여 넣으십시오(민감한 데이터는 가림 처리하고, 필요한 범위를 넘어 다른 사용자의 PII를 포함하지 마십시오). 버프 스위트의 "curl로 복사" 기능을 사용해 검토자가 즉시 실행할 수 있는 한 줄짜리 재현 명령을 제공하십시오.

초기 검토 질문에 신속하게 답변하십시오. 설명을 요청받았다면 24~48시간 이내에 제공하십시오. 전문적이고 예의 바른 커뮤니케이션은 보안 팀과의 장기적인 관계를 쌓고, 재테스트 공로 인정과 보너스 보상을 받을 가능성을 높입니다.

HackerOne과 Bugcrowd의 공개 페이지에서 높은 평가를 받은 보고서를 읽으십시오. 뛰어난 연구자들이 보고서를 구성하고, 영향을 입증하고, 취약점을 연결하는 방식을 연구하십시오. 자신의 제출물에도 그들의 서식과 영향 설명 방식을 적용하십시오.

품질이 높은 버그 보고서와 품질이 낮은 보고서를 구분하는 가장 중요한 요소는 무엇입니까?

품질이 높은 버그 보고서는 구체적인 제목, 명확한 재현 절차, 확실한 개념 증명, 정확한 CVSS 점수 산정, 설득력 있는 비즈니스 영향 평가를 갖춥니다. 보고서 품질에 투자하면 보상을 극대화하고 평판을 쌓으며 보안 팀의 초기 검토를 신속하게 진행할 수 있습니다.