시작하며
팀원들이랑 여러 회사 사이트를 나눠서 훑어보던 중이었다. 그중 한 명이 오래돼 보이는 로그인 페이지 하나를 가져왔다. 화면 스타일부터가 요즘 나오는 서비스들과는 결이 달랐고, 이런 페이지는 다 같이 보면 반사적으로 폼 구조부터 살피게 된다. 오래된 페이지일수록 최근에 새로 짠 코드보다 손을 덜 탔을 가능성이 있고, 로그인 폼은 특히 그렇다 — 한 번 만들어두면 웬만해선 다시 안 건드리는 기능이라서다.
입력값 하나하나를 각자 나눠서 살펴보다가, 팀원 하나가 파라미터 하나를 짚었다. 동작 자체는 멀쩡해 보이는데, 입력을 살짝 비틀었을 때 반응하는 방식이 뭔가 기계적이지 않았다 — 사람이 짠 검증 로직이라기보다는 그냥 아무 검증도 없이 뒤로 흘러가는 느낌이었다.
확인하는 과정
느낌만으로는 리포트를 쓸 수 없어서, 실제로 그 파라미터가 쿼리에 검증 없이 들어가는지를 확인하는 절차를 밟았다. 이번엔 팀원 중 하나가 직접 확인해보고, 다른 한 명이 옆에서 같은 걸 다시 돌려보면서 교차 확인했다. 몇 단계를 거쳐서 이게 단순한 우연이 아니라 재현 가능한 SQL Injection이라는 걸 확인했다. 확인하는 순간의 느낌은 매번 비슷하다 — 반가움보다 먼저 드는 건 "이거 확실한가, 우리가 잘못 본 거 아닌가"를 다시 한번 의심하는 거다. 그래서 서로 같은 걸 몇 번 더 반복해서 결과가 일관되게 나오는지부터 확인했다.
취약점이 있다는 걸 증명하는 데 필요한 최소한의 확인이면 충분했다.
재현이 안정적으로 된다는 걸 확인하고 나서는 범위를 더 넓히지 않기로 다 같이 합의했다. 실제로 어떤 데이터가 그 뒤에 있는지까지 파고드는 건 권한 밖의 일이고, 굳이 그럴 필요도 없었다.
제보, 그리고 침묵
재현 과정을 같이 정리해서 해당 기업의 제보 채널로 접수했다. 여기까지는 다른 제보들과 똑같은 절차였다. 근데 이 건은 그 뒤로 아무런 피드백이 없었다. 접수는 됐는지, 검토는 하고 있는지, 이미 조치했는지 — 아무것도 확인이 안 되는 상태로 시간이 흘렀다.
이게 은근히 애매한 상태다. KISA처럼 정식 채널을 거치는 신고는 접수·심사·조치 단계가 어느 정도 눈에 보이는데, 기업에 직접 제보하는 경우는 그 기업이 얼마나 적극적으로 소통하느냐에 따라 완전히 달라진다. 어딘가는 하루 만에 답이 오고, 어딘가는 이렇게 조용하다. 이번 건은 후자였다.
그래서 지금은 여기까지만
결과를 모르는 채로 자세한 내용을 공개하는 건 여러모로 맞지 않다고 생각한다. 회사명도, 정확한 엔드포인트도, 어떤 방식으로 확인했는지도 여기엔 적지 않는다. 최악의 경우 아직 조치가 안 된 상태에서 내가 확인한 방법을 그대로 공개해버리는 꼴이 될 수도 있는데, 그건 애초에 이 일을 제보로 시작한 이유와 정반대되는 결과다. 상태가 확인되는 대로 — 조치가 됐다는 게 확인되면 그때 이 글도 업데이트하겠다.
돌아보며
오래되고 화려하지 않은 화면일수록 오히려 눈여겨볼 가치가 있다는 걸 다시 확인했다. 그리고 여러 명이 나눠서 훑어보는 방식이 확실히 효율이 다르다는 것도 — 혼자였으면 이 페이지까지 순서가 오기 전에 지쳤을 수도 있다. 제보한다고 해서 항상 깔끔하게 마무리되는 게 아니라는 것도 다시 배웠다 — 어떤 건 반년째 조용하고, 어떤 건 한 달 안에 끝난다. 결과를 통제할 수 없는 부분은 그냥 받아들이고, 우리가 통제할 수 있는 부분 — 정확하게 확인하고, 범위를 넘지 않고, 책임감 있게 제보하는 것 — 에만 집중하는 수밖에 없다.