개념 사전 · 개념
웹 세션
웹 세션 · Session · 로그인 세션
은 서로 독립적인 HTTP 요청들을 하나의 인증 상태에 연결하는 방법이다. 서버의 세션 상태와 브라우저가 보내는 식별자는 별개이며 생성·갱신·만료·폐기 조건이 필요하다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- 로그인 결과를 후속 요청의 사용자 정보에 연결한다.
- 인증 수준 변경과 로그아웃 때 식별자와 유효 상태를 갱신한다.
- 유휴·절대 만료로 탈취된 인증 상태의 사용 시간을 제한한다.
02어떤 순서로 동작하나
- 자격 검증
서버가 로그인 입력을 검증하며 실패한 입력에는 인증된 세션을 발급하지 않는다.
- 새 식별자 발급
로그인 또는 권한 변경 시 예측하기 어려운 새 식별자로 회전하고 서버 저장소의 사용자 문맥에 연결한다.
- 쿠키 전달
서버의 Set-Cookie 응답을 받은 브라우저가 쿠키 정책에 맞는 다음 요청에 Cookie를 첨부한다.
- 요청마다 검사
서버가 식별자 존재·만료·인증 상태를 확인한 뒤 해당 객체·행동의 를 별도로 수행한다.
- 만료 또는 종료
유휴·절대 만료나 로그아웃 시 서버 상태를 무효화한다. 브라우저의 쿠키 삭제만으로 서버의 기존 상태가 자동 폐기되지는 않는다.
03먼저 알아둘 용어와 구성요소
- 서버가 세션 상태를 찾는 데 사용하는 예측하기 어려운 식별자.
- 공격자가 아는 기존 식별자가 로그인 뒤에도 계속 쓰이는 문제.
- 마지막 활동 이후 일정 시간이 지나면 세션을 만료시키는 조건.
- 활동 여부와 관계없이 최초 생성 이후 정해진 시간이 지나면 만료하는 조건.
- 브라우저 스크립트가 쿠키를 읽는 경로를 제한하는 쿠키 속성.
- 쿠키의 전송을 보안 연결로 제한하는 속성.
- 로그인·권한 상승 때 기존 식별자를 새 식별자로 교체하는 처리.
LEARN THROUGH PRACTICE
쿠키와 폼 토큰이 서로 다른 상태를 나타내는지 확인하기
세션 식별자와 요청 검증 토큰을 구분하고, 쿠키가 있다는 사실과 인증 성공을 분리한다.
실습 구성과 전제
- 폐기 가능한 실습 계정으로만 로그인한다.
- 다음 두 요청 화면은 서로 다른 웹 실습의 비교 자료다. 쿠키 값을 복사해 한 연결처럼 재사용하지 않는다.
서버가 상태를 찾는 단서를 분리한다
- 브라우저 개발자 도구에서 로그인 응답의 Set-Cookie와 다음 요청의 Cookie를 구분한다. 응답이 저장 지시를 보내고 요청이 저장된 값을 되돌려 보낸다.
- 세션 쿠키가 있어도 서버 측 세션이 만료됐거나 해당 작업 권한이 없을 수 있다.
원본 크기로 보기 ↗- Cookie 헤더와 로그인 폼의 user_token이 서로 다른 위치에 있다.
- Origin·Referer·Content-Type도 함께 보이므로 서버가 검증할 수 있는 입력은 세션 값 하나만이 아니다.
확인 기준Cookie 존재 여부와 로그인 응답 결과를 별도 칸으로 기록한다.
본문 토큰과 사용자 입력의 역할을 비교한다
- 교육용 실습 요청에는 token·phrase·send가 본문 필드로 전달된다. token이라는 이름만으로 서버 세션 토큰인지 토큰인지 결정할 수 없다.
- 응답·서버 코드·과제 설명을 함께 보아 어떤 값과 연결해 검증하는지 확인한다.
원본 크기로 보기 ↗- 상단 Cookie와 하단 Form item: token·phrase·send가 나뉘어 보인다.
- Content-Length 66과 Response in frame 링크가 있어 요청 본문 크기와 대응 응답을 추적할 수 있다.
확인 기준필드 이름이 아니라 생성 위치·저장 위치·검증 조건으로 역할을 설명한다.
로그아웃과 세션 만료를 재시험한다
- 정상 로그인→허가된 조회→로그아웃→같은 보호 자원 조회 순서로 결과를 기록한다. 로그아웃 뒤 서버가 세션을 더 이상 인정하지 않는지가 핵심이다.
- 인증 쿠키 삭제만으로 끝나는지, 서버 상태도 무효화되는지 구분한다. 예전 요청의 원문을 외부에 전송하지 않는다.
확인 기준로그아웃 뒤 보호 자원이 다시 보이면 캐시와 실제 서버 응답을 나누어 조사한다.
실습에서 확인한 동작 원리
- 쿠키·세션·폼 토큰은 같은 개념이 아니다.
- 상태 변화는 응답과 서버의 판단으로 확인해야 한다.
04예제로 따라가기
- 모형 고정: 각 16진수 글자가 독립적이고 균등한 난수라고 가정한다. 실제 생성기의 품질을 이 계산만으로 입증할 수는 없다.
- 전체 난수: 32글자가 모두 무작위이면 표현 가능한 경우의 수는 16^32=2^128이고 이상적 엔트로피는 128비트다.
- 고정 접두사: 앞 24글자가 고정이고 뒤 8글자만 무작위이면 엔트로피는 8×4=32비트로 줄어든다.
- 확률 비교: 유효 ID 하나를 독립적으로 한 번 추측하는 모형에서 성공 확률은 각각 1/2^128과 1/2^32다. 겉보기 길이가 같아도 차이가 크다.
- 해석 범위: 재사용·유출·은 난수 길이를 늘려도 별도로 남는다. 생성기·발급·전달·폐기 경로를 함께 보호해야 한다.
05혼동하기 쉬운 점과 확인 기준
- Cookie 범위: 같은 이름의 쿠키가 서로 다른 Domain·Path에 존재하는지 본다. 요청에 복수 값이 들어오면 서버 선택 방식에 따라 다른 세션이 적용될 수 있다.
- 저장소 분리: 로드밸런서 뒤 서버들이 같은 세션 저장소·서명 키·만료 정책을 사용하는지 비교한다. 특정 서버에서만 로그아웃되는 패턴은 분산 상태의 단서다.
- 회전 경쟁: 동시에 보낸 요청이 이전 ID와 새 ID를 번갈아 쓰는지 본다. 이전 ID의 유예가 필요하면 기간·권한 범위를 명확히 제한한다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.