SAML: 나쁜 설계가 반복되는 프로토콜

AI 요약

SAML(Security Assertion Markup Language)은 기업과 대학의 웹 서비스에서 사용자 인증을 한 번으로 묶는 SSO(Single Sign-On) 표준으로 널리 쓰여 왔습니다. Trail of Bits의 글은 SAML이 SSO 산업을 키우고 오랫동안 인증을 지원한 점은 인정하면서도, 복잡한 설계와 반복되는 보안 취약점 때문에 신규 도입을 피하고 OIDC(OpenID Connect)로 옮겨야 한다고 주장합니다.

여러 표준을 한데 묶은 출발

SAML은 OASIS 위원회가 2002년에 만들었습니다. 당시 여러 업체가 제출한 네 가지 XML 기반 보안 프로토콜을 하나의 표준에 담았습니다. 이후 Yale의 CAS, Internet2의 Shibboleth, Microsoft의 ADFS 같은 대학·기업 프로젝트가 SAML을 지원했고, Ping Identity와 Okta 등 SSO 사업자도 성장했습니다. 웹 서비스가 늘면서 여러 서비스에 따로 로그인하지 않으려는 수요가 있었고, SAML이 그 요구를 채웠습니다.

서명 검증이 복잡해지는 구조

글은 XML 서명 검증이 SAML의 가장 큰 위험 요소라고 봅니다. XML은 태그와 속성뿐 아니라 네임스페이스, 주석, 스키마, DTD 등 파싱 과정에 영향을 주는 요소가 많습니다. 따라서 SAML 라이브러리는 인증 로직을 처리하기 전부터 XXE, 엔티티 확장, SSRF를 일으키는 DTD 조회, XPath·XSLT 인젝션 같은 XML 취약점도 막아야 합니다.

XML 정규화(Canonicalization)는 서로 다르게 표현된 XML을 서명 검증에 쓸 일관된 형태로 바꾸는 과정입니다. 하지만 정규화 과정에서 파서마다 문서를 다르게 해석하면, 검증한 내용과 실제 인증 코드가 읽는 내용이 달라질 수 있습니다. 글은 이 차이를 악용하는 XML Signature Wrapping(XSW) 공격이 2012년 연구에서 자동으로 탐지됐는데도 이후 여러 구현에서 계속 발견됐다고 설명합니다. 2018년 XML 주석 우회와 2025년 GitHub Enterprise의 libxml2 관련 우회 사례도 언급합니다.

SAML은 서명을 메시지 안에 넣는 enveloped signature 방식도 사용합니다. 서명과 데이터가 한 문서 안에 있어 정규화한 뒤에도 서명 대상과 애플리케이션이 실제로 사용하는 데이터가 일치하는지 보장하기 어렵습니다. 반면 JWT(JSON Web Token)는 서명과 페이로드를 구분자로 분리해 표현합니다. 글의 요점은 XML 자체만이 아니라, 복잡한 문서 구조에서 서명 대상이 정확히 무엇인지 구현마다 달라질 여지가 있다는 점입니다.

필요한 범위를 넘어선 명세와 오래된 가정

현대 SAML 구현은 대체로 비슷한 메시지 형식과 명세 일부만 사용하지만, 표준에는 실제로 거의 쓰지 않는 기능도 들어 있습니다. 글은 이처럼 여러 사용 사례를 미리 포괄하려는 ‘주방 싱크대식’ 설계가 불필요한 복잡성을 더한다고 지적합니다. 새로운 연동을 만든다면 Okta, OneLogin, Google, Shibboleth 같은 주요 제공자가 쓰는 형식과 다른 메시지를 거부하는 방안도 고려하라고 제안합니다.

