실제 환경의 원격 MCP 서버를 대상으로 한 측정 연구에서 약 8,000개의 라이브 배포 사례를 스캔한 결과, 40.55%가 인증(authentication)을 전혀 사용하지 않은 채 도구를 노출하고 있다는 사실이 밝혀졌습니다. 이는 인증 설정 오류가 아니라, 아예 인증 자체가 없는 상태였습니다. 해당 논문은 엔드포인트를 발견한 누구에게나 수천 개의 내부 연락처 기록을 노출한, 인증되지 않은 CRM 연결 서버의 사례를 설명합니다. OAuth가 활성화된 서버들도 상황은 크게 다르지 않았습니다. 동일한 연구에서 119개의 서버를 테스트한 결과, 모든 서버에서 최소 하나 이상의 확인된 인증 결함이 발견되었습니다. 총 325개의 결함이 발견되었으며, 그중 동적 클라이언트 등록(dynamic client registration) 문제는 테스트된 서버의 96.6%에서 나타났습니다. MCP OAuth에 대한 표준 권장 사항은 PKCE를 사용하고, 리다이렉트 URI(redirect URIs)를 정확하게 검증하며, 동적 클라이언트 등록을 기본적으로 고위험군으로 취급하는 것입니다. 이 권장 사항은 올바르며, 스펙(spec)에서 직접적으로 제시하는 내용입니다. 문제는 이 권장 사항이 틀렸다는 것이 아니라, 이를 따르는 것과 이를 검증하는 것이 서로 다른 활동이라는 점이며, 대부분의 팀은 첫 번째 단계만을 수행한다는 것입니다. PKCE를 구현한다는 것은 클라이언트가 코드 챌린지(code challenge)를 보내고 서버가 코드 검증기(code verifier)를 확인한다는 것을 의미합니다. 이는 설정(config) 항목이며, 한 번 켜지면 계속 유지됩니다. 하지만 이것이 서버가 실제로 일치하지 않는 검증기를 거부할지, 리다이렉트 URI 검증을 끝에 슬래시(/)를 붙이거나 인코딩 트릭을 사용하여 우회할 수 있는지, 혹은 재사용된 권한 부여 코드(authorization code)가 흐름의 어딘가에서 여전히 허용되는지 여부를 알려주지는 않습니다. 이러한 문제들은 누군가 설정 파일을 읽을 때가 아니라, 실제로 구현 사항을 깨뜨리려고 시도할 때 나타나는 것들입니다. 이것이 연구 결과의 수치가 그렇게 나타나는 가장 유력한 이유입니다. 테스트된 서버의 96.6%가 OAuth를 갖추고 있었음에도 불구하고 동적 클라이언트 등록 과정 어딘가에서 실패했습니다. 그들은 스펙을 무시한 것이 아닙니다. 단지 한 번 구현한 뒤 그것이 잘 작동할 것이라고 가정했을 뿐입니다. 실제로 그 간극을 메우는 방법은 라이브 배포를 단순히 '설정하고 방치하는 것'이 아니라, '테스트해야 할 대상'으로 취급하는 것입니다.

이는 단순히 문서를 검토하는 것이 아니라, API에 대한 침투 테스트 (Pentest)를 수행하는 것과 동일한 방식으로, 실행 중인 서버를 대상으로 명세서(Spec)가 경고하는 바로 그 공격들—불일치하는 PKCE 검증기 (PKCE verifiers), 잘못된 형식의 리다이렉트 URI (Malformed redirect URIs), 재전송된 코드 (Replayed codes), 위조된 동의 흐름 (Forged consent flows)—을 주기적으로 시도해 보아야 함을 의미합니다. 여기 계신 분들 중, 단순히 한 번 설정하고 넘어가는 대신 자신의 MCP OAuth 흐름을 실제로 깨뜨려 보려고 시도해 본 분이 얼마나 될지 궁금하네요. submitted by /u/Hacken_io [link] [comments]