6. 로그인 방식 분석 (쿠키, Session, JWT)

강혜성·2023년 9월 25일
0

사이드 프로젝트

목록 보기
6/12

Vuetify를 통해 기본 메인 환경에 대한 구성은 끝났으므로, 로그인 화면을 구성하고 로그인 기능을 만들 예정.
로그인은 Cookie, Session, JWT를 이용하는 방식이 있으며, Spring Security, Redis를 이용한 Token 처리 등 다양한 방법이 있으므로 이를 정리한 후 구현.

1. 로그인 방식

사용자가 로그인화면에서 로그인을 수행할 경우 기본적으로 다음과 같은 방식으로 수행된다.

  1. 로그인 정보를 입력 받는다.
  2. 로그인 정보를 서버에 전송한다.
  3. 서버는 로그인 정보를 수신한다.
  4. 인증 절차를 수행한다.
  5. 인증 결과를 클라이언트에 전송한다.

1.1. 인증/인가

인증 : 인증(認證, authentication)은 참이라는 근거가 있는 무언가를 확인하거나 확증하는 행위
인가 : 제3자의 법률적 행위를 행정청이 동의 · 승인의 형식으로 보충하여 그 법률상 효과를 완성시켜 주는 행정행위

Cookie, Session, JWT 방식 인증은 아래 링크 참고.

로그인에서 인증/인가

사용자가 로그인을 하는 행위는 인증에 해당하며, 로그인 정보를 토대로 자원에 접근할 수 있도록 하는 것이 인가에 해당한다.

일반적인 웹 서비스는 stateless 상태이므로, 서버에서 인가를 받을 경우 이를 저장하는 방식이 필요하다.(그렇지 않을 경우, 지속적으로 인증을 수행해야한다.)
(※ stateless : 서버로 가는 모든 요청이 독립접으로 수행)

1.2. Cookie를 통한 로그인

HTTP 쿠키란 하이퍼 텍스트의 기록서의 일종으로서 인터넷 사용자가 어떠한 웹사이트를 방문할 경우 사용자의 웹 브라우저를 통해 인터넷 사용자의 컴퓨터나 다른 기기에 설치되는 작은 기록 정보 파일을 일컫는다.

세션을 통한 로그인도 세션 정보(Session ID)를 Cookie로 저장하므로 Cookie를 통한 로그인이라 볼 수 있지만,
여기서 Cookie를 통한 로그인은 Cookie에 ID, PW 등을 Cookie에 직접 저장 해 지속적으로 인증하는 것을 의미한다.

HTTP 쿠키(웹 쿠키, 브라우저 쿠키)는 서버가 사용자의 웹 브라우저에 전송하는 작은 데이터 조각, 브라우저는 데이터 조각들을 저장해 놓았다가, 동일한 서버에 재 요청 시 저장된 데이터를 함께 전송한다.

Cookie를 통한 로그인 구현 시, 사용자의 로그인 정보를 저장하고 이를 서버에 전송하는 형태를 사용하게 된다. 이 경우 여러 보안 문제점을 가지게 된다.

  1. 쿠키 탈취 (Ex, XSS 공격)
  2. 쿠키 변조
  3. 세션 하이재킹
  4. 쿠키 평문 저장

쿠키는 클라이언트(브라우저)에 저장된다. 쿠키 기반 로그인에서 브라우저는 저장된 쿠키를 서버에 전송해 인가를 수행하게 된다. 이 쿠키는 인증을 위해 인증과 관련된 정보를 가지고 있어야 한다.

만약 쿠키를 탈취 당하게 된다면 인증 정보를 탈취 당한 것과 동일해 진다.
XSS(Cross-Site Scripting) 공격 기법을 통해 쿠키를 탈취할 수 있다. 보통 Cookie의 HttpOnly(XSS 방어) 및 Secure(Sniffing 방어) 설정을 통해 이를 예방 할 수 있다.

쿠키가 탈취되었고 ID, PW 같은 인증 정보가 평문으로 저장되었다면, 쿠키가 변경되어도 ID, PW를 통한 로그인이 가능해진다.

만약 세션 ID가 탈취되었다면, 이를 이용한 세션 하이재킹이 발생할 수 있다. (Session을 통한 로그인 구현 시)
HTTPS 프로토콜 사용과 세션에 만료 시간을 넣어 예방할 수 있다.

또한, 사용자가 쿠키 정보를 임의로 변경해 인가 및 권한 정보에 대한 공격 시도를 수행할 수 있다.

1.3. Session을 통한 로그인

Session?

세션(session)은 컴퓨터 과학에서, 특히 네트워크 분야에서 반영구적이고 상호작용적인 정보 교환을 전제하는 둘 이상의 통신 장치나 컴퓨터와 사용자 간의 대화나 송수신 연결상태를 의미하는 보안적인 다이얼로그(dialogue) 및 시간대를 가리킨다.