SAML은 HTTP에 종속되지 않고 IdP와 서비스 제공자(SP)가 서로 직접 통신하지 않아도 동작하도록 설계됐습니다. 당시 기업 방화벽과 네트워크 분리가 중요한 환경에서는 유용했지만, 전송 방식과 메시지에 더 많은 기능과 복잡성을 맡겼습니다. OIDC는 HTTPS와 HTTP 기반 흐름을 전제로 하고, 일반적인 인증 코드 흐름에서는 제공자와 서비스가 직접 통신해 토큰 정보를 주고받습니다. 글은 이 구조가 브라우저 메시지에 담겨야 할 정보량과 복잡성을 줄인다고 설명합니다. 모바일, SPA, IoT 환경을 SAML이 충분히 예상하지 못한 점도 뒤늦은 적응을 어렵게 했다고 봅니다.

새 연동은 OIDC로, 기존 SAML은 단계적으로

글은 모든 프로토콜에 단점이 있다고 전제하면서도 신규 서비스에는 OIDC를 권합니다. SAML의 주요 장점으로 꼽히는 직접 통신 없는 환경도 OIDC의 form post 방식으로 대응할 수 있다고 설명합니다. SAML을 제공하는 인증 사업자는 신규 고객의 SAML 연동을 중단하고, 기존 고객에게 동등한 OIDC 설정을 제공한 뒤 종료 시점을 정하는 단계적 폐기 계획을 세울 수 있습니다. 저자는 SAML이 SSO 산업을 일으키고 오랜 기간 인증 경험을 개선한 공로를 인정하면서도, 새 시스템에서는 사용을 피하자는 입장입니다.

Hacker News 반응

• @ocdtrekkie — SAML을 지원하지 않으면 지원하는 다른 제품을 고르면 됩니다. 기업용 제품이 어떤 인증 방식을 쓸지 독단적으로 정하는 건 대체로 받아들이기 어렵습니다. 우리가 쓰는 방식에 맞추든지, 우리 요구에 맞지 않는 제품이 되는 겁니다. OIDC만 쓰는 제품에도 SAML만 쓰겠다고 하면 비슷하게 거부당할 겁니다.
  • @jeltz — 그런 태도는 보안 연극에 가깝습니다. 기업 IT에서 보안 연극이 흔하다는 점을 생각하면 놀랍지도 않습니다.
  • @jeroenhd — 보안도 이유지만 편의성도 큽니다. 사실상 거의 모든 제품이 SAML을 지원합니다. 표준 SSO 프로토콜 하나를 지원하지 않으면 고객을 잃습니다. 회사의 인증 시스템을 바꿀 만큼 큰 이점을 주고 경쟁 제품도 없어야 바꾸게 됩니다.
  • @clhodapp — 결국 공략할 시장과 개발 비용의 문제입니다. OIDC만 지원할 때 잃을 고객이 얼마나 되는지, 그 차이가 SAML 구현을 계속 유지할 만큼 큰지 따져야 합니다. 그래도 SAML 설계가 나쁘다는 글의 주장은 맞고, 신규 연동 때마다 비용과 위험을 다시 계산하는 일은 좋습니다.
• @cratermoon — SaaS 제품 상당수에는 직접 통신이 필요한 네트워크 구조가 맞지 않습니다. SaaS 업체의 서비스가 우리 시스템에 백채널로 접속하도록 열어두고 싶지 않습니다.
  • @foltik — 그 경계는 조금 임의적인 것 같습니다. 웹훅에도 같은 생각을 적용하시겠습니까?
• @stuaxo — 주요 인증 방식을 전부 구현하는 건 지옥입니다. OAuth2도 정말 형편없습니다.
  • @7bit — 인증에 권한 부여 프로토콜을 쓰는 이유가 뭔가요? OIDC를 써보세요.
  • @vips7L — OIDC는 OAuth 위에 얹힌 계층입니다.
  • @9dev — 맞습니다. 다만 OIDC는 인증 프로토콜이고 OAuth는 권한 부여 프로토콜입니다.
  • @bawolff — OAuth2는 SAML보다 훨씬 낫습니다. 명세를 따르면 안전하게 구현할 가능성이 있지만, SAML은 그럴 가능성이 거의 없습니다.
