쿠키 (Cookie)
Key : Value 형식의 문자열
- 사용자 브라우저에 저장 (브라우저간 공유 불가)
- 용량 제한 있음 (4KB 이하)
- 사이즈가 커질수록 네트워크 성능 부하
- 서버에 반복 요청시 쿠키 값을 그대로 보내기에 조작 및 유출 위험성 높음
동작원리
- 클라이언트가 인증 요청
- 서버는 클라이언트에 저장할 정보를
응답 헤더(Set-Cookie)에 담음 - 클라이언트는 요청때 마다 요청 헤더의
Cookie에 저장된Cookie를 담아 보냄 - 서버는
Cookie에 담긴 정보를 통해 클라이언트가 누군지 식별
세션 (Session)
쿠키 인증의 보안적 이슈 보완, 사용자 민감정보를 서버에 저장 및 관리
- 해커가 세션 id를 탈취하여 사용자인척 위장 가능---(서버에서 ip특정으로 해결가능)
- 서버에서 세션저장소를 따로 이용하기에 요청이 많으면 서버 부하가 심해짐
동작원리
- 클라이언트가 로그인
- 서버는 사용자 확인 후, 세션 저장소에 세션 ID를 저장
- 서버는 응답 헤더에 세션 ID를 담아 전달
- 클라이언트가 요청 때마다 세션 ID 담긴 Cookie를 함께 보냄
- 서버는 세션 저장소에 세션 ID와 일치하는지 확인
- 세션 ID 일치하면 응답
토큰 (Token)
사용자를 인증, 식별하기 위한 정보를 암호화시킨 토큰
- 클라이언트에 인증 토큰을 저장하여 서버 부담을 덜어줌
- Header, Payload, Signature로 구성
- Payload 자체는 암호화 하지 않음 --> 사용자 민감 정보 담을 수 없음
- 토큰 탈취시 대처 어려움 --> 만료기한을 두어 어느정도 해결 가능
- 토큰 자체 데이터가 길어서 인증 요청이 많을 수록 네트워크 부하
- Header : 어떠한 알고리즘으로 암호화 할 것인지 어떤 토큰을 사용할 것인지에 대한 정보 포함
- Payload : 인증에 필요한 최소한의 정보, 전달 하려는 정보 (사용자 민감 정보는 X)
- Signature :
Header와 정보를 합친 후, 서버가 지정한 Secret key로 암호화 시켜 토큰을 변조하기 어렵게 만듬
⭐️ JWT
웹 상에서 정보를 Json 형식으로 주고 받고자 표준 규약에 따라 암호화한 토큰
- 클레임 토큰 기반
사용자 인증에 필요한 모든 정보를 토큰 자체에 담고 있어서 별도의 인증 저장소가 필요하지 않음- 일반토큰 : 검증 관련 정보를 서버에 저장 --> DB에 항상 접근 필요 (부담 발생)
JWT 동작원리
- 사용자 로그인
- 서버는 DB에 사용자 있는지 확인
- 확인이 되면 요청 확인 후, Secret key를 통해 토큰 발급
- 발급한 토큰을 클라이언트에 전달
- 서비스 요청, 권한 확인 위해 헤더에 JWT를 요청
- 데이터 확인, JWT에서 사용자 정보 확인
- 클라이언트 요청에 대한 응답과 데이터 전달
⭐️ JWT 변조 공격 대처
공격
- Signature Striping : alg 클레임을 Null로 변조하는 공격
--> 일부 JWT 라이브러리들에서 alg가 None인 토큰을 유효한 토큰으로 인식하는 허점 이용
- 사용자가 입력한 값을 DB에 저장, Front에서 출력하는 구조를 가진 웹 게시판에서
<script>태그 입력시 공격 성립 --> 일반 쿠키, 세션 스토리지에 저장한 토큰 탈취
대처
Access_token의 유효기간을 짧게 설정하고,Refresh_token발급
Access_token에 비해 긴 만료기한, 노출되면 안되므로 DB에 저장- 원리
- 사용자 인증 요청시
Access_token이 만료되었을 경우, HTTP 요청 헤더의Refresh_token과 DB에 저장된Refresh_token을 비교 후, 토큰이 동일하면 새로운Access_token을 발급 해줌
- HTTPS 통신에서만 쿠키 전송할 수 있게 하기
- HTTP 헤더 플래그
Secure: HTTPS에서만 쿠키 전송가능HttpOnly: 오로지 서버로만 전송(js의 document.cookie로 접근 불가)SemiSite: 쿠키가 교차 도메인 전송 차단 (CSRF에 대해 보안)
발전하는 꿈나무 개발자 / 취준생