SAML, 내부 들여다보기: 서명은 편지 안에
SAML은 거의 모든 업무 앱에 로그인하게 해주며, 그 서명은 서명하는 XML 내부에 있습니다.
SAML은 거의 모든 업무 앱에 로그인하게 해주며, 그 서명은 서명하는 XML 내부에 있습니다. 내부 들여다보기: 앱, 브라우저, ID 공급자 간의 로그인 과정, 어설션이 어떻게 생겼는지, 왜 정규화가 모든 바이트에 동의해야 하는지, 그리고 왜 2012년부터 2025년까지 동일한 버그 클래스가 계속해서 돌아오는지. Trail of Bits의 "SAML: A fractal of bad design" (Hacker News에서 312점)에 의해 촉발되었습니다.
이 동영상에서 다루는 내용
- SAML: 내부에서 스스로 서명하는 로그인
- 2002년: 4가지 XML 형식, 하나의 위원회, 전체 산업
- 로그인 과정: 앱 → ID 공급자 → 브라우저를 통해 다시
- 어설션: 서명이 서명하는 것 안에 존재한다
- 정규화: 모든 바이트에 동의해야 로그인 가능
번역된 스크립트
원래 영어 내레이션에서 번역되었습니다. 사용 가능한 오디오 및 캡션은 YouTube에서 제어합니다.
SAML: 내부에서 스스로 서명하는 로그인
0:00 SAML은 거의 모든 업무 앱에 로그인하게 해주는 XML이며, 그 서명은 서명하는 문서 내부에 있습니다. 마치 공증인이 봉인하는 봉투 안에 도장을 찍는 것과 같습니다. 위원회가 이를 작성한 지 10년 후, 연구원들은 14개의 SAML 프레임워크를 테스트했습니다. 11개가 실패했습니다. 그리고 이번 주, Trail of Bits의 게시물은 SAML을 나쁜 디자인의 프랙탈이라고 부르며 Hacker News의 첫 페이지를 장식했습니다. 3분 안에: 로그인 과정이 어떻게 작동하는지, 서명이 어디에 숨어 있는지,
0:27 그리고 모두가 동의하는 해결책이 왜 다른 프로토콜인지. 여기는 The Daily Diff, 내부 들여다보기입니다.
2002년: 4가지 XML 형식, 하나의 위원회, 전체 산업
0:34 2002년. Oasis의 보안 위원회가 4가지 공급업체 XML 형식을 하나로 통합했습니다. 대학들이 먼저 채택했고, 그 다음 Okta가 이를 기반으로 회사를 설립했습니다. 위원회 문서가 수익으로 전환된 가장 빠른 사례입니다. 앱을 엽니다.
로그인 과정: 앱 → ID 공급자 → 브라우저를 통해 다시
0:46 앱은 당신이 누구인지 모르므로, 당신의 브라우저를 ID 공급자, 즉 당신 회사 Okta로 보냅니다. 거기서 로그인합니다. Okta는 당신의 브라우저에 당신이 누구인지 알려주는 서명된 XML 문서를 전달하고, 브라우저는 이를 다시 게시합니다.
어설션: 서명이 서명하는 것 안에 존재한다
0:59 그 문서가 어설션입니다. 사용자 이름을 명시하고, 서명이 그 안에 있으며, 자신의 ID로 어설션을 다시 가리킵니다. 그리고 이 모든 것이 당신의 브라우저를 통해, 즉, 사용자를 통해 전달됩니다. 이를 확인하기 위해 앱은
정규화: 모든 바이트에 동의해야 로그인 가능
1:11 서명된 정확한 바이트를 재구성합니다. 서명을 다시 잘라내고, 공백과 속성 순서를 정규화한 다음 결과를 해시합니다. 이것이 정규화이며, 만약 양측이 단 한 바이트라도 일치하지 않으면, 아무도 로그인할 수 없습니다. JSON 웹 토큰은 다르게 작동합니다. 헤더, 페이로드, 서명이 점으로 구분되어 나란히 놓여 있습니다. 먼저 잘라낼 것이 없습니다.
2012년: 검사자와 리더가 다른 요소를 본다
1:32 여기에 문제가 있습니다. 서명을 확인하는 코드와 사용자 이름을 읽는 코드는 종종 두 개의 다른 부분입니다. 2012년, 'On Breaking Saml'이라는 논문은 독자가 무시하는 곳으로 서명된 어설션을 이동시키고, 독자가 찾는 곳에 두 번째 어설션을 놓을 수 있음을 보여주었습니다. Salesforce와 Shibboleth는 이로 인해 무너진 11개 중 일부였습니다. 2018년, Duo는 사용자 이름 내의 주석이 일부 라이브러리가 이름의 절반만 읽게 할 수 있지만,
2018년 및 2025년: 두 개의 파서, 두 개의 다른 답변
1:55 서명은 여전히 유효하다는 것을 보여주었습니다. 2025년, GitHub은 Ruby SAML 내에서 두 개의 XML 파서가 동일한 문서에 대해 의견이 일치하지 않는 것을 발견했습니다. 같은 버그, 새로운 시대. Trail of Bits는 이를 프랙탈이라고 부릅니다. 확대하는 모든 레벨에서
왜 계속 고장나는가: 나쁜 디자인의 프랙탈
2:12 동일한 결함이 있기 때문입니다. XML을 기반으로 하며, 서명은 봉투 안에 있고, 실제 로그인은 사양의 10분의 1 정도만 사용합니다. 그리고 Hacker News의 상위 댓글은 구매자로부터 왔습니다. SAML 지원이 없다면, 다른 제품을 찾을 수 있습니다. 둘 다 사실이라는 것이 문제입니다. 그래서, 월요일. OpenID Connect를 먼저 배포하십시오. Fly와 Tailscale은 SAML 없이도
월요일: OIDC 우선, 유지 관리되는 라이브러리, 엄격한 형식
2:31 기업에 판매합니다. 고객이 강제한다면, 유지 관리되는 라이브러리를 사용하고, 패치를 적용하며, Okta나 Google이 보내는 것과 다르게 보이는 메시지는 거부하십시오. 절대 자신만의 서명 확인 코드를 작성하지 마십시오.
결정, 내부 들여다보기: REVERT
2:43 판결, 내부 들여다보기. REVERT. 거의 25년, 결코 죽지 않는 하나의 버그 클래스, 그리고 모두가 동의하는 해결책은 다른 프로토콜입니다. 지난 토요일에 패스키를 분석했습니다. 다음에는 무엇을 열어볼지 댓글로 알려주세요. 이것이 오늘의 차이점입니다. 저는 Axrisi의 Niko입니다. 책임감 있게 병합하세요.
출처
- Trail of Bits, "SAML: A fractal of bad design" (Matt Schwager, Sep 21, 2026)blog.trailofbits.com
- Hacker News threadnews.ycombinator.com
- Somorovsky et al., "On Breaking SAML: Be Whoever You Want to Be", USENIX Security 2012www.usenix.org
- Duo Labs, SAML vulnerabilities affecting multiple implementations (2018): https://duo.com/blog/duo-finds-saml-vulnerabilities-affecting-multiple-implementations · CERT VU#475445www.kb.cert.org
- GitHub Security Lab, "Sign in as anyone: Bypassing SAML SSO authentication with parser differentials" (Mar 12, 2025)github.blog
