JWT를 localStorage 또는 쿠키에 저장해야합니까? [복제]


101

JWT를 사용하여 REST API를 보호하기 위해 일부 자료 (이 가이드 및이 질문 등 )에 따르면 JWT는 localStorage 또는 Cookies에 저장할 수 있습니다 . 내 이해를 바탕으로 :

  • localStorage 는 XSS의 영향을받으며 일반적으로 민감한 정보를 저장하지 않는 것이 좋습니다.
  • 쿠키 를 사용하면 XSS의 위험을 완화하는 "httpOnly"플래그를 적용 할 수 있습니다. 그러나 백엔드의 쿠키에서 JWT를 읽으려면 CSRF를 받게됩니다.

따라서 위의 전제에 따라 JWT를 쿠키에 저장하는 것이 가장 좋습니다. 서버에 대한 모든 요청에서 JWT는 쿠키에서 읽고 Bearer 체계를 사용하여 Authorization 헤더에 추가됩니다. 그러면 서버는 요청 헤더에서 JWT를 확인할 수 있습니다 (쿠키에서 읽는 것과 반대).

내 이해가 맞습니까? 그렇다면 위의 접근 방식에 보안 문제가 있습니까? 아니면 실제로 처음부터 localStorage를 사용하여 벗어날 수 있습니까?



@ lrn2prgrm은 (상태 비 저장) JWT (상태 저장) 세션 의미를 함께 사용해서는 안됩니다 .
ozanmuyes

답변:


57

@ pkid169가 말한 기사에서 언급 한 XSRF Double Submit Cookies 방법이 마음에 들지만 기사에서 말하지 않는 한 가지가 있습니다. 공격자가 할 수있는 일은 CSRF 쿠키 (HttpOnly가 아님)를 읽는 스크립트를 삽입 한 다음 JWT 쿠키가 자동으로 전송되는이 CSRF 토큰을 사용하여 API 엔드 포인트 중 하나에 요청하는 것이므로 여전히 XSS로부터 보호되지 않습니다.

따라서 실제로는 여전히 XSS에 취약합니다. 공격자가 나중에 사용하기 위해 JWT 토큰을 훔칠 수는 없지만 XSS를 사용하여 사용자를 대신하여 요청할 수 있습니다.

JWT를 localStorage에 저장하든 http 전용이 아닌 쿠키에 XSRF 토큰을 저장하든 관계없이 둘 다 XSS에서 쉽게 얻을 수 있습니다. HttpOnly 쿠키의 JWT조차도 고급 XSS 공격에 의해 잡힐 수 있습니다.

따라서 Double Submit Cookies 방법 외에도 콘텐츠 이스케이프를 포함하여 항상 XSS에 대한 모범 사례를 따라야합니다. 이는 브라우저가 원하지 않는 작업을 수행하게하는 실행 코드를 제거하는 것을 의미합니다. 일반적으로 이것은 자바 스크립트가 평가되도록하는 // <! [CDATA [태그 및 HTML 속성을 제거하는 것을 의미합니다.


11
HttpOnly 쿠키의 JWT를 어떻게 잡을 수 있는지 명확히 할 수 있습니까? XSRF 토큰이 XSS에 의해 손상되면 XSRF에서 사용할 수 있지만 실제로는 스스로 잡을 수 있습니까?
Jacek Gorgoń

1
이 글이 오래된 글이라는 것을 알고 있지만 몇 가지 질문을하고 싶습니다. 잘 만들어진 스크립트가 localStorage와 쿠키를 모두 읽을 수 있다는 의미입니까? 그렇다면 브라우저에 JWT를 저장하는 위치에 관계없이 JWT를 도난 당할 수 있다고 가정하는 것이 안전합니까? 그런 다음 JWT에만 의존하는 것이 매우 위험하다고 생각합니다.
Hiroki

2
"HttpOnly 쿠키의 JWT조차도 고급 XSS 공격에 의해 포착 될 수 있습니다." 거짓입니다. 이를 수정하기 위해 원본 게시물을 수정했습니다.
java-addict301

