HTTPS
(Hyper Text Transfer Protocol Secure Socket layer)
HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해 내용을 암호화하여 데이터를 전송하는 방법
중간자 공격에 취약한 HTTP와 달리 상대적으로 안전함.
HTTPS 프로토콜의 특징
- 암호화
- 일련의 정보를 임의의 방식을 사용하여 다른 형태로 변환하여 해당 방식에 대한 정보를 소유한 사람을 제외하고 이해할 수 없도록 '알고리즘'을 이용해 정보를 관리하는 과정
- 암호화된 데이터를 주고받기 때문에 인터넷 요청이 탈취되어도 내용을 알아볼 수 없음.
- 인증서
- 클라이언트가 응답과 함께 전달된 인증서 정보를 확인할 수 있음.
- 해당 인증서를 발급한 CA 정보 확인, 인증된 CA가 아니라면 경고창을 띄워 서버와 연결이 안전하지 않다고 말해줌.
Hashing
어떠한 문자열에 '임의의 연산'을 적용하여 다른 문자열로 변환하는 것
- Hashing 철칙
- 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
- 모든 값은 고유한 해시 값을 가진다.(충돌 저항성)
- 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.(쇄도 효과)
- 단방향이어야 한다.
Salt
암호화해야 하는 값에 '별도의 값'을 추가하여 결과를 변형하는 것
- 암호화만 해놓으면 해시된 결과가 늘 동일함. Decoding 해버리는 경우 방지
- 알고리즘이 노출되더라도 원본값을 보호할 수 있도록 하는 안전 장치
- 기존: (암호화 하려는 값) => (hash 값)
Salt 사용: (암호화 하려는 값) + (Salt용 값) => (hash 값)
- salt 사용 시 주의점
- salt는 유저와 패스워드 별로 유일한 값을 가져야 한다.
- 사용자 계정을 생성할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
- salt는 절대 재사용해서는 안 된다.
- Salt는 DB의 유저 테이블에 같이 저장되어야 한다.
Cookie
서버가 일방적으로 클라이언트에 데이터를 저장하는 작은 데이터.
현재는 web storage API에 저장하는 것을 권장
HTTP의 stateless(무상태성)을 stateful하게 보완
Cookie 등장 배경 => HTTP의 단점
HTTP 특징1. 무상태 프로토콜(Stateless) : 서버가 클라이언트의 상태를 보존하지 않음
장점) 서버 확장성 높음
단점) 클라이언트 식별 불가
HTTP 특징2. 비연결성(Connectionless) : 사용자의 요청에 대한 응답이 끝나면 연결 상태를 해제
장점) 서버 자원 절약
단점) 클라이언트 식별 불가
주로 언제 쓸까?
삭제하지 않으면 사라지지 않는 특성으로, 주로 장기간 저장해야 하는 옵션들
=> 30일 동안 로그인 상태 유지, 테마 등에 쓰임
Cookie 종류
영속 쿠키: 웹 브라우저가 종료되어도 지정한 날짜나 시간이 되어야 삭제
세션 쿠키: expores 또는 max-age를 명시하지 않고 브라우저가 종료되면 삭제
Cookie Options
- Domain: 서버와 요청의 도메인이 일치하는 경우 클라이언트에서 쿠키 전송
- Path: 서버와 요청의 세부경로가 일치하는 경우 쿠기 전송
- MaxAge or Expires: 쿠키의 유효기간 설정, 지정된 시간과 날짜 초과할 경우 쿠키는 자동 파괴
- HttpOnly: 스크립트의 쿠키 접근 가능 여부 결정 (script는 XSS 공격에 취약)
- Secure: Https 프로토콜에서만 쿠키 전송 여부 결정
- SameSite: CORS 요청의 경우 옵션 및 메서드에 따라 쿠키 전송 여부 결정
- Lax: Cross-Origins은 GET 메서드 요청만 쿠키 전송 가능
- Strict: Cross-Origins 쿠키 전송 불가, same-site만 쿠키 전송
- None: 모든 메서드 요청에 대해 쿠키 전송 가능-> 위험하기 때문에 https, secure 쿠키 옵션이 필요
Session
정보 교환을 하고 있는 기간 또는 그 상태(단방향X, 양방향)
중요 데이터는 서버에서 관리하고, 쿠키에는 이 데이터에 접근 가능한 유일한 암호화된 ID를 부여.
쿠키는 변조가 쉬운 반면, 세션은 더 다양한 검증을 거치므로 더 나은 보안성을 가짐.
사용자가 인증에 성공한 상태는 세션이라고 부름.
Session token
현재 세션을 식별하기 위해 생성되어 서버에서 클라이언트로 전송되는 고유 식별자
클라이언트에서는 session token을 쿠키에 저장 또는 GET/POST 쿼리의 매개변수로 이용
단점
쿠키를 이용하는 것이기 때문에 쿠키의 단점을 가짐 (XSS 공격 취약)
세션은 서버 측 메모리에 생성됨. 확장성의 한계가 존재함
하나의 서버에서만 접속 상태를 가지므로 분산에 불리 -> 토큰 활용
로그아웃 구현 방법
1) 서버의 세션 정보 삭제
2) 클라이언트의 쿠키 정보를 무효한 값으로 갱신(임의 삭제는 불가능 함)
Token, 토근 기반 인증
클라이언트에 인증 정보를 암호화한 상태로 보관하는 방식
JWT (JSON Web Token이 가장 대표적)
토근 기반 인증이 나오게 된 이유
세션 기반 인증: 매 요청마다 데이터베이스를 살펴보면서 가지고 있는 세션 값과 일치하는지 확인하는 것이 불편하고 부담스러움
JWT의 종류
- Access Token: 보호된 정보들 (유저 정보)에 접근할 수 있는 권한 부여에 사용됨.
- Refresh Token: Access Token의 유효기간이 만료될 때 새로운 Access Token을 발급 시 필요한 수단.
JWT 구조
- Header : 어떤 종류의 토큰인지, 어떤 알고리즘으로 암호화 할 지가 적혀짐
- Payload: 유저 정보, 정보 접근 권한 등의 정보가 담김.
- Signature: Header, Payload를 암호한 값 + 암호화에 쓸 salt
토근 기반 인증 절차
