다음을 통해 공유

사용자 식별 또는 권한 부여를 위해 이메일 클레임을 사용하지 않고 마이그레이션합니다.

  • 아티클

이 문서는 권한 부여를 위해 이메일 클레임이 사용되는 안전하지 않은 패턴을 현재 사용하고 있는 애플리케이션의 개발자에게 지침을 제공하기 위한 것입니다. 이로 인해 다른 사용자가 전체 계정을 인수할 수 있습니다. 애플리케이션이 영향을 받는지 여부와 수정 단계에 대해 자세히 알아보려면 계속해서 참조하세요.

내 애플리케이션이 영향을 받았는지 어떻게 알 수 있나요?

Microsoft에서는 애플리케이션 소스 코드를 검토하고 다음 패턴이 있는지 확인하는 것이 좋습니다.

  • email과 같은 변경 가능한 클레임은 사용자를 고유하게 식별하는 데 사용됩니다.
  • email과 같은 변경 가능한 클레임은 리소스에 대한 사용자 액세스 권한을 부여하기 위해 사용됩니다.

프로비전된 사서함이 없는 사용자는 메일(기본 SMTP) 특성에 대해 이메일 주소를 설정할 수 있으므로 이러한 패턴은 안전하지 않은 것으로 간주됩니다. 이 특성은 확인된 이메일 주소에서 오는 것이 보장되지 않습니다. 확인되지 않은 도메인 소유자가 있는 이메일 클레임을 권한 부여에 사용하는 경우 프로비전된 사서함이 없는 사용자는 메일 특성을 변경하고 다른 사용자를 가장하여 무단 액세스 권한을 얻을 가능성이 있습니다.

다음과 같은 경우 이메일은 도메인 소유자가 확인된 것으로 간주됩니다.

  • 도메인은 사용자 계정이 있는 테넌트에 속하며 테넌트 관리자가 도메인 확인을 완료했습니다.
  • 이메일이 MSA(Microsoft 계정)에서 전송되었습니다.
  • 이메일이 Google 계정에서 온 것입니다.
  • 이메일이 OTP(일회용 암호) 흐름을 사용한 인증에 사용되었습니다.

또한 Facebook 및 SAML/WS-Fed 계정에는 확인된 도메인이 없다는 점에 유의해야 합니다.

이러한 무단 액세스 위험은 다중 테넌트 앱에서만 발견되었습니다. 한 테넌트의 사용자가 메일 특성 수정을 통해 다른 테넌트의 리소스에 액세스할 수 있는 권한을 승격할 수 있기 때문입니다.

내 애플리케이션을 즉시 보호하려면 어떻게 해야 하나요?

확인되지 않은 이메일 주소로 인한 실수로부터 애플리케이션을 보호하기 위해 모든 새로운 다중 테넌트 애플리케이션은 2023년 6월부터 확인되지 않은 도메인 소유자가 있는 이메일 주소를 토큰에서 제거하는 새로운 기본 동작에 자동으로 선택됩니다. 도메인 소유자가 확인되지 않은 이메일 주소를 사용한 이전 로그인 작업이 있는 단일 테넌트 애플리케이션 및 다중 테넌트 애플리케이션에는 이 동작이 사용하도록 설정되지 않습니다.

시나리오에 따라 애플리케이션의 토큰이 확인되지 않은 이메일을 계속 수신하도록 결정할 수 있습니다. 대부분의 애플리케이션에는 권장되지 않지만, Microsoft Graph에 있는 애플리케이션 API의authenticationBehaviors 개체에서 removeUnverifiedEmailClaim 속성을 설정하여 기본 동작을 사용하지 않도록 설정할 수 있습니다.

removeUnverifiedEmailClaim을 false로 설정하면 애플리케이션이 잠재적으로 확인되지 않고 사용자에게 계정 인수 위험을 초래할 수 있는 email개의 클레임을 수신하게 됩니다. 사용자 로그인 흐름을 중단하지 않기 위해 이 동작을 사용하지 않도록 설정하는 경우 아래 지침에 설명된 대로 가능한 한 빨리 고유 식별 토큰 클레임 매핑으로 마이그레이션하는 것이 좋습니다.

