참고
HTTP StateLess
NOTE
Http 프로토콜의 가장 큰 특징은 Stateless(상태없음)이다!
상태가 없으므로 어떤 서버에 요청해도 상관없다 (확장성에 유리)
한계점
•
초창기에는 이미 만들어진 정보만 제공하는 경우가 대부분이었다.
•
하지만 사용자가 많아지고, 다양화되면서 한계가 드러난다.
◦
ex) 쇼핑, 로그인시 서버는 클라이언트를 기억해야했다.
◦
⇒ 이를 위해 등장한것이 쿠키와 세션!
Cookie
NOTE
브라우저에 클라이언트의 상태를 저장하는 데이터의 형태!
쿠키에 데이터를 담아서 보낸다.
•
쿠키는 기본적으로 서버가 생성한다.
◦
클라이언트 최초 요청시 쿠키가 존재하지 않는다.
◦
서버는 응답과 함께 쿠키를 클라이언트에게 전달하고 이를 저장한다.
◦
클라이언트는 이후 요청부터 쿠키를 같이 전달한다.
◦
브라우저마다 생성된다.(브라우저가 다르면 다른 클라이언트로 인식)
쿠키의 사용목적
•
세션관리
◦
사용자 아이디, 접속시간, 장바구니 등의 서버가 알아야할 정보 저장
•
개인화
◦
사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다
•
트래킹
◦
사용자의 행동과 패턴을 분석하고 기록
쿠키의 도메인(Domain)
NOTE
쿠키에 도메인을 지정해서, 지정해준 특정 도메인에만 쿠키에 전달되고 접근할 수 있도록한다!
•
쿠키가 아무 사이트에 들어갈 때 마다 계속 생기면, 보안성에 문제가 발생한다.
◦
원하는 도메인에서만 쿠키가 생성되도록 도메인을 지정해줄 수 있다!
도메인 명시
•
명시한 문서 기준 도메인과 서브 도메인에서 모두 쿠키에 접근 가능하다.
◦
ex) domain = example.org
◦
example.gord에서 쿠키가 생성되고, 그 외 서브도메인(dev.example.org)에서 모두 전달된다.
도메인 생략
•
도메인을 생략하게 된다면, 현재 문서 기준 도메인에서만 쿠키에 접근가능하다.
◦
ex) example.org에서 쿠키가 생성되었다.
◦
example.org에서만 접근 가능하며, 서브 도메인에서는 접근이 불가능하다
쿠키의 경로(path)
NOTE
쿠키의 경로를 지정해서 지정해준 경로를 포함한 하위 경로 페이지에만 쿠키로 접근할 수 있다!
•
ex ) path = /home
◦
home 디렉토리를 포함한 그외 하위 디렉토리에서 모두 쿠키가 전달된다.
Cookie - 한계점
NOTE
쿠키 저장의 주체가 브라우저(클라이언트)측에 있다는 점이다!
•
쿠키 값은 임의로 변경이 가능하다.
◦
클라이언트가 쿠키를 강제로 변경할 수 있어 다른 사용자 정보를 볼수도 있음
•
쿠키에 보관된 정보는 훔칠 수 있다.
◦
만약 이름뿐 아니라 중요한 신용카드 정보가 있다면..?
◦
PC가 감염되거나, 네트워크 전송에 탈취될 위험이 존재한다.
•
[해결방법]
◦
쿠키에 중요한 값을 노출시키지 않고 예측 불가능한 임의의 토큰을 노출시킨다
서버에서 이를 매핑해 인식하고 서버에서 토큰 관리
◦
토큰은 해커가 임의의 값을 넣어도 찾을 수 없도록 예상 불가능해야 한다
◦
해커가 평생 토큰을 사용하는것을 막기위해 만료 시간을 짧게 잡는다.
또는 해킹이 의심되면 서버에서 해당 토큰을 강제로 제거한다.
Session
NOTE
쿠키와 달리 클라이언트의 상태를 서버에 저장한다!
첫 요청을 하면 response와 ssid(Session ID)를 발급한다.
•
Session Cookie를 활용한다.
session의 특징
•
웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장
•
웹 서버에 저장되는 쿠키(=session cookie,, 비유로 생각)
•
브라우저를 닫거나, 서버에서 세션을 삭제 했을 때만 삭제가 되므로, 쿠키보다 보안이
좋다
•
저장 데이터에 제한이 없다
•
각 클라이언트의 고유 Session ID를 부여한다
•
Session ID로 클라이언트를 구분하여 각 클라이언트 요구에 맞는 서비스 제공
동작방식
NOTE
값 추정이 불가능한 UUID를 키값으로 사용한다
cookie의 단점이었던 정보노출이 UUID로 인해 보안되고, 값을 사용할수 있게됨
•
[참고]
◦
회원과 관련된 정보는 클라이언트에게 전달 X (서버가 관리하기 때문)
▪
쿠키 값 변조
•
UUID 값으로 예상 불가능해짐
▪
쿠키에 대한 정보 탈취위험
•
세션ID가 털려도 중요한 정보가 없으니 상관 X
▪
쿠키 탈취후 사용
•
세션 만료 시간이 짧아 시간이 지나도 이용할수 없다
•
해킹이 의심되면 서버에서 세션 종료
Session 정보와 타임아웃 설정
NOTE
// 세션 데이터 출력
session.getAttributeNames().asIterator()
.forEachRemaining(name -> log.info("session name={}, value={}", name, session.getAttribute(name)));
log.info("sessionId={}", session.getId());
log.info("getMaxInactiveInterval={}", session.getMaxInactiveInterval());
log.info("getCreationTime={}", new Date(session.getCreationTime()));
log.info("getLastAccessedTime={}", new Date(session.getLastAccessedTime()));
log.info("isNew={}", session.isNew());
Java
복사
•
sessionId
◦
세션 id, 추정불가능한 랜덤 값
•
maxInactiveInterval
◦
세션 유효시간
•
creationTime
◦
세션 생성 일시
•
lastAccessedTime
◦
세션과 연결된 사용자가 최근 서버 접속 시간
◦
클라이언트에서 서버로 sessionId를 요청한 경우 갱신
•
isNew
◦
새로 생성된 세션인지 과거에 만들어져 클라이언트에서 서버로 sessionId를 요청해
조회된 세션인지에 대한 여부
server.servlet.session.timeout=60
Java
복사
application.properties에서 다음과 같이 설정하면 60초뒤 세션삭제됨
•
세션 타임아웃 설정
◦
사용자가 로그아웃을 호출한다 → session.invalidate() 호출해 바로 삭제
◦
하지만 대부분은 로그아웃하지 않고 바로 웹브라우저를 종료함
▪
이때 HTTP는 비연결성이므로 서버는 클라이언트가 브라우저 종료했는지를 모른다
▪
따라서 서버에서 언제 세션을 삭제해야하는지 판단하기 어려움
◦
이에 대한 대안으로 사용자가 서버에 요청한 가장 최근 시간을 기준으로 30분정도 세션을 유지시킨다
▪
session.getLastAccessedTime() : 최근 세션 접근시간