쿠키를 통한 ID, PW 전송 방식은 많은 보안 문제를 일으킨다. 인증 후 인가와 함께 사용자를 식별할 수 있는 고유값을 생성해 Cookie를 통해 주고 받는다면 ID, PW 같은 인가정보의 탈취는 예방할 수 있다.

다만, 이 경우에도 쿠키에 저장된 고유값을 탈취하면 Session Hijacking 기법을 통해 사용자 계정에 액세스할 수 있다.

Session 로그인

Session을 통한 로그인은

  1. 사용자가 로그인 요청
  2. 서버 인증 수행
  3. Session 정보 DB에 저장
  4. DB에 저장된 Session 정보를 사용자 Cookie로 전달

인증이 필요한 경우

  1. 사용자는 수신한 쿠키를 서버에 전달
  2. 서버는 수신받은 쿠키에 해당하는 Session ID를 확인
  3. Session ID와 유저를 확인해 인증

클라이언트와 서버의 세션 정보를 저장해야 하기 때문에 사용자가 많아 질 경우 부하가 많아진다. 단일 서버에서 다중 서버로 확장하게 될 경우 모든 서버가 세션에 대한 정보를 공유해야 하기 때문에 확장성 또한 좋지 않은 편이다.

1.4. Token을 통한 로그인

토큰 기반 인증(Token based Authentication)

토큰 기반 인증이란 사용자가 자신의 아이덴티티를 확인하고 고유한 액세스 토큰을 받을 수 있는 프로토콜을 말한다.
(※ 액세스 토큰은 많은 양의 데이터를 포함하는 작은 코드 조각입니다. 사용자, 권한, 그룹 및 기간에 대한 정보는 서버에서 사용자의 장치로 전달되는 하나의 토큰에 포함)

JWT (JSON Web Tokens)

RFC 7519 표준으로 당사자 간에 정보를 JSON 개체로 안정하게 전송하는 간결하고 독립적인 방법. 디지털 서명이 되어 있어 신뢰할 수 있다.

JWT Token을 이용하면 내용 저장 없이 전달 받은 토큰을 통해 인증을 수행하고 필요한 정보를 전달할 수 있다. JWT는 Header, Payload, Signature로 구성되어 있다.
Header는 토큰의 타입과 JWT를 서명하는데 사용한 알고리즘을 명시한다.
Payload는 유저의 정보 또는 추가 데이터에 대한 내용이 들어있다. 서명된 토큰의 경우 해당 정보들은 보호되지만 누구나 읽을 수 있다. 암호화 되지 않는 경우 민감 정보를 담아서는 안된다.
Signature 서버에서 토큰의 정보가 서버로부터 생성된 것인지 증명하기 위해 사용한다.

취약점

  1. none Attack : JWT 대표적인 공격 방식으로 Header 영역에 alg값을 통해 알고리즘을 명시. 일부 JWT 라이브러리들은 alg값에 none 등 비 서명 처리 시 서명 검증을 하지 않는 취약점을 가지고 있다. 이를 이용하면 Secret 값을 몰라도 임의로 토큰을 생성, 수정할 수 있다.
  1. Brute force attack : 대칭키와 서명을 비교하여 JWT를 무효화.
  1. JWT 도용 : 정상적으로 발급 된 JWT 토큰을 탈취당할 경우 해당 계정의 아이디, 비밀번호를 도용한 것과 같이 계정을 사용할 수 있다.서버 입장에서는 정상적인 JWT이므로 구분할 방법이 없다.
    JWT 탈취를 막기 위해서 Http Only Cookie에 JWT를 저장한다. 또한, 탈취 당할경우를 대비해 Access Token을 짧게 적용한 후, Refresh Token을 통해 Access Token을 새로 발급 받는 방식을 적용한다.
    Refresh Token 조차 탈취 당할 경우 Access Token과 Refresh Token의 1:1 맵핑을 확인하는 등 여러가지 방법으로 기존 토큰을 만료시키는 방법을 사용할 수 있다. 다만 JWT를 임의로 만료시키는 방법은 없으므로 만료시간 만큼 DB에 저장하여 관리한다.

1.5. OAuth를 통한 로그인

OAuth, Open Authorization

인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조일 가능성이 매우 많다.

기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예를 들면 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다.

OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

OAuth 2.0의 동작 메커니즘

클라이언트 : 앱. 휴대기기 또는 기존 웹 앱에서 실행되는 앱. 앱은 리소스 소유자를 대싱하녀 리소스 서버에 요청을 보낸다.

리소스 소유자 : 최종 사용자. 리소스에 대한 액세스 권한을 부여할 수 있다.

리소스 서버 : Facebook, Google, Twitter와 같은 서비스. OAuth 토큰 검증이 필요할 때마다 API 요청을 처리하는 리소스 서버.

승인 서버 : OAuth 2.0 사양을 준수하며 구현되며 액세스 토큰 발급을 담당.

보호된 리소스 : 리소스 소유자가 소유한 데이터. (연락처, 계정 정보 등)

참고자료

profile
강혜성
이전 포스트

5. Vue 화면 디자인

다음 포스트

7. 로그인 화면 구성

0개의 댓글