편집기
셰인 위든, IBM
안호, IBM
추상적인
세션 하이재킹은 온라인 사기 및 계정 탈취를 위한 초기 공격 벡터가 증가하고 있습니다. FIDO 인증은 크리덴셜 스터핑 및 피싱과 같은 다른 간단한 형태의 침해의 효율성을 감소시키기 때문에 사이버 범죄자는 전달자 토큰의 도난 및 재사용으로 전환합니다. 전달자 토큰은 웹 사이트에 연결하는 브라우저에서 사용하는 세션 쿠키와 기본 모바일 애플리케이션과 같은 다른 씩 클라이언트 애플리케이션 유형에서 사용하는 OAuth 액세스 토큰을 포함하는 자격 증명의 한 형태입니다. 이러한 자격 증명이 수명이 길고 다른 시스템에서 악의적인 행위자가 사용할 수 있도록 생성된 시스템에서 “들어 올려 이동”할 수 있는 경우 거래 가능한 가치는 중요합니다. 브라우저용 DBSC(Device Bound Session Credentials) 및 OAuth 애플리케이션용 DPoP(Demonative Proof of Possession)와 같은 새로운 기술은 세션 하이재킹의 위협을 줄이기 위해 노력합니다. 이 문서에서는 이러한 기술이 세션 하이재킹 문제를 해결하는 방법과 온라인 생태계에서 강력한 피싱 방지 인증을 보완하는 방법에 대해 설명합니다.
관객
이 백서는 온라인 사기로부터 온라인 ID 및 액세스 관리의 보안 및 수명 주기를 보호하는 책임이 있는 최고 정보 보안 책임자(CISO) 및 기술 직원을 위한 것입니다.
1. 소개
인증 및 권한 부여는 ID 수명 주기, 특히 온라인 자격 증명 에코시스템의 경우 필수적인 부분입니다. 비용이 많이 드는 보안 사고 및 침해로 인한 온라인 신원 사기의 위협이 증가함에 따라 기업은 피싱, 크리덴셜 스터핑, 세션 하이재킹과 같은 다양한 공격 벡터를 통해 계정 탈취로부터 직원을 보호하고 보호할 수 있는 방법을 찾고 있습니다. 인증의 경우 패스키를 사용한 FIDO 인증은 사용자에게 “더 안전하고 안전하며 빠른 온라인 경험”을 제공하며, 패스키 채택이 증가함에 따라 MITM(man-in-the-middle) 피싱 공격을 통해 수행되는 크리덴셜 피싱, 크리덴셜 스터핑 및 세션 하이재킹과 같은 공격 벡터의 성공률이 감소했습니다. 그러나 인증식 이후에는 어떻게 됩니까?
인증 후 브라우저 및 애플리케이션 클라이언트에는 일반적으로 다른 자격 증명이 발급됩니다. 엔터프라이즈 애플리케이션은 일반적으로 웹 브라우저 기반이고 상태 관리를 위해 세션 쿠키를 사용하는 애플리케이션과 OAuth 액세스 토큰을 사용하는 씩 클라이언트 애플리케이션(일부 브라우저 기반 단일 페이지 애플리케이션 및 대부분의 기본 모바일 애플리케이션 포함)의 두 가지 기본 범주로 나뉩니다. 두 가지 유형의 자격 증명(세션 쿠키 및 액세스 토큰)은 기본 사용에서 “전달자” 토큰으로 간주됩니다. 토큰(세션 쿠키 또는 액세스 토큰)이 있는 경우 해당 토큰을 인증하고 소유한 사용자로서 해당 토큰의 수명 동안 계속 거래할 수 있습니다. 이 백서에서는 베어러 토큰에 대한 “리프트 앤 시프트” 공격 벡터를 해결하는 인접 기술과 이러한 기술이 FIDO 기반 인증 메커니즘을 보완하는 방법을 살펴봅니다. 특히, 이 백서에서는 브라우저 세션 쿠키를 보호하기 위해 제안된 웹 표준 DBSC(Device Bound Session Credentials) 에 중점을 두고 OAuth 2.0 OAuth 보조금 보호를 위한 DPoP(소유 증명) 입증 .
2. 용어
세션 하이재킹: 일반적으로 세션 쿠키에 대해 관리되는 웹 세션 제어 메커니즘의 악용입니다.
자격 증명 스터핑: 도난당한 사용자 이름과 비밀번호 쌍(자격 증명)을 웹사이트 로그인 양식에 자동으로 삽입하여 사용자 계정에 부정하게 액세스합니다.
1. 패스키 – https://fidoalliance.org/passkeys/
2. 디바이스 바인딩 세션 자격 증명 – https://github.com/w3c/webappsec-dbsc
3. OAuth 2.0 소유 증명(DPoP) 입증 – RFC9449: https://datatracker.ietf.org/doc/html/rfc9449
4. 세션 하이재킹 공격 https://owasp.org/www-community/attacks/Session_hijacking_attack
5. 크리덴셜 스터핑 https://owasp.org/www-community/attacks/Credential_stuffing
액세스 토큰: 클라이언트 측 애플리케이션에서 사용자를 대신하여 API 호출을 호출하는 데 사용하는 자격 증명입니다.
세션 쿠키: 브라우저와 웹 사이트 간의 세션 상태를 유지하기 위해 브라우저에서 관리하는 자격 증명입니다.
전달자 토큰: 토큰(이 백서의 맥락에서 액세스 토큰 또는 세션 쿠키를 참조할 수 있음)은 토큰을 보유한 사람이 이를 사용하여 리소스에 액세스할 수 있기 때문에 그렇게 불립니다. 베어러 토큰은 다른 컴퓨팅 장치에서 사용하기 위해 자체적으로 “들어 올리고 이동”할 수 있습니다.
보낸 사람 제한 토큰: 인증 프로세스 중에 토큰을 설정한 클라이언트 이외의 다른 사용자가 서버 쪽 리소스에 대한 후속 요청에서 해당 토큰을 사용할 수 있는 위험을 최소화하도록 설계된 메커니즘으로 보호되는 토큰입니다.
DBSC(Device Bound Session Credential): 발신자 제한 쿠키를 설정하고 유지 관리하기 위한 프로토콜 및 브라우저 동작을 정의하는 W3C 웹 표준에 대한 제안입니다. 이 메커니즘은 비대칭 암호화 키의 소유 증명을 사용하여 세션 쿠키 하이재킹을 완화하는 데 도움이 됩니다. OAuth 2.0 DPoP(Proof of Procession) 시연: 클라이언트가 토큰을 사용할 때 비대칭 암호화 키의 소유를 입증해야 하는 발신자 제한 액세스 토큰을 구현하는 메커니즘입니다.
OAuth 2.0 DPoP(Proof of Procession) 시연: 클라이언트가 토큰을 사용할 때 비대칭 암호화 키의 소유를 입증해야 하는 발신자 제한 액세스 토큰을 구현하는 메커니즘입니다.
3. 안전한 생태계를 위한 인접/보완 기술
FIDO 인증 기술은 로그인 프로세스 중에 발생하는 피싱 및 크리덴셜 스터핑 공격을 효과적으로 제거할 수 있지만, 전달자 토큰 도용과 관련된 위협을 완화하기 위한 솔루션을 추가하는 것도 마찬가지로 중요합니다. 로그인 프로세스 중에 공격이 저지된 악의적인 행위자는 체인에서 다음으로 가장 취약한 링크를 추적하여 인증 후 전달자 토큰을 훔치려고 시도합니다. 이 섹션에서는 전달자 토큰을 보호하기 위한 두 가지 기술, 즉 브라우저 기반 세션 쿠키를 보호하는 DBSC(Device Bound Session Credentials)와 OAuth 권한 부여를 보호하는 DPoP(Proof of Possession)를 보여줍니다. 무기명 토큰을 보호하기 위한 대체 접근 방식도 논의됩니다.
단일 기술로는 모든 위협으로부터 보호할 수 없기 때문에 적절한 보호를 위해서는 여러 기술의 조합이 필요합니다.
표 1: 보안 강화를 위한 기술 조합
| 기술 | 인증 위협 | 인증 후 위협 | |
| 원격 피싱 | 크리덴셜 스터핑 | 토큰 도용 | |
| Passkeys | ✅ | ✅ | ❌ |
| DBSC/DPoP | ❌ | ❌ | ✅ |
| 패스키 + DBSC/DPoP | ✅ | ✅ | ✅ |
3.1 브라우저 세션 쿠키 보안
DBSC(Device Bound Session Credentials)에 대해 논의하기 전에 브라우저 세션 쿠키와 관련하여 해결되는 문제를 이해해야 합니다. 쿠키 도용을 통한 세션 하이재킹을 통해 훔친 쿠키를 소유한 공격자는 강력한 인증 또는 다단계 인증(MFA)을 포함한 최종 사용자 인증을 우회할 수 있습니다. 이는 브라우저가 수명이 긴 세션 쿠키(전달자 토큰의 일종)를 생성할 때 특히 문제가 되는데, 이러한 쿠키는 사용자의 기본 인증 자격 증명에 대한 대안으로 거래된 다음 공격자의 시스템에서 사용될 수 있기 때문입니다. 이로 인해 민감한 데이터에 대한 무단 액세스, 재정적 손실 및 조직의 평판 손상이 발생할 수 있습니다.
공격자는 사용자의 기존 MFA 로그인 프로세스에 대한 중간자 피싱(FIDO와 같은 피싱 방지 인증을 사용하지 않는 경우), 클라이언트 측 멀웨어, 때로는 서버 측 인프라 또는 소프트웨어의 취약점을 통해 쿠키 도용을 수행합니다. 쿠키 도용이 어떻게 저질러지는지에 관계없이 이러한 공격이 성공하면 위험할 뿐만 아니라 격리 및 탐지하기도 어렵습니다. DBSC(Device Bound Session Credentials)와 같은 보완 기술은 도난당한 쿠키를 인증 중에 발급된 시스템 이외의 시스템에서 사용할 수 없게 만들어 브라우저 쿠키 도난과 관련된 위험을 최소화합니다.
3.2 장치 바인딩 세션 자격 증명 – DBSC
DBSC 는 현재 W3C의 웹 애플리케이션 보안 워킹 그룹 내에서 개발 중인 제안된 웹 표준을 말합니다[2]. DBSC의 목표는 도난당한 웹 세션 쿠키 시장을 퇴치하고 방해하는 것입니다. 이는 HTTP 메시징 프로토콜을 정의하고 애플리케이션 세션 쿠키의 사용을 사용자의 컴퓨팅 장치에 바인딩하는 데 필요한 브라우저 및 서버 동작을 정의하여 달성됩니다. DBSC는 비대칭 키 쌍을 사용하며 브라우저 구현에서 개인 키는 공격자가 추출할 수 없어야 합니다(예: TPM(신뢰할 수 있는 플랫폼 모듈), 보안 요소 또는 유사한 하드웨어 기반 암호화 모듈 내에 저장됨).
높은 수준에서 API는 사용자의 브라우저 및 보안 키 스토리지 기능과 함께 다음을 허용합니다.
- 서버는 새 DBSC 세션을 설정하기 위한 요청을 브라우저에 전달합니다. 여기에는 서버 제공 과제가 포함됩니다.
- 브라우저는 비대칭 키 쌍을 생성한 다음 서명된 챌린지와 함께 공개 키를 서버로 보냅니다. 이 프로세스를 DBSC 등록이라고 합니다. DBSC의 브라우저 구현은 안전한 하드웨어 바인딩 스토리지 및 개인 키 사용을 용이하게 하는 운영 체제 API를 사용해야 합니다.
- 서버는 수명이 짧고 새로 고칠 수 있는 auth_cookie 발행하여 공개 키를 브라우저 세션에 바인딩하며, 이 후속 브라우저 요청에서 웹 서버로 전송해야 합니다.
auth_cookie가 정기적으로 만료되므로 브라우저가 기본 애플리케이션 웹 트래픽에 대해 비동기적으로 auth_cookie 새로 고치는 메커니즘이 필요합니다. 새로 고침 프로세스에서는 DBSC 등록 중에 생성된 동일한 개인 키를 사용하여 서버에서 발행한 새 챌린지에 서명해야 하므로 클라이언트 브라우저가 여전히 동일한 개인 키를 소유하고 있음을 (정기적으로) 다시 증명해야 합니다.
auth_cookie의 수명을 짧은 기간(예: 몇 분)으로 제한하면 수명이 긴 세션 쿠키 거래 시장이 중단됩니다. 공격자는 도난당한 세션 쿠키(auth_cookie 포함)를 짧은 기간 동안만 사용할 수 있으며 새로 고침 작업을 수행하는 데 필요한 개인 키를 클라이언트 컴퓨터에서 추출할 수 없으므로 새로 고침 작업을 수행할 수 없습니다.
DBSC는 응용 프로그램에 대한 최소한의 변경으로 기존 배포에 도입될 수 있습니다. DBSC는 기존 서버 측 기술(예: Apache 모듈, 서블릿 필터 또는 역방향 프록시 기능)에 웹 플러그인 모듈로 쉽게 통합될 수 있으므로 이는 중요합니다. 이를 통해 기업은 현재 모든 인프라를 완전히 점검하지 않고도 단계적으로 DBSC 배포를 출시할 수 있으며 기업은 특정 중요한 엔드포인트 또는 리소스의 우선 순위를 먼저 지정할 수 있습니다.
DBSC 서버 측 구현은 의미 체계를 허용하는 방식으로 작성할 수도 있습니다(예: “브라우저가 DBSC를 지원하는 경우 DBSC를 사용하고, 그렇지 않으면 일반 세션 특성으로 대체하십시오.” 이를 통해 사용자는 모든 사용자가 먼저 브라우저를 업그레이드하도록 요구할 필요 없이 DBSC를 지원하는 브라우저를 사용할 때 DBSC의 보안 이점을 얻을 수 있습니다.
DBSC 키 쌍에 증명을 추가하는 엔터프라이즈별 확장에 대한 제안을 포함하여 DBSC 프로토콜 및 표준에 대한 자세한 내용은 Device Bound Session Credentials 설명 자를 참조하십시오.
3.2.1 DBSC가 FIDO를 보완하는 기술인 이유는 무엇인가요?
DBSC 초안 표준은 로그인 프로세스를 DBSC API와 긴밀하게 통합할 수 있도록 허용합니다. FIDO는 인증을 더 안전하고 피싱에 강하게 만드는 메커니즘인 반면, DBSC는 인증 후 전달자 자격 증명(세션 쿠키)을 더 안전하게 만드는 메커니즘입니다. 계정 탈취 및 남용의 위험을 줄임으로써 서로를 보완하여 애플리케이션 세션의 전체 수명 주기를 더 안전하게 만듭니다.
3.2.2 대체 솔루션
DBSC는 클라이언트 장치에 대한 바인딩 세션 쿠키를 제안하는 첫 번째 표준이 아닙니다. 토큰 바인딩은 IETF RFC 8471, 8472 및 8473을 결합한 대안입니다. HTTP를 통한 토큰 바인딩은 TLS(전송 계층 보안) 확장을 통해 구현되며 암호화 인증서를 사용하여 토큰을 TLS 세션에 바인딩합니다. 토큰 바인딩은 브라우저 채택이 제한적이었고 애플리케이션 계층과 TLS 보안 스택에서 변경이 필요하기 때문에 구현이 복잡합니다. HTTP 표준을 통한 토큰 바인딩은 널리 채택되지 않았으며 현재 하나의 주요 브라우저만 지원합니다.
3.2.3 팁
DBSC 표준은 브라우저 세션에 바인딩된 개인 키의 저장 및 사용을 위해 로컬 장치 보안 및 운영 체제 API에 의존합니다. 이러한 개인 키는 다른 장치로 내보낼 수 없지만 키는 로컬 시스템에서 사용할 수 있으며 사용자 장치에 상주하는 맬웨어에 의해 실행될 수 있습니다. 마찬가지로 브라우저 내 멀웨어는 여전히 일반 세션 쿠키와 수명이 짧은 auth_cookies 모두에 대한 완전한 가시성을 가지고 있습니다. DBSC는 클라이언트 측 멀웨어 보호를 대체하지 않으며, DBSC에 대한 위협 모델은 지속적인 클라이언트 측 멀웨어로부터 보호를 제공하지 않습니다. 궁극적으로 사용자는 브라우저를 신뢰해야 합니다.
시간이 지남에 따라 브라우저가 DBSC를 지원하기 시작함에 따라 서버가 이 기술에 대한 지원을 포함하거나 포함하지 않는 브라우저를 혼합하여 작업할 수 있어야 합니다. 일부 기업에서는 기업에서 발급한 시스템에 DBSC를 지원하는 것으로 알려진 브라우저가 포함되도록 지시할 수 있지만 많은 기업은 그렇지 않습니다. 서버 측 구현에서는 브라우저가 등록 요청에 응답할 때 DBSC를 사용하고 브라우저가 응답하지 않을 때 바인딩되지 않은 세션 쿠키를 허용하여 이를 고려해야 합니다. 상용 솔루션을 구축하거나 선택할 때 이 시나리오를 고려하고 고도로 제어되거나 규제된 환경 또는 특정 애플리케이션에 대해 DBSC를 엄격하게 요구하는 액세스 제어 정책을 구현하는 기능을 포함해야 합니다.
이 글을 쓰는 시점에서 DBSC는 초기 발전에 있습니다. 브라우저 공급업체에서 널리 채택될지는 두고 봐야 합니다. W3C를 통해 이 표준을 인큐베이팅하고 개발하면 모든 주요 브라우저 구현에 암호 키 인증을 제공하기 위해 WebAuthn API가 채택된 방식과 유사하게 이전 제안보다 더 널리 채택될 수 있기를 바랍니다.
4. OAuth 보조금
이전 섹션에서는 웹 브라우저에서 세션 쿠키 도난을 방지하는 수단으로 DBSC를 소개했습니다. 모바일 애플리케이션 및 단일 페이지 웹 애플리케이션을 포함한 씩 애플리케이션 클라이언트는 일반적으로 세션 쿠키 대신 OAuth 권한 부여를 활용하는 상태 비저장 API 호출을 사용합니다. OAuth 권한 부여는 여러 가지 방법으로 설정할 수 있으며, 씩 클라이언트에 권장되는 패턴 은 처음에 시스템 브라우저를 사용하여 사용자를 인증하고 애플리케이션을 대신하여 작동하도록 액세스 권한을 부여하는 것입니다. 개념적으로 이는 가능한 경우 최종 사용자 인증에 FIDO 인증을 사용할 수 있는 기능 및 권장 사항을 포함하여 브라우저 기반 세션과 매우 유사합니다. 이 흐름의 브라우저 기반 인증 부분이 끝나면 프로그래밍 방식 API 호출에 사용하기 위해 토큰이 설정되는 씩 클라이언트 애플리케이션 또는 단일 페이지 웹 애플리케이션에 제어가 반환됩니다.
이 시점부터 발생하는 문제는 브라우저에 대해 설명된 것과 거의 동일합니다 – OAuth 토큰은 악의적인 행위자에게 노출된 경우 합법적인 응용 프로그램 대신 원격 시스템에서 응용 프로그램 API를 호출하는 데 사용할 수 있는 전달자 토큰입니다.
이 섹션에서는 DBSC와 마찬가지로 비대칭 키 쌍과 개인 키의 지속적인 소유 증명을 사용하는 OAuth 보호 API 호출에 사용되는 자격 증명의 “리프트 앤 시프트”를 보호하는 기술인 DPoP의 사용에 대해 설명합니다.
4.1 소유 증명(DPoP) 입증
OAuth 2.0 DPoP(Proof of Possession )는 디바이스 바인딩(또는 발신자 제한) OAuth 액세스 및 새로 고침 토큰을 구현하기 위한 기존 OAuth 2.0 표준의 확장입니다. OAuth 권한 부여와 연결된 토큰(즉, 새로 고침 토큰 및 액세스 토큰)이 공개 및 개인 키 쌍을 사용하여 요청된 클라이언트와 바인딩할 수 있도록 하는 애플리케이션 수준 메커니즘입니다. 이를 위해서는 클라이언트가 액세스 토큰 새로 고침 작업을 수행할 때 권한 부여 서버에 개인 키의 소유권을 증명하고 액세스 토큰을 사용하여 API를 호출할 때 리소스 서버에 개인 키의 소유권을 증명해야 합니다.
6. 네이티브 앱용 OAuth 2.0 https://datatracker.ietf.org/doc/html/rfc8252
FAPI 2.0(Financial-grade API)과 같은 높은 보증 OpenID 사양은 발신자 제한 토큰의 사용을 의무화하고 DPoP는 상호 TLS(mTLS)를 사용할 수 없는 경우 이 요구 사항을 구현하는 데 권장되는 방법입니다.
높은 수준에서 DPoP는 다음을 요구합니다.
- 클라이언트는 DPoP 증명을 구성하는 데 사용할 권한 부여별 공개/개인 키 쌍을 생성합니다. 모범 사례 구현은 운영 체제 API를 사용하여 프라이빗 키를 추출할 수 없도록 해야 합니다.
- 초기 권한 부여 설정(예: OAuth 권한 부여 코드를 권한 부여의 첫 번째 액세스 토큰 및 새로 고침 토큰 교환)에서 DPoP 증명(무엇보다도 공개 키의 복사본을 포함하는 클라이언트의 개인 키로 서명된 JWT)을 사용하여 공개 키를 권한 부여에 바인딩합니다.
- 이러한 방식으로 얻은 액세스 토큰을 사용하여 리소스 서버에 대한 요청에는 DPoP 증명 헤더도 포함되어야 하며, 이는 권한 부여 설정 중에 사용된 개인 키의 소유를 지속적으로 증명해야 합니다. 이 작업은 모든 API 요청에 대해 수행됩니다. 리소스 서버는 액세스 토큰이 발신자 제한을 받는지 확인하고, 공개 키를 확인하고, 각 API 호출에서 DPoP 증명 헤더의 유효성을 검사해야 합니다.
- 공용 클라이언트의 경우 권한 부여 서버의 토큰 엔드포인트에 대한 후속 refresh_token 흐름에도 초기 권한 부여 설정 중에 사용된 것과 동일한 키로 서명된 DPoP 증명이 포함되어야 합니다. 새로 고침 토큰은 수명이 긴 경우가 많고 일종의 전달자 토큰이기도 하기 때문에 이는 특히 중요합니다(즉, 가지고 있는 경우 사용할 수 있음). 권한 부여 서버는 이러한 새로 고침 토큰 흐름에 대해 DPoP 증명 사용을 강제하고 초기 권한 부여 설정 중에 등록된 동일한 공개 키를 통해 서명 유효성 검사가 발생하도록 해야 합니다.
모든 보유자가 사용할 수 있는 일반 전달자 액세스 토큰과 달리 DPoP 기반 액세스 토큰은 해당 클라이언트만 개인 키로 DPoP 증명에 서명할 수 있으므로 처음에 OAuth 권한 부여를 설정한 클라이언트에 바인딩됩니다. 이 접근 방식은 유출된 액세스 토큰을 거래하는 악의적인 행위자와 관련된 위험을 최소화합니다.
자세한 내용은 DPoP RFC 9449 – OAuth 2.0 DPoP(Proof of Possession) 시연을 참조하십시오.
4.2 DPoP가 FIDO를 보완하는 기술인 이유는 무엇입니까?
FIDO는 OAuth 부여를 설정하는 동안 피싱 방지 최종 사용자 인증에 활용될 수 있습니다. 이 인증 후 클라이언트가 얻은 새로 고침 및 액세스 토큰은 브라우저 기반 앱의 세션 쿠키와 마찬가지로 “리프트 앤 시프트” 공격으로부터 보호되어야 합니다. DPoP는 이러한 OAuth 토큰을 무단 사후 인증으로부터 보호하기 위해 권장되는 솔루션입니다. 최종 사용자 인증을 위한 FIDO와 OAuth 토큰을 클라이언트 디바이스에 바인딩하기 위한 DPoP는 서로를 보완하여 씩 클라이언트 애플리케이션에 사용되는 ID에 대한 전반적인 보안 태세를 개선합니다.
4.2.1 DPoP 대체 솔루션?
RFC8705 – OAuth 2.0 상호 TLS 클라이언트 인증 및 인증서 바인딩 액세스 토큰은 액세스 토큰을 클라이언트 인증서에 바인딩하는 전송 계층 솔루션을 제공하는 메커니즘에 대해 설명합니다. 오픈 뱅킹 솔루션을 위해 FAPI 2.0 에서 사용하도록 승인되었지만 기본 모바일 애플리케이션과 같은 공용 클라이언트에는 특별히 적합하지 않습니다.
RFC9421 – HTTP 메시지 서명은 HTTP 메시지의 일부에 서명하기 위한 애플리케이션 수준 메커니즘을 정의합니다. 클라이언트와 검증자 간의 키 설정 및 공유는 DPoP와 유사한 방식으로 초기 권한 부여 설정 중에 첫 번째 사용자 방식에 대한 신뢰 로 수행될 수 있지만 이 사양에 의해 정의되지 않습니다. HTTP 메시지 서명의 사용을 OAuth 클라이언트 애플리케이션의 송신자 제한 전달자 토큰의 유스 케이스에 맵핑하는 알려진 공용 스펙은 없습니다. 이러한 공개 사양이 없으면 이 사용 사례에 대한 광범위한 채택은 거의 없습니다.
4.2.2 팁
보낸 사람 제한 토큰은 좋은 생각이며 일부 배포에서는 규정 요구 사항입니다. 예를 들어, OAuth의 FAPI 프로필 사용은 이제 많은 주권 오픈 뱅킹 이니셔티브에서 의무화되고 있습니다. DPoP는 이 요구 사항을 충족하는 비교적 간단한 방법이며 광범위한 애플리케이션 클라이언트 유형을 포괄할 수 있을 만큼 유연합니다. 즉, DPoP의 보안 고려 사항을 준수하기 위해 주의를 기울여야 합니다. RFC9449의 섹션 11에 세심한 주의를 기울이고 시나리오에 따라 네이티브 또는 브라우저 기반 단일 페이지 애플리케이션에 대한 다른 애플리케이션 보안 전략을 적용하십시오. DPoP는 악의적인 행위자의 거래 및 사용을 포함하여 토큰 유출과 관련된 위협을 해결하는 데에만 중점을 두고 있다는 점을 기억하십시오. 이는 OAuth 애플리케이션에 대한 심층 방어 전략의 일부로 간주되어야 합니다.
5. 결론
이 백서의 목적은 다양한 웹 보안 표준이 어떻게 조화를 이루는지, 그리고 이러한 표준이 사용자를 위한 FIDO 인증 사용과 어떤 관련이 있는지에 대한 생각을 고취하는 것입니다. 표준과 표준 기관이 너무 많아서 어떤 표준이 동일한 공간에서 경쟁하고 어떤 것이 서로를 보강하여 온라인 애플리케이션에서 신원 사기 보호를 위한 포괄적인 심층 방어 전략의 일부를 형성하는지 이해하기 어려운 경우가 많습니다.
이 백서는 도난당한 쿠키 및 액세스 토큰의 악의적인 거래 및 사용이라는 구체적이고 널리 퍼진 애플리케이션 보안 문제를 다루었습니다. 이 백서는 또한 DBSC 및 DPoP와 같은 기술이 토큰 도난과 관련된 위협을 완화하는 방법과 이러한 기술이 FIDO 인증을 어떻게 보완하는지 보여주었습니다. FIDO와 함께 DBSC 및 DPoP를 사용하면 애플리케이션에 대한 전반적인 신원 사기 방지 기능이 향상됩니다.