안전하지 않은 구성 식별 및 데이터베이스 마이그레이션 수행

변경 가능한 클레임(예: emailpreferred_username등)을 식별자로 사용하여 데이터베이스에서 권한 부여 검사 또는 인덱스 사용자를 수행해서는 안 됩니다. 이러한 값은 재사용 가능하며 애플리케이션이 권한 상승 공격에 노출될 수 있습니다.

다음 의사 코드 샘플은 사용자 식별/권한 부여의 안전하지 않은 패턴을 설명하는 데 도움이 됩니다.

 // Your relying party (RP) using the insecure email claim for user identification (or authorization)
 MyRPUsesInsecurePattern()
 {
    // grab data for the user based on the email (or other mutable) attribute
    data = GetUserData(token.email)

    // Create new record if no data present (This is the anti-pattern!)
    if (data == null) 
    {
        data = WriteNewRecords(token.email)
    }

    insecureAccess = data.show // this is how an unverified user can escalate their privileges via an arbirarily set email
 }

애플리케이션이 이 안전하지 않은 특성에 의존하고 있음을 확인한 후에는 GUID(Globally Unique Identifier)에서 사용자를 다시 인덱스화하도록 비즈니스 논리를 업데이트해야 합니다.

다중 테넌트 애플리케이션은 고유하게 식별되는 두 개의 클레임인 tid + oid 매핑에 대한 인덱스를 생성해야 합니다. 이렇게 하면 테넌트가 tid로 분할되고 사용자가 oid로 분할됩니다.

xms_edov 선택적 클레임을 사용하여 이메일 확인 상태를 확인하고 사용자를 마이그레이션합니다.

마이그레이션 프로세스에서 개발자를 지원하기 위해 이메일 도메인 소유자가 확인되었는지 여부를 나타내는 부울 속성인 선택적 클레임 xms_edov를 도입했습니다.

xms_edov는 기본 키를 oid와 같은 고유 식별자로 마이그레이션하기 전에 사용자의 이메일을 확인하는 데 도움이 될 수 있습니다. 다음 의사 코드 예에서는 이 클레임을 마이그레이션의 일부로 사용할 수 있는 방법을 보여 줍니다.

// Verify email and migrate users by performing lookups on tid+oid, email, and xms_edov claims
MyRPUsesSecurePattern()
{
    // grab the data for a user based on the secure tid + oid mapping
    data = GetUserData(token.tid + token.oid)

    // address case where users are still indexed by email
    if (data == null) 
    {
        data = GetUserData(token.email)

        // if still indexed by email, update user's key to GUID
        if (data != null) 
        {

            // check if email domain owner is verified 
            if (token.xms_edov == false) 
            {
                yourEmailVerificationLogic()
            }

            // migrate primary key to unique identifier mapping (tid + oid)
            data.UpdateKeyTo(token.tid + token.oid)
        }

        // new user, create new record with the correct (secure) key
        data = WriteNewRecord(token.sub)
    }

    secureAccess = data.show
}

전역적으로 고유한 매핑으로 마이그레이션하면 각 사용자가 주로 다른 사용자를 가장하기 위해 재사용되거나 남용될 수 없는 값으로 인덱싱됩니다. 사용자가 GUID(Globally Unique Identifier)에 대해 인덱스를 생성하고 나면 email 클레임을 사용하는 잠재적인 권한 부여 논리를 수정할 준비가 된 것입니다.

적절한 클레임 유효성 검사로 권한 부여 논리 업데이트

애플리케이션이 권한 부여 목적으로 email(또는 기타 변경 가능한 클레임)을 사용하는 경우 클레임의 유효성을 검사하여 애플리케이션 및 API 보안를 자세히 읽고 적절한 검사를 구현해야 합니다.

다음 단계