← ALL RESEARCH
Field Notes

헤더 하나 바꿔봤다가

Naver Bug Bounty · NBB-2026-0095 · 2026-03-29
이 글의 순서
  1. 시작하며
  2. 이상하다 싶었던 순간
  3. 제보하기까지
  4. 기다리는 동안
  5. 돌아보며

시작하며

딱히 뭘 노리고 앉은 건 아니었다. 팀원들이랑 같이 네이버 쇼핑 쪽을 이것저것 찔러보고 있었고, 다들 개발자 도구 Network 탭을 켜놓은 채였다. 큰 서비스일수록 요청 개수가 많아서 혼자서는 하나하나 다 볼 여유가 없는데, 여러 명이 각자 다른 화면을 보고 있으니 그중 한 명이 GraphQL 요청 하나를 짚었다. 커스텀 헤더가 붙어 있었고, 이름부터가 낯설었다.

이런 헤더를 보면 버릇처럼 하는 게 있다 — 그냥 지워보거나, 값을 말도 안 되게 바꿔서 다시 보내보는 것. 대부분은 아무 일도 안 일어난다. 서버가 알아서 무시하거나, 그냥 정상적인 fallback으로 빠지거나. 열에 아홉은 그렇다. 근데 가끔 그 나머지 하나가 나온다.

이상하다 싶었던 순간

값을 바꿔서 보내니 500 에러가 떨어졌다. 여기까지는 흔한 일이다. 서버가 예상 못 한 입력을 받으면 에러를 내는 게 당연하고, 보통은 그걸로 끝이다. "요청이 잘못됐습니다" 같은 한 줄짜리 메시지가 오면 아, 이 헤더는 뭔가 검증을 하긴 하는구나 정도만 확인하고 넘어간다.

근데 이번엔 응답 body가 눈에 띄게 길었다. 보통 에러 응답이 이 정도로 길 이유가 없다. 스크롤을 몇 번 더 내려야 할 정도였고, 그 안에 있으면 안 될 것 같은 종류의 정보들이 섞여 있는 게 보였다. 정확히 뭐가 담겨 있었는지는 여기서 풀지 않겠지만, 화면을 같이 보고 있던 팀원도 바로 "이거 이상한데" 하고 반응했다. 혼자 봤으면 그냥 넘겼을 수도 있는데, 다른 사람 눈에도 똑같이 걸린다는 게 확신을 더 굳혀줬다. 이런 감은 자주 틀리는데, 이번엔 여러 번 같이 다시 봐도 같은 결론이었다.

혼자 봤으면 그냥 넘겼을 수도 있는데, 다른 사람 눈에도 똑같이 걸린다는 게 확신을 더 굳혀줬다.

제보하기까지

확신이 든 다음부터는 오히려 조심스러워진다. 어디까지가 내가 실제로 확인한 범위인지, 어디부터는 추측인지를 분명히 나눠야 한다. 이 건은 특히 애매했다 — 단독으로 실행하면 내 계정, 내 세션에 대한 정보만 보이는 구조였는데, 그 구조 자체가 갖는 의미는 훨씬 컸다. 로그인 상태에서 같은 방식으로 트리거하면 브라우저가 원래 막아주는 종류의 쿠키까지 응답에 실려 나온다는 걸 확인했을 때는, 이건 "내 정보만 보였다"로 축소해서 쓰면 안 되는 건이라고 판단했다.

보고서는 팀원들이랑 같이 정리했다. 재현 절차를 남이 따라할 수 있게 정리하고, 왜 이게 위험한지를 과장 없이 설명하고, 영향 범위를 실제로 확인한 것과 추정만 한 것으로 나눠서 적었다. 생각보다 오래 걸렸는데, 한 사람이 쓰고 나머지가 돌아가면서 검토하는 식으로 진행해서 그나마 빠뜨리는 걸 줄일 수 있었다. 테스트 범위도 명확히 했다 — 자동화 스캐너나 퍼저는 쓰지 않았고, 단일 엔드포인트에서 확인한 것 이상으로 다른 서비스를 건드리지 않았다는 것, 타인의 세션을 탈취하거나 열람하지 않았다는 것. 이런 걸 한 줄씩 명시해 두는 게 귀찮아 보여도, 나중에 심사하는 쪽에서 신뢰할 수 있는 리포트인지 아닌지를 가르는 지점이라고 생각한다.

기다리는 동안

제보하고 나면 할 수 있는 게 별로 없다. 접수 확인 메일이 오고, 그다음부터는 그냥 기다리는 시간이다. 이 시간이 은근히 길게 느껴진다 — 확인은 됐다는데 실제로 얼마나 심각하게 보고 있는지, 패치가 언제 될지는 알 수가 없으니까. 중간에 몇 번 추가 질문이 오갔다. 재현이 안 된다는 피드백도 있었는데, 그럴 때마다 다시 정확히 어떤 조건에서 재현되는지 짚어서 답했다.

결과적으로는 정식으로 접수되어 심사를 거쳤고, 포상금도 지급받았다 — 같이 찾고 같이 제보한 팀원들과 나눴고, 벌써 꽤 오래전 일이다. 지급이 끝났다고 해서 아무거나 다 공개해도 되는 건 아니다. 참여 약관에 신고한 취약점의 공격 방법이나 세부 정보는 기밀로 다뤄야 한다고 명시되어 있고, 허가 없이 외부에 공개하면 이후 프로그램 참여 자격이나 이미 지급된 포상금에도 문제가 생길 수 있다고 적혀 있다. 그래서 이 글에도, 지금 사이트의 Bounty 카드에도 딱 공개 가능한 선까지만 남겨뒀다.

돌아보며

거창한 도구나 스캐너 없이, 그냥 켜놓고 있던 개발자 도구에서 헤더 하나를 바꿔본 게 시작이었다. 근데 그게 여러 명이 각자 다른 화면을 나눠 보고 있었기 때문에 가능했던 것도 크다 — 혼자 봤으면 스쳐 지나갔을 수도 있는 요청을 누군가는 보고 있었고, 발견한 뒤에도 서로 검증해주니 확신이 훨씬 빨리 섰다. 큰 서비스일수록 이런 사소한 지점 하나하나까지 다 완벽하게 막혀 있을 거라고 생각하기 쉬운데, 실제로는 안 그런 경우가 꽤 있다. 그리고 에러 메시지가 평소보다 길다 싶을 때 그냥 넘기지 않는 습관 — 이게 별거 아닌 것 같아도 이번처럼 꽤 크게 돌아올 때가 있다.

작성자: Alert_K (ANH) 관련: Naver Bug Bounty · NBB-2026-0095