"HttpOnly 쿠키의 JWT조차도 고급 XSS 공격에 의해 잡힐 수 있습니다."누군가 쿠키를 자신의 서버로 전송하여 잡는다고 상상할 수 있습니다. 이를 위해 그는 자격 증명 플래그의 적절한 값으로 가져 오기를 사용할 수 있습니다. 여기서 주된 문제는 CORS 보호이지만 어떤 상황에서는 가능하다고 생각합니다.
bartnikiewi.cz

"내 CSRF 쿠키를 읽는 스크립트 삽입 (HttpOnly가 아님)" Html.AntiForgeryToken()ASP.NET MVC 의 기본 구현은 CSRF 토큰에 HttpOnly 쿠키를 사용합니다. 나는 당신이 것 같아요 여전히 특정 XSS에 취약하지만,이 언급 할 가치라고 생각했다.
Lovethenakedgun

21

Stormpath 의 적시 게시물은 내 요점을 정교하게 설명하고 내 질문에 답했습니다.

TL; DR

쿠키에 JWT를 저장 한 다음 내가 언급 한 모든 요청에 ​​대해 Authorization 헤더에 JWT를 전달하거나 기사에서 제안한대로 백엔드에 의존하여 CSRF를 방지합니다 (예 : xsrfTokenAngular의 경우 사용 ).


2
안녕하세요, 이것이 올바른지 확실하지 않지만 컨트롤러에 CrossOrigin을 구현할 때 쿠키를 사용하여 jwt를 저장하는 데 몇 가지 특별한 단점이 있습니까? 이는 내 서버 앱이 다른 위치에 있고 다른 도시에 위치한 클라이언트 앱에서 API를 사용합니까? 많은 웹 서비스 공급자가 쿠키 사용을 자제하는 이유가 아닌가요?
valik

CrossOrigin은 물리적 위치를 의미하지 않습니다. 다른 도메인에서 오는 요청을 나타냅니다. .net core에서 CORS를 사용하기로 결정할 때 허용 할 도메인을 지정합니다. 허용 할 헤더 등
Brian Allan West

11
  • 토큰을 LocalStorage 또는 SessionStorage에 저장하지 마십시오. 이러한 토큰은 자바 스크립트에서 읽을 수 있으므로 XSS 공격에 취약합니다.
  • 귀하의 토큰을 쿠키에 저장하지 마십시오. 쿠키 (HttpOnly 플래그 포함)가 더 나은 옵션입니다. XSS에 취약하지만 CSRF 공격에 취약합니다.

대신 로그인시 액세스 토큰과 새로 고침 토큰의 두 가지 토큰을 전달할 수 있습니다. 접근 토큰은 자바 스크립트 메모리에 저장하고 새로 고침 토큰은 HttpOnly 쿠키에 저장해야합니다. 새로 고침 토큰은 새 액세스 토큰을 만드는 데만 사용되며 더 이상은 없습니다.

사용자가 새 탭을 열거 나 사이트 새로 고침시 쿠키에 저장된 새로 고침 토큰을 기반으로 새 액세스 토큰 생성 요청을 수행해야합니다.

또한이 기사를 읽는 것이 좋습니다 : https://hasura.io/blog/best-practices-of-using-jwt-with-graphql/


6
새로 고침 토큰을 액세스 토큰으로 처리 할 수 ​​있는데 왜 복잡성이 추가 되었습니까? 어떻게이 방법을 더 내 접근으로 토큰을 표시 해주고 주어진 안전 secure, samesite: strict, http-only?
Charming Robot

더 안전하지 않습니다
Chris Hawkes

2

기존 쿠키를 이용하는 CSRF 공격을 방지하기 위해 SameSite지시문을 사용하여 쿠키를 설정할 수 있습니다 . lax또는로 설정하십시오 strict.

이는 아직 초안 이며 2019 년 현재 모든 브라우저 에서 완전히 지원되지않지만 데이터의 민감도 및 / 또는 사용자가 사용하는 브라우저에 대한 제어에 따라 실행 가능한 옵션이 될 수 있습니다. 지시문을로 설정 SameSite=lax하면 " '안전한'... HTTP 메소드를 사용하는 최상위 탐색"이 허용됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.