🚀 이슈 핵심 요약: SAML은 왜 ‘나쁜 설계의 프랙탈’이라 불리는가
보안 업계에서 손꼽히는 컨설팅 기업 Trail of Bits가 최근 공개한 기술 블로그 글이 개발자 커뮤니티를 뜨겁게 달구고 있습니다. 제목부터 도발적인 ‘SAML: A fractal of bad design(SAML: 나쁜 설계의 프랙탈)’은, 기업 환경에서 널리 쓰이는 SSO(Single Sign-On) 인증 표준인 SAML(Security Assertion Markup Language)의 근본적인 설계 결함을 정면으로 저격하고 있습니다.
여기서 ‘프랙탈’이라는 표현이 핵심입니다. 프랙탈은 아무리 확대해도 똑같은 패턴의 복잡한 구조가 반복되는 도형을 뜻하는데요, Trail of Bits는 SAML을 어느 레벨에서 뜯어봐도 구조적 결함이 끝없이 반복되는 프로토콜이라고 지적합니다. 즉, 표면적인 버그 하나를 고쳐도 그 밑에 똑같은 유형의 문제가 계속 발견된다는 뜻이죠. 🔍
SAML은 2000년대 초반 XML 기반으로 설계된 인증/인가 프로토콜로, 지금도 수많은 대기업과 공공기관의 SSO 시스템 근간을 이루고 있습니다. 그런데 왜 20년이 넘은 지금까지도 이런 근본적인 비판을 받는 걸까요? 지금부터 그 이유를 하나씩 파헤쳐보겠습니다.
💻 기술적 배경 및 상세 내용: XML의 저주에 걸린 인증 시스템
1. XML 파싱과 서명 검증의 분리 문제
SAML의 가장 악명 높은 취약점은 바로 XML 서명 래핑 공격(XML Signature Wrapping Attack)입니다. SAML 응답(Response)은 XML 형태로 전달되고, 그 안에 디지털 서명이 포함되어 무결성을 보장합니다. 문제는 ‘무엇이 서명되었는가’와 ‘무엇이 처리되는가’가 서로 다른 코드 경로에서 처리된다는 점입니다.
공격자는 정상적으로 서명된 XML 요소를 그대로 유지한 채, 문서 구조 안에 새로운 가짜 요소를 몰래 삽입합니다. 서명 검증 로직은 원본 서명된 부분만 확인하고 ‘유효하다’고 판단하지만, 실제로 애플리케이션이 처리하는 것은 공격자가 삽입한 가짜 요소인 경우가 발생합니다. 이 틈을 타면 다른 사용자로 완벽하게 위장한 로그인(계정 탈취)이 가능해지는 것이죠. 😱
2. 지나치게 복잡한 XML 표준 자체의 문제
SAML이 기반으로 삼는 XML Signature, XML Encryption 표준 자체가 지나치게 유연하고 복잡합니다. 같은 의미를 표현하는 방법이 너무 많고(Canonicalization, 네임스페이스 처리 등), 파서마다 구현 방식이 미묘하게 달라 ‘해석의 불일치’가 발생하기 쉽습니다. 이런 유연성은 개발자에게는 악몽이고, 공격자에게는 놀이터가 됩니다.
3. 반복되는 보안 사고 이력
- Duo Security, OneLogin 등 주요 SSO 업체에서 과거 XML 서명 래핑 관련 취약점이 다수 보고됨
- 오픈소스 SAML 라이브러리(OneLogin’s Ruby SAML 등)에서 인증 우회 취약점(CVE)이 반복적으로 발견
- 구현체마다 파싱 로직이 미묘하게 달라 동일한 표준임에도 서로 다른 취약점 패턴 발생
Trail of Bits는 이런 사례들을 근거로, 단순히 특정 라이브러리나 구현체의 버그가 아니라 SAML이라는 표준 자체의 설계 철학이 근본적으로 안전하지 않은 방향으로 짜여 있다고 주장합니다.
💡 업계 파장 및 전망: 개발자와 기업은 무엇을 준비해야 하나
🏢 기업 IT 담당자에게 주는 시사점
여전히 많은 대기업, 금융기관, 공공기관이 레거시 SSO 인프라로 SAML을 채택하고 있습니다. 당장 걷어내기는 어렵지만, 이번 지적을 계기로 다음과 같은 조치가 필요합니다.
- 사용 중인 SAML 라이브러리의 최신 보안 패치 여부 즉시 점검
- XML 서명 검증 로직이 파싱과 분리되어 있는지 내부 감사 실시
- 가능하다면 OAuth 2.0 + OpenID Connect(OIDC) 같은 JSON 기반의 최신 표준으로 마이그레이션 로드맵 수립
👨💻 개발자에게 주는 시사점
SAML을 직접 구현하거나 유지보수하는 개발자라면, ‘표준을 따랐으니 안전하다’는 안일한 생각을 버려야 합니다. 서명 검증은 반드시 실제로 처리되는 XML 요소를 대상으로 이루어져야 하며, 신뢰할 수 있는 검증된 라이브러리(예: 최신 패치가 유지되는 오픈소스 프로젝트)를 사용하는 것이 필수입니다.
🌐 장기적인 업계 트렌드
이번 이슈는 단순히 SAML 하나의 문제가 아니라, 레거시 XML 기반 보안 표준 전반에 대한 재검토를 촉발할 가능성이 큽니다. 실제로 최근 몇 년간 글로벌 빅테크와 스타트업들은 신규 서비스에서 SAML 대신 더 단순하고 검증하기 쉬운 JSON 기반의 OIDC를 채택하는 추세입니다. 이번 Trail of Bits의 지적은 이런 흐름에 더욱 힘을 실어줄 전망입니다. 📈
❓ 자주 묻는 질문 (FAQ)
Q1. SAML을 사용하는 우리 회사, 지금 당장 위험한 건가요?
A1. 반드시 즉각적인 위험을 의미하지는 않습니다. 다만 사용 중인 SAML 구현체(라이브러리, IdP/SP 솔루션)의 최신 버전 및 패치 적용 여부를 우선 점검하는 것이 중요합니다. 특히 자체 개발한 SAML 처리 로직이 있다면 XML 서명 래핑 공격에 취약하지 않은지 보안 전문가의 코드 리뷰를 받아보시길 권장합니다.
Q2. SAML 대신 어떤 대안을 고려해야 하나요?
A2. 신규 프로젝트라면 OAuth 2.0과 OpenID Connect(OIDC) 조합이 현재 가장 널리 권장되는 대안입니다. JSON 기반으로 구조가 단순하고, 토큰 검증 로직이 XML보다 훨씬 명확해 구현 실수 여지가 적습니다. 다만 기존 레거시 시스템과의 호환성 문제가 있을 수 있으므로, 단계적 마이그레이션 전략을 수립하는 것이 현실적입니다.
답글 남기기