• @arpinum — 글에 나온 것보다 SAML은 더 나쁩니다. 서명이 실제로 무엇에 걸렸는지 확인해야 합니다. 다만 XML 전체를 처리하는 라이브러리에 기대기보다 SAML의 안전한 일부와 상위 제공자 약 10곳의 방언만 지원하는 방법에는 기대를 걸고 있습니다. 아주 특수한 제공자는 계약 규모가 충분할 때 따로 추가하면 됩니다.
  • @bawolff — 보통은 문서 전체에 서명합니다. SAML은 정규화 뒤 공격자가 조작할 수 있는 일부에 서명할 수 있습니다. 그러면 서명이 덮지 않는 내용을 공격자가 추가해 파서를 혼란시킬 수 있습니다. 주석을 넣어 텍스트 노드 해석을 바꾸면서 서명은 그대로 통과시키는 사례가 특히 인상적입니다.
  • @stouset — 서명이 문서의 한 부분을 참조해 검증하는 구조입니다. 서명된 부분이 문서 전체와 무관해도, 서명 검증 뒤 문서 전체를 신뢰한 구현이 놀랄 만큼 많았습니다.
• @miguelspizza — SAML은 나쁘지만 OAuth와 OIDC도 에이전트 신원 문제에서 큰 균열을 보입니다. 지금 주요 기업에 에이전트 인증을 어떻게 하는지, 에이전트 신원을 무엇으로 보는지 물어보면 됩니다. 다만 글에서 다룬 XSW는 처음 알았고 꽤 충격적입니다.
  • @jeroenhd — RFC 8628은 8년 전에 나왔습니다. OAuth가 봇을 막고 있는 건 아닙니다. 브라우저용 흐름에 봇을 억지로 끼워 넣을 때 문제가 생깁니다. 그 문제 때문에 새 프로토콜이 필요한 건 아닙니다.
• @sandeepkd — 소수 의견일 수 있지만 SAML이 잘하는 영역도 있습니다. OAuth2/OIDC에서는 요청이 서비스 제공자에서 시작해야 하지만, 기업 IdP는 IdP 시작 흐름을 지원하는 SAML을 선호합니다. 글이 SAML 취약점만 나열하고 OIDC와 같은 기준으로 비교하지 않은 점도 아쉽습니다. 결국 도구의 효과는 사용하는 사람의 이해와 숙련도에 달렸습니다.
• @bawolff — 제가 가장 좋아하는 SAML 괴담은 주요 XML 서명 C 라이브러리가 예전에는 공격자가 조작한 문서 안의 비밀번호를 이용한 HMAC 검증과 웹 PKI 검증까지 기본으로 시도했다는 이야기입니다. 공격자는 자기 도메인의 TLS 키로 SAML 문서에 서명해도 인증을 통과시킬 수 있었습니다. 이렇게 끔찍한 표준과 구현이 있는데도 SAML 사이트가 늘 해킹당하지 않는 게 신기합니다.
• @cameronh90 — SAML은 나쁘지만 기업 SSO 용도에 맞는 기능 중 OIDC에 없는 것도 있습니다. 대표적으로 IdP 시작 흐름입니다. 기업에 제품을 판매한다면 둘 다 지원해야 합니다.
  • @maxwellg — OIDC가 IdP 시작 흐름을 지원하지 않는 데는 이유가 있습니다. Login CSRF 공격에 취약하기 때문입니다. 공격자가 피해자 브라우저에 공격자 계정의 인증 응답을 제출하게 해 피해자가 자기 계정 대신 공격자 계정에 로그인하도록 속일 수 있습니다. IdP 포털에서 앱 아이콘을 제공하고 싶다면 그 아이콘이 서비스의 안전한 로그인 흐름을 시작하도록 연결해야 합니다.

원문: Trail of Bits / 번역·요약: Trawling