HTTP 헤더를 통해 액세스 토큰을 전송하는 것이 안전합니까?

첫 번째 RESTful 웹 서비스이며 보안 문제가 걱정됩니다. HTTP 헤더를 통해 액세스 토큰을 전송하는 것이 안전합니까? 예를 들면 다음과 같습니다.

POST /v1/i/resource HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Api-key: 5cac3297f0d9f46e1gh3k83881ba0980215cd71e
Access_token: 080ab6bd49b138594ac9647dc929122adfb983c8

parameter1=foo&parameter2=bar

연결이 완료되었습니다 SSL. 또한 scope모든 속성에 대해 정의해야 할 사항access token

— ahmedsaber111
소스

답변:

HTTP를 통해 액세스 토큰 헤더를 전송하는 경우 man-in-the-middle 공격에 취약합니다.

HTTPS를 통해 액세스 토큰 헤더를 전송하면 요청이 보안 연결을 통해 터널링되므로 클라이언트 외에는 아무도이 토큰을 볼 수 없습니다.

— 코드 아트
소스

조잡한 클라이언트는 SSL을 사용하더라도 MITM 공격에 취약 할 수 있습니다.

— ott--

예를 들어 주시겠습니까?

— CodeART

클라이언트를 제어하지 않으면 클라이언트 측 보안을 보장 할 수 없지만 이는 거의 사실입니다.

— Matt

@CodeWorks 대부분의 브라우저는 SSL 인증서가 리소스에 대해 잘못된 경우에도 사용자에게 HTTPS 리소스에 연결할 수있는 기회를 제공합니다. 이것은 아마도 브라우저 제작자들이 해왔 던 가장 끔찍한 일 중 하나이며, 본질적으로 MITM 공격을 수용하도록 제공하고 있습니다.

— 로스 패터슨

그런 다음 특정 MITM 인증서를 클라이언트의 루트 인증서 목록에 추가해야합니다. 그렇지 않으면 HTTPS 경고를 문자 그대로의 "울프"로 줄여서 A) 사용자가 완전히 무시하도록 사용자를 교육시키고 B) 실제 악의적 인 MITM 공격과 구별하기가 어렵습니다 (A 때문에 불가능).

— Nick T

SSL을 사용할 때 전송 된 데이터가 암호화되므로 http 헤더를 통해 액세스 토큰을 전송하는 데 심각한 문제가 없습니다. 즉, 해당 클라이언트와 요청에 응답 한 서버가 해당 클라이언트를 이해할 수 있음을 의미합니다. 타사의 데이터를 이해합니다.

다른 것은 access token시간 기반이므로 특정 기간 동안 수명을 가지므로 나중에 사용할 기회가 없습니다.

— 애쉬 윈
소스

-1

고려해야 할 것도 캐싱입니다.

백엔드는 동일한 GET / POST 매개 변수를 사용하지만 동일한 헤더 액세스 토큰을 사용하여 동일한 URL에 대한 여러 호출을 볼 수 있으며 컨텐츠를 캐시하고 모든 본문으로 이동할 수 있다고 간주합니다.

— 토마스 데코
소스