🇰🇷 한글 설명
dropbox samly 라이브러리의 Samly.SPHandler.validate_authresp/3가 SAML 응답의 SubjectConfirmationData/@InResponseTo 값을 서비스 제공자가 발급한 AuthnRequest ID와 비교하지 않아, 요청하지 않은 SAML 응답으로도 인증 세션이 생성될 수 있습니다. 요청 ID가 저장되지 않아 검증 자체가 불가능하며, esaml 라이브러리도 이 값을 검사하지 않습니다. 0.3.0 이후 버전이 영향을 받습니다.
💡 쉬운 설명
공격자가 자신의 계정으로 정상 서명된 SAML 인증 응답을 받아두고, 이를 피해자의 세션에 전달하여 로그인 상태를 만들 수 있습니다. 서명 위조가 아니라 응답 요청 여부를 확인하지 않는 문제입니다.
🇺🇸 원문 (English)
Insufficient Verification of Data Authenticity vulnerability in dropbox samly allows an attacker to establish an authenticated session using a SAML response the service provider never requested.
Samly.SPHandler.validate_authresp/3 in lib/samly/sp_handler.ex validates a SAML response for the SP-initiated flow by comparing only the RelayState value, the IdP identifier, and the presence of a target URL held in the session. It never compares SubjectConfirmationData/@InResponseTo against the ID of the AuthnRequest the service provider issued, and that request ID is never persisted, so no comparison is possible. SAML 2.0 Core section 4.1.4.3 requires a service provider to reject a response whose InResponseTo does not match a request it made. The underlying esaml library checks status, signature, recipient, audience, and staleness, but likewise never inspects InResponseTo, so nothing else closes the gap. Exploitation requires a validly signed assertion from the trusted IdP, which an attacker can obtain for their own account, and a RelayState matching the victim's session; the assertion signature itself remains intact, so this is not a signature-forgery issue.
This issue affects samly: from 0.3.0 onward.
📍 영향받는 시스템
samly 0.3.0 이상을 사용하는 Elixir/Phoenix 기반 SAML SP 애플리케이션
⚔️ 공격 벡터
공격자가 신뢰된 IdP에서 본인 계정의 유효한 서명 어설션을 발급받은 뒤, 피해자 세션의 RelayState와 맞춰 SP에 제출하여 인증 세션을 탈취
🛡️ 대응 방법
InResponseTo 검증을 구현한 패치 버전으로 samly를 업그레이드하고, 요청 ID를 세션에 저장해 응답과 대조
🔧 검증 코드
출력된 samly 버전이 0.3.0 이상이고 패치 버전 이전이면 취약하며, 패치 릴리스 버전 이상이면 조치된 것으로 판단합니다.
grep -E '"samly"' mix.lock 2>/dev/null