OAuth2.0PKCE와 ~ State의 차이점

개시하다
OAuth2.0의 확장 방법이 당연해지고 있습니까?PKCE 요약
이른바'PKCE'
PKCE는'Proof Key for Code Exchange by OAuth Public Clients'의 약칭으로, 인가코드 횡취 공격에 대응하기 위해 OAuth2로 구성됐다.0의 확장 사양입니다.
여러분들이 제일 좋아요?RFC 7636에 정의되어 있습니다.
RFC에서도 읽기 방법을 정의하고 PKCE도 정의합니다.
PKCE, pronounced "pixy"
그래서'PKCE'는'픽스'로 읽는다.
※ 포테이토칩은 아니다.
인증 코드를 가로로 추출하는 공격
이 확장 방법은'인정 코드 횡취 공격'대책을 위한 방법이기 때문에 우선 이 RFC 대책에 대한 공격을 귀결시킨다.
이 공격에는 몇 가지 전제가 있다.

OAuth2.0의 승인 코드 프로세스 사용

Public 고객

(기본적으로) 스마트폰 앱 구상

첫 번째, 인정 코드 횡취 공격의 이름으로 관찰하고 싶은데 문제가 없습니다.
두 번째 Public 고객은 기밀 유지가 불가능한 고객을 말합니다.예를 들어 자바스크립트가 쓴 웹 페이지, 로컬 응용 프로그램처럼 자원 관리자 옆에서 실행되는 응용 프로그램이다.이 프로그램들은 기본적으로 사용자의 손에 프로그램의 모든 원본 코드를 가지고 있는데 거기에도 클라이언트 기밀이 기재되어 있기 때문에 기밀을 유지할 수 없다.
세 번째는 스마트폰 앱을 구상하는 것이다.
나는 설명한 후에 어떻게 설명된 인정 코드를 얻었는지 설명한 후에 더욱 쉽게 이해할 수 있을 것이라고 생각한다.
횡취 방법
일반적인 인증 코드 허가 절차는 아래 그림과 같다.

라이선스 코드 라이선스에서 사용자가 인정한 후에 ③의 리셋 단점을 통해 연합 승인 코드를 통과한다.
스마트폰 앱의 경우 이 리디렉션 엔드포인트는 앱 설치자가 결정하는 URL 시나리오를 리디렉션한다.
iOS에서는 동일한 URL Scheme을 사용하는 여러 응용 프로그램을 추가할 수 있습니다.따라서 공격 대상의 휴대전화에 악의적으로 인정 코드를 가로채는 앱을 넣으면 비교적 간단하게 허가 코드를 받을 수 있다.

이렇게 전제가 일치하면 인정코드를 뺏기게 된다.
그리고 공격자의 앱에는 피해자의 토큰링크가 연결된다.
선점 대책
빼앗긴 것은 ①에서 요청한 앱과 ④에서 Token을 요청한 앱을 검증할 수 없다는 것이다.
이 두 개가 같은 클라이언트에서 온 것으로 확인되면 악의적인 앱에 접근카드를 보내지 않고 정확한 앱만 접근카드를 발행할 수 있다.
우선 해시 값code_challenge을 ①의 승인 엔드포인트에 보냅니다.
hash의 원시값code_verifier을 ④의 영패 단점으로 승인 서버에 공급값을 검증합니다.
권한 수여 서버는 첫 번째 권한 수여를 요청한 클라이언트와 영패 노드를 성공적으로 호출한 클라이언트가 동일하다는 것을 검증합니다.

이렇게 되면 방금 횡취 허가 코드의 공격자는 다음과 같은 상태가 된다.

