세션, 토큰, JWT, CSRF 설명

|

요약

JWT : JSON Web Tokens – jwt.io

세션과 토큰

  • 인증 (Authentication)
  • 권한 부여 (Authorization)

한번 로그인을 하고 그 상태가 유지하기 위해 권한 부여(Authorization) 가 사용됩니다.
권한 부여를 취득한 유저는 로그인 한 사용자만 접속할 수 있는 기능을 사용할 수 있습니다. 이때 사용할 수 있는 것이 세션과 JWT입니다.

세션

세션은 브라우저와 웹 서버가 연결되어 브라우저가 종료될 때가지의 시점입니다.
브라우저를 통해 서버에 접속할 때 서버는 세션 id 를 쿠키에 담아 되돌려줍니다. 사용자는 세션 id를 담은 쿠키인 세션 쿠키를 이후 요청부터 계속 함께 전달아여 서버가 클라이언트를 식별할 수 있게 합니다.
이를 세션 인증 방식이라고 합니다.

클라이언트가 HTTP 요청 할 때 쿠키에 ID가 없으면 서버는 세션 ID를 생성 한 다음 쿠키로 돌려줍니다. 다시 HTTP 요청을 할 때 쿠키를 보내기 때문에 서버에서는 세션 ID를 통해 클라이언트를 식별할 수 있게됩니다.

쿠키와 세션 차이점

쿠키는 클라이언트에 저장되고 세션은 서버에 저장됩니다.
이 때 세션이 쿠키를 사용하는 방식으로 볼 수 있습니다.

차이점

쿠키는 영구 쿠키와 세션 쿠키가 있어 만료시기가 브라우저에 따라 다르게 저장됩니다.
예로 로그인에 대한 정보를 담을 때 쿠키를 사용하면 클라이언트에 노출되어 위험합니다. 그래서 서버에 저장되는 세션을 사용합니다.

세션의 단점

추가로 쿠키는 클라이언트가 자료를 저장하는 방식이기에 서버의 부담이 적지만 세션은 유저 사용자 수에 따라 세션DB와 서버를 확장해야 할 수도 있습니다.

토큰

보안 객체의 접근 관리에 사용되는 객체, 장치

API 요청을 할 때 어떤 권한을 가지고 있는지 정확히 모를 때가 많습니다.
그것을 판별하기 위해서는 비밀번호를 알고 있는지, 열쇠를 가지고 있는지를 파악하고 문을 열어주어야 하는데, 이 때 사용하는 것이 토큰이죠.

  • Access Token : 접속할 때 토큰 값을 부여하여 접근 권한을 부여합니다.
  • Refresh Token : 엑세스 토큰을 보완하였으며 유효기간을 가지고 있습니다.

이 두가지는 똑같은 형태의 JWT(JSON Web Token) 로 불리며, 이 둘의 쓰임새는 다릅니다.
그래서 접근할 때 Access Token 과 Refresh 토큰 두가지를 같이 발급받아 관리하게 됩니다.

리프레쉬 토큰의 유효기간이 만료되면 사용자는 새로 로그인해야 합니다.

각 토큰의 만료 기한

  • Access Token : 30분 내외
  • Refresh Token : 14일 ~ 30일 내외

슬라이딩 세션 전략

세션을 지속적으로 이용하는 유저에게 자동으로 만료 기한을 늘려주는 전략입니다. 이는 은행 사이트에서 로그인을 해보면 알아볼 수 있는데요, 3분의 시간동안 아무것도 하지 않다가 이벤트가 발생하면 새로운 Access Token 을 발급해주는 방식입니다.

이렇게 만들게 되면 편의성을 잡을 수 있습니다. 보안성은 위험할 수 있기 때문에 암호화 되어 있다고 해도 개인정보를 절대로 담으면 안됩니다.

웹 표준과 보안성

이러한 토큰의 경우는 보안에 직접적인 연결점에 있기 때문에 안전하지 않습니다.
왜냐하면 암호화 방식도 모두가 알고 있고, 키값이 없다고 해도 위험할 수 있기 때문입니다.

rfc-ediror 의 8715 문서는 비교적 최신 일자인 2020년에서 암호 변환 방식을을 HS256(HMAC-SHA256) 와 같은 다른 것으로 사용하는 것을 권장하고 있습니다.
내용 중에는 UTF-8 로 인코딩하는 것을 권장하기도 합니다.

hs512

None Type Attack 방어

알고리즘 영역에 alg=none 과 같은 값을 통해 공격을 당할 수도 있습니다. 현재 jwt.io 에서 권장하는 라이브러리는 해당 취약점이 모두 패치되었습니다. 테스트를 하려면 여기서 할 수 있습니다

JWT 만료 이전에 세션 무효화를 허용하는 경우 더이상 토큰 표명(Token Assetion)을 신뢰할 수 없습니다. 이 때는 데이터 저장소(Data Store)에 대해 검사되어야 합니다.

  • JWT 헤더만으로 유효성을 확인하지 말 것
  • 알고리즘 타입 검증(필드에만 의존하지 말 것)
  • 적절한 키 크기 사용
  • 예측할 수 없는 난수 키를 사용


세션과 같이 사용함으로서 값을 대차대조해 보안성을 높이는 등의 방안이 필요합니다.

무차별 대입 공격

무차별 대입 공격(brute-force attack) 을 하면 일반 PC로도 몇초 걸리지 않게 암호값을 알아낼 수도 있습니다. 이러한 공격을 방어하기 위해 공격을 시뮬레이션 할 수 있는 오픈소스 도 있습니다.

해결방법은 다음과 같습니다.

  • JWT 토큰 생성 서버를 따로 관리합니다.
  • 서버의 세션을 활용합니다.
  • 어려운 암호화를 위해 자주 사용하지 않는 값(특수문자 등) 을 포함시킵니다.
  • 토큰의 유효기간을 최대한 짧게 만듭니다.

CSRF 토큰

사용자 의도에 관계없이 행해지는 공격기법

Cross Site Request Forgery

CSRF 토큰은 해킹을 방어하기 위해 만든 방법입니다. 임의의 난수를 생성하고 세션에 저장합니다.
그리고 사용자의 매 요청마다 해당 난수 값을 포함시켜서 전송하고
백엔드에서는 요청을 받을 때마다 세션에 저장된 토큰값과 요청 파라미터에 전달된 토큰값이 같은지 검사합니다.

Trust Tokens

구글이 만든 JWT 대체 토큰입니다. 그러나 구글이 만들었다고 해도 공격방식이 다양하기 때문에 무조건 안전하지 않을 수 있습니다.

사용법 : https://github.com/WICG/trust-token-api#sample-api-usage
메뉴얼 : https://web.dev/i18n/ko/trust-tokens/

참조

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다