▏시작하는 말
그간 사이드 프로젝트를 진행하면서 보안에 대해 신경 쓸 생각을 하지 못했다. 아니, 더 솔직히는 중요함을 알면서도 귀찮아 생각하고 싶지 않았던 것이다. 그저 쉬운 방법인 세션 쿠키방식으로 구현했고, 사용하면서도 개념을 제대로 이해하려는 노력조차 없었다.
회사를 다니다 보니 보안에 대해 조금 더 깊게 생각해보게 되었고 그렇게 틈틈이 공부한 내용을 설명해보고자 한다.
▏인증 방식
HTTP는 stateless 성질로, 본래 정보를 유지하지 않는다.
클라이언트와 서버 사이에 통신이 필요할 때 그 순간 요청 / 응답을 하고, 완료되었다면 연결이 끊겨(connectionless) 매번 새로운 요청을 해야한다.
이는 HTTP 가 인터넷상에서 불특정 다수와 연결해야 하는 환경을 만들기 위해 설계되었기 때문이다.
만일 서버가 다수의 클라이언트들과 연결을 유지하고 있다면, 이를 위한 Resource가 많이 필요하게 되어 서버 관리 측면에서 단점으로 작용된다.
하지만, 웹 기술이 발달하고 그에 따른 수요가 발생하며 상태유지 (stateful) 기능이 필요해졌다.
예시로 메일을 읽고 답장을 할 때 초기의 HTTP 특징을 그대로 가지고 한다면,
로그인 > 메일 읽기 > 로그인 > 메일 답장 > ... 형식의 중복되는 과정을 거치게 된다.
이러한 불필요한 작업을 없애기 위해 한 번 인증하고 나면, 이를 일정시간 저장해 두어 같은 작업의 중복을 없애는 인증방식이라는 개념이 나왔다. 이것의 대표적인 3가지가 Cookie, Session, Token이며 지금부터 설명하고자 하는 내용이다.
▏쿠키 (Cookie) 란?
클라이언트의 브라우저에 바로 저장되는 파일이다.
풀어서 설명하자면, 클라이언트가 특정 웹사이트를 방문했을 때, 그 사이트의 서버를 통해 클라이언트의 브라우저에 기록하는 정보 파일이다. 사용자별로 각각의 브라우저에 정보를 저장하기 때문에 고유 정보 식별이 가능하다.
Cookie 인증방식
1. 클라이언트가 서버에 요청을 보낸다.
2. 서버는 응답을 작성할 때, 클라이언트 측에 저장할 정보들을 응답 헤더의 Set-Cookie에 key - value 형태로 담는다.
3. 클라이언트는 쿠키를 저장하고 있다가 서버에 재요청할 때 쿠키를 함께 전송한다.
4. 서버는 요청 페이지와 함께 쿠키를 전송한다.
# 서버는 쿠키에 담긴 정보를 바탕으로 해당 요청의 클라이언트가 누군지 식별할 수 있다.
장점
- 서버의 저장공간 절약
단점
- 보안 취약
네트워크를 통해 전달되기 때문에 중간에 탈취 우려가 있다.
- 트래픽 증가
쿠키에 대한 정보를 매번 HTTP Header에 붙여야 하기 때문에 클라이언트 수가 증가함에 따라 트래픽이 커진다.
Cookie의 용도
- ID저장, 로그인 상태 유지
- 일주일간 다시 보지 않기 / 오늘 하루 그만 보기
- 쇼핑몰 장바구니
▏세션 (Session) 이란?
앞서 설명한 Cookie의 단점 중 하나가 데이터가 브라우저에 저장되기 때문에 외부 공격에 취약하다는 점인데.
이를 보완하고자 등장한 것이 Session이다.
세션은 데이터를 브라우저가 아닌 서버에 저장한다.
예를 들어, 비밀번호와 같은 인증 정보를 쿠키에 저장하지 않고 사용자의 식별자인 session id를 저장한다.
서버에 이 session id에 해당하는 사용자의 정보를 저장한다.
Session 인증방식
1. 클라이언트가 서버에 요청을 보낸다.
2. 서버는 클라이언트별 세션을 생성해 서버 메모리에 저장한다.
세션 식별키인 Session id 를 기준으로 정보를 저장한다.
3. Session id를 Cookie에 담아 클라이언트에게 전달한다.
이는 브라우저에 저장되며 브라우저 종료 시에 사라진다.
4. 클라이언트는 재요청 시에 쿠키에 Session id를 담아 전송한다.
5. 서버는 받은 Session id로 세션을 식별해 응답한다.
장점
- 사용자가 임의로 정보를 변경하더라도 서버에서 본래의 정보를 가지고 있어 쿠키보다 비교적 안전하다.
- 서버 용량이 허용하는 한 저장 데이터에 제한이 없다.
단점
- 서버의 과부하
클라이언트 수가 증가하면 서버에 저장해야 할 session 또한 늘어나기 때문에 서버의 과부하를 야기할 수 있다.
- 서버 확장의 어려움
서버를 분산해서 운영할 경우, 한 개의 클라이언트를 위한 세션정보를 모두 가지고 있어야만 인증절차가 가능해진다.
▏토큰 (Token) 이란?
토큰 방식이란 암호화된 접근 권한이다.
보호해야 할 데이터들을 token으로 치환하여 본래의 데이터 대신 token을 기반으로 인증을 진행하는 방식이다.
특정 사이트에 로그인할 때로 예를 들어 보자. 사용자가 id와 pwd를 입력하면, 서버는 이를 검증한 후 사용자에게 '유효한 사용자다.'라는 토큰을 발행해 준다. 그럼 사용자는 이 토큰을 가지고 사이트에서 제공하는 기능들을 이용할 수 있게 되는 것이다.
토큰의 가장 큰 특징으로는 유효 시간이 있다. 유효시간을 정해두고 그 시간이 지나면 토큰이 만료되게 설정한 것이다.
이는 보안적인 측면에서 장단점이 있는데,
장점으로는 토큰의 유효 시간을 설명함으로써 만료된 토큰을 사용하는 공격으로부터 보호할 수 있다.
단점을 다른 인증방식과 비교해 보면
세션 / 쿠키의 경우 악의적으로 활용될 경우 쿠키를 삭제하면 되지만, 토큰의 경우는 한 번 발급되면 유효기간이 끝날 때까지 계속 사용 가능하기 때문에 위험하다.
이를 해결하기 위해 Refresh Token이라는 개념이 등장했는데, Access Token의 유효시간을 줄이고 Refresh Token을 새로 발급하면 보안을 조금 더 높일 수 있다.
# Access token
인증된 사용자가 api를 호출할 때 권한을 부여하는 데 사용된다.
# Refresh Token
Access Token을 갱신하기 위해 사용된다.
Token 인증방식
1. 클라이언트가 서버에 요청을 보낸다.
2. 서버는 해당 계정 정보를 검증한 후 클라이언트에게 signed token을 발급한다.
signed 란? 해당 토큰이 서버에서 정상적으로 발급된 토큰임을 증명하는 signature을 지니고 있다.
3. 클라이언트는 전달받은 토큰을 저장해 두고, 서버에 요청할 때마다 헤더에 해당 토큰을 함께 전달한다.
4. 서버는 토큰을 검증하고, 요청 데이터에 대한 응답을 보낸다.
장점
- 무상태 (Stateless)
유저의 인증정보를 서버나 세션에 담아두지 않는다
- 확장성 (Scalability)
클라이언트와 서버의 연결고리가 없기 때문에 session 인증구조와는 반대로 서버의 확장성이 높다.
단점
- 토큰 탈취의 위험성
암호화를 잘해놓았다고 해도, 해커에게 토큰 안에 들어있는 정보를 탈취당할 위험성이 있다.
- 토큰 유효기간의 단점
- 서버의 자원 낭비
토큰의 길이가 길기 때문에 인증이 필요한 요청이 많을수록 서버의 자원낭비가 발생한다.
▏참고자료
- https://sdy-study.tistory.com/44
'기초지식' 카테고리의 다른 글
| Spring Security란 ? (2) | 2023.04.26 |
|---|---|
| JWT (Json Web Token) 란 ? (0) | 2023.04.23 |
| Internet Explorer 11 지원 종료, Edge / Window11 전환 방법 (0) | 2022.06.10 |
| 형상관리 란? (0) | 2022.01.11 |
| Socket (소켓) 이란? (0) | 2022.01.05 |
댓글