첫 번째 승인 요청이 생성된 휴대전화 앱code_challenge에서 생성됐기 때문에 횡취하려는 공격자의 앱은 최초code_challenge에 산열된 원시치를 모른다.
그래서 공격자는 코드입니다.verifier의 검증이 실패하여 가로로 취할 수 없는 상태가 되었습니다.
PKCE 한계
조금 말씀드리지만, PKCE의 대책 범위는 제한적입니다.PKCE의 전제는 공격자의 응용 프로그램이 첫 번째 해시 값code_challenge을 모른다는 것이다.
예측 가능한 값(동일값 사용 등)일 경우 이 절차를 사용해도 무허가 코드를 가로채는 대책이 되지 않는다는 것이다.
OAuth2입니다.이것은 0의 한계라고 생각하지만 서버를 인정하는 데 있어서 어떤 최신 규격을 실시하든지 고객측에 의뢰하여 실시한 것이기 때문에 절대 보호할 수 있는 것이 아니라고 생각하기 때문에 설계해야 한다.
PKCE가 CSRF 대책이 될 수 있을까
그럼 원래의 화제로 돌아가자.
이 규격은 원래는
- OAuth2.0의 승인 코드 프로세스 사용
- Public 클라이언트
- (기본적으로) 스마트폰 앱을 구상
전제로 현재 CSRF의 대안인 PKCE가 활용되는 곳이 늘고 있다.
최근의 OAuth2.0을 위해 확장 방법에 따라 디자인한 내용을 썼다
Best Current Practice(BCP).
그 가운데
Clients utilizing the authorization grant type SHALL use PKCE [RFC7636] in order to (with the help of the authorization server) detect and prevent attempts to inject (replay) authorization codes into the authorization response.
although PKCE so far was recommended as a mechanism to protect native apps, this advice applies to all kinds of OAuth clients, including web applications.
라이선스 코드 라이선스를 사용하는 고객은 PKCE(라이선스 서버의 PKCE 규격을 빌려)를 사용하여 인증 라이선스 도용 시도를 검측하고 방지해야 한다.
그동안 PKCE는 로컬 애플리케이션을 보호하는 메커니즘으로 추천됐지만, 이 제안은 웹 애플리케이션을 포함한 모든 유형의 OAuth 클라이언트에 적용된다.
번역
이런 견해가 있다.
지금까지 CSRF 대책으로는 일반적으로 RFC 6749에 기재된state에서 대책을 강구했으나 BPC에서도 PKCE를 사용해 대응한다는 내용이 기재됐다.
state와 CSRF 대책에 관해서는 과거 나의 Qita가 비교적 이해하기 쉽다고 생각한다저편.
OAuth2.0곳의 CSRF 공격은 위의 그림에서 보듯이 ①인정단점을 관건적인 클라이언트와 ③인정단점에서 인정결과(인정코드)를 받은 클라이언트가 변화를 발견하지 못하고 절차를 전진했기 때문이다.
PKCE를 사용하는 절차라면 공격자의 방문 영패는 공격자의 클라이언트와 연결되지 않습니다.

이에 따라 PKCE는 CSRF 대책을 진행할 수 있게 됐다.
CSRF 대책인 State와 PKCE의 차이점
이렇게 되면 의문이 생기고 스테이트와 PKCE가 어떻게 다른지 등 의문이 떠오를 것 같다.
state와 PKCE의 차이점은 검증의 바디입니다.
state의 경우 고객측은 비준 후 단점에서 고객이 받은'state'를 다시 지정하는 것을 검증하고 있습니다.
이에 비해 PKCE는 토큰요청을 통해'코드 챌린지'를 인정 코드와 함께 발송해 인정 서버에 수치 검증을 한다.

State의 설치에서 권한 수여 서버는 클라이언트가 정확하게 설치되었는지 모르지만 권한 수여 서버를 통해 같은 사무를 검증하면 클라이언트 측의 설치에 의존하지 않고 CSRF 대책을 실행할 수 있다.
(말은 그렇지만 PKCE의 경계에서 서술하는 상황이 존재하기 때문에 CSRF 대책을 완전히 집행할 수 없습니다.)
총결산
PKCE가 대응할 수 있는 무허가 코드 공격부터 CSRF 공격까지 대책.
OAuth2.진짜로 0을 배우기 시작했을 때'PKCE'가 뭐냐!"state"랑 달라요!
그러니 차이를 고민하는 사람들이 이해할 수 있었으면 좋겠다.