[보안] 사내 그룹웨어 서비스에서 발견한 Broken Access Control 사례 (OWASP TOP 10)

배경

회사에서 사용하는 그룹웨어 서비스를 쓰다가 보안 이슈로 보이는 상황을 발견했습니다. 개발자도구의 네트워크 탭을 연 상태로 그룹웨어를 사용 중 응답 데이터 안에 다른 직원의 ID가 포함되어 있음을 발견했는데, 그 값을 요청 파라미터에서 바꾸어 특정 API를 호출하면 전혀 관계없는 다른 직원의 근태 정보까지 조회되는 것을 확인하게 된 것입니다. 조금 더 디테일하게 파고들어보고 싶었지만 혹시나 하여 더 이상의 테스트는 진행하지 않고 바로 중단했습니다.

OWASP TOP 10, Broken Access Control, IDOR

국제 웹 보안 표준기구인 Open Web Application Security Project(OWASP)에서는 몇 년에 한 번씩 주요 웹앱 취약점 중 가장 빈번한 10가지(OWASP TOP 10)를 선정하여 발표합니다. 이 중 1번에 랭크되어있는 Broken Access Control은 서버가 사용자의 권한을 제대로 확인하지 않아 접근해서는 안 되는 데이터에 접근할 수 있는 모든 상황을 의미하는데, 이 하위 항목으로 IDOR(Insecure Direct Object Reference)이 포함됩니다. IDOR은 클라이언트가 전달한 식별자 값(예: URL 파라미터)을 그대로 사용해 내부 객체에 접근할 때 인가 검증이 빠져 발생하는 취약점으로, 단순한 파라미터 변경만으로 다른 사람의 정보가 노출될 수 있는 경우를 말하며 흔하면서도 위험도가 높은 사례로 분류됩니다.

*OWASP TOP 10

버그 리포트

제가 발견한 사례는 명백히 IDOR에 해당했습니다. 서버는 요청자의 신원을 확인하고 있었지만, 요청마다 '이 데이터를 볼 권한이 있는가'를 검증하지 않았습니다. 근태 정보는 개인 정보이며, ID만 알면 누구든 조회할 수 있는 구조였기 때문에 저는 문제의 심각성이 크다고 판단했습니다. 그래서 이 문제를 리포트하기로 결정했습니다.

 

발견한 내용을 사실만 중심으로 정리하여(타인 ID 취득 가능 경로, 취득한 ID를 이용한 타인 정보 조회 가능) 서비스 제공자측에 전달했습니다. 보안상 문제가 될 수 있으므로 추가 테스트는 하지 않았고, 필요시 최소한의 재현 정보를 전달할 수 있음을 고지했습니다. 이렇게 처리하면 책임 있는 공개(Responsible Disclosure) 방식으로 문제를 보고한 셈이 됩니다(라고 생각합니다).

 

아직까지 피드백이 오진 않은 상태이지만 충분히 문제가 될 수 있는 요소이고, 잘 알려진 서비스 제공자이므로 아마도 조치가 되지 않을까 생각합니다.

결론

이번 경험을 통해, 평소 당연하게 여겼던 권한 검증 로직의 중요성을 다시 느꼈습니다. 인증만 있다고 해서 서비스가 안전한 것이 아니며, 각 요청마다 권한 검증을 제대로 수행하는 것이 필수적이라는 점을 확인했습니다. 기능 구현뿐 아니라 접근 제어와 데이터 검증 같은 기본적인 보안 요소에도 신경을 좀 더 써야겠습니다.

Note

사실 다들 알만한 서비스라 버그 바운티를 운영하고 있지 않을까 기대했는데 의외로 없어서 당황했습니다. 보상을 바란다기보단 버그바운티가 어떻게 운영되는지 경험을 해보고 싶었던 건데 그점은 조금 아쉽습니다. 그래도 고객센터 통해서 접수하여 유관부서에 잘 전달되었다고 하니 그나마 다행입니다.