3

이것은 this에 대한 후속 질문입니다. 나는 파이썬 2.7과 최신 Django OAuth2 Toolkit (0.10.0)을 사용하고Django Rest Framework 및 OAuth2 Toolkit을위한 추가 보호 레이어

, 장고 1.8 장고 REST 프레임 워크 3.3

일부 배경 : 인증 할 때
는, 클라이언트는 그 때마다 A를 사용하는 새로운 AccessToken을받을 수는한다 새 요청을 서버에 보냅니다. 이 AccessToken은 클라이언트 소유이며 요청시 Authorization 헤더를 사용하여 전송됩니다.

간단한 테스트는 인증 된 클라이언트에서이 액세스 토큰을 가져 와서 다른 컴퓨터의 간단한 HTTP 요청을 사용하여 Authorization header으로 보냅니다.
결과는이 새로운 "클라이언트"가 이제 원래 클라이언트와 마찬가지로 인증되었으며 그는 기꺼이 요청할 수있었습니다.

그래서이 문제는 다음과 같습니다
액세스 토큰 (세션 ID 또는 클라이언트의 IP 주소와 마찬가지로) 클라이언트 검증 모든 형태의 바인딩되지 않습니다. 클라이언트의 AccessToken을 가져 오거나 발견하거나 훔치거나 조회 할 수있는 사람은이 클라이언트 대신 가짜 요청 일 수 있습니다.

이 문제는 연구되었지만이 문제를 해결 한 사람을 찾을 수 없습니다. 어쩌면 나는 클라이언트를 인증 할 때 뭔가 잘못하고있는 것일까? 나는 약간의 통찰력을 사랑할 것이다. 어쩌면 간단한 구성, 내가 놓친 바로 사용할 수있는 솔루션 일 것입니다.

감사합니다.

답변

1

이 공격 방법을 재생 공격이라고합니다. This video by Professor Messer은 재생 공격을 설명합니다.

웹 브라우저의 투명성 때문에 이것을 극복하기 위해 클라이언트 측 (브라우저)을 구현할 수 없습니다.

당신이 할 수있는 일은 nonce를 사용하여 다이제스트 인증을 구현하는 것입니다.

암호화에서 논스는 한 번만 사용할 수있는 임의의 숫자입니다.

기본 구현은 다음과 같습니다.

enter image description here

  1. 사용자는 API 서버를 요청합니다.
  2. API 서버는 WWW-Authenticate 헤더의 HTTP 401과 nonce로 응답합니다. [nonce를 추적해야합니다] (작은 창에서 만료되도록 설정된 nonce가있는 JWT는 2 초 이하일 수 있습니다. 무국적자).
  3. 클라이언트는받은 nonce, 클라이언트 nonce 및 암호를 사용하여 요청에 서명하고 리소스를 다시 호출합니다.
  4. API 서버가 서명의 유효성을 검사합니다. 서명이 유효하면 요청이 승인됩니다.
  5. 공격자가 요청을 캡처하고 사용자를 속임합니다.
  6. nonce가 만료되었거나 '한 번만 사용됨'이므로 공격자의 요청이 거부됩니다.