인증·인가·세션의 생애주기

01개념과 구성 요소

• 세션서로 독립적인 HTTP 요청을 서버가 같은 인증 상태와 연결하는 방식이다.
• 식별자와 저장소브라우저의 세션 식별자와 서버의 사용자·권한·만료 문맥을 연결한다.
• 생명주기발급·회전·요청 검증·만료·로그아웃이 함께 맞아야 인증 상태를 일관되게 유지한다.

02로그인부터 로그아웃까지 세션 상태 변화

1. 자격 검증서버가 로그인 입력을 검증하며 실패한 입력에는 인증된 세션을 발급하지 않는다.
2. 새 식별자 발급로그인 또는 권한 변경 시 예측하기 어려운 새 식별자로 회전하고 서버 저장소의 사용자 문맥에 연결한다.
3. 쿠키 전달서버의 Set-Cookie 응답을 받은 브라우저가 쿠키 정책에 맞는 다음 요청에 Cookie를 첨부한다.
4. 요청마다 검사서버가 식별자 존재·만료·인증 상태를 확인한 뒤 해당 객체·행동의 인가를 별도로 수행한다.
5. 만료 또는 종료유휴·절대 만료나 로그아웃 시 서버 상태를 무효화한다. 브라우저의 쿠키 삭제만으로 서버의 기존 상태가 자동 폐기되지는 않는다.

03HTTP 요청 사이의 사용자를 서버는 어떻게 연결하는가

• HTTP와 상태HTTP의 개별 요청만으로 서버가 사용자의 로그인 상태를 자동 보존하지는 않는다. 애플리케이션은 인증 성공 뒤 서버 측 세션을 만들고 브라우저에 세션 식별자를 보낸다.
• 요청 연결이후 요청에 식별자가 포함되면 서버는 연결된 계정·권한·만료 상태를 찾아 현재 요청을 처리한다. 세션 식별자는 DB의 사용자 번호와 달리 그 자체가 접근 증거로 쓰일 수 있는 비밀값이다.
• 서버 저장소서버 측 세션에서는 쿠키가 계정 정보 전체를 담지 않아도 된다. 예측 불가능한 식별자가 서버 저장소의 레코드를 가리키면 충분하다.
• 클라이언트의 주장반대로 클라이언트가 보낸 user_id나 role 값을 세션의 검증된 계정처럼 취급하면 사용자가 요청을 바꾸어 다른 신원이나 권한을 주장할 수 있다.

04Set-Cookie와 Cookie의 방향

• 쿠키의 방향로그인 응답의 Set-Cookie는 브라우저가 저장할 쿠키의 이름·값·속성을 지정한다. 이후 브라우저의 Cookie 헤더는 해당 요청 대상과 정책에 맞는 쿠키를 서버로 보낸다.
• 식별자 조회세션 서버는 그 값을 조회 키로 사용하고 유효한 레코드가 있을 때만 계정과 연결한다. 브라우저에 쿠키가 남아 있다는 사실만으로 서버 세션도 살아 있다고 볼 수 없다.
• 가상 예시아래 예제의 값은 설명용 표지이며 실제 발급값이 아니다. 요청에 Secure·HttpOnly 같은 속성 문자열을 다시 실어 인증하는 구조도 아니다.
• 속성의 역할이 속성은 브라우저가 쿠키를 보관·전송·스크립트에 노출할 때 적용하는 정책이다.

응답:
Set-Cookie: sid=<가상 세션 식별자>; Path=/; Secure; HttpOnly; SameSite=Lax

다음 요청:
GET /profile HTTP/1.1
Host: app.example
Cookie: sid=<가상 세션 식별자>

서버 세션 저장소:
식별자 → 사용자, 발급 시각, 최근 활동, 만료, 권한 문맥

세션 생성 응답과 이후 요청의 헤더 역할을 비교한다. 실제 토큰은 포함하지 않았다.

05Weak Session IDs: 숫자의 모양보다 예측 가능성

• 예측 가능한 식별자DVWA의 낮은 보안 단계에서 세션값이 1001,1002,1003처럼 증가한다면 다음 후보를 좁히기 쉽다. 타임스탬프나 사용자 번호를 단순히 해시해서 긴 16진수로 만들어도 입력 후보가 적으면 예측 가능성이 남는다.
• 길이와 엔트로피길이가 길어 보이는 인코딩 문자열과 충분한 엔트로피를 갖는 난수는 다르다.
• 발급 표본 비교더미 세션을 여러 번 발급해 응답의 Set-Cookie를 비교하면 식별자 생성 규칙의 단서를 얻을 수 있다. 길이·문자 집합·증가 폭·발급 시각과의 관계는 생성 규칙을 파악하는 단서다.
• 표본의 한계다만 소수 표본에서 뚜렷한 규칙이 안 보인다고 암호학적으로 안전한 난수 생성임을 증명한 것은 아니다. 실제 구현이 사용하는 난수 생성기와 엔트로피, 식별자 생성 방식을 함께 읽어야 한다.

09세션 고정과 세션 탈취의 차이

• 탈취와 고정세션 탈취는 이미 인증된 식별자를 얻어 재사용하는 문제다. 세션 고정은 피해자가 공격자가 알고 있는 식별자를 사용하도록 만든 뒤 로그인 이후에도 그 값이 유지되는 문제다.
• 식별자 회전두 경우 모두 식별자가 로그인 상태의 열쇠로 쓰이지만 발생 순서가 다르다.
• 이전 상태 폐기로그인 성공과 권한 상승 때 새 세션 ID를 발급하고 이전 상태를 적절히 무효화하면 인증 전 식별자와 인증 후 권한의 연결을 끊을 수 있다. 비밀번호가 올바른지만 검사하고 기존 식별자를 그대로 승격하면 이 경계가 남는다.
• 동시 요청여러 탭과 진행 중 요청 때문에 교체 처리에는 서버 저장소의 상태 전환이 필요하며 쿠키 문자열을 새로 만들어 보여 주는 것만으로 끝나지 않는다.

10쿠키 속성이 막는 경로와 남는 경로

• Secure·HttpOnlySecure는 보안 전송 조건에 맞는 요청에서 쿠키를 보내도록 제한하고 HttpOnly는 자바스크립트의 일반적인 쿠키 읽기를 제한한다. SameSite는 교차 사이트 상황의 쿠키 전송을 제어한다.
• Domain·PathDomain과 Path는 적용 범위를 결정하지만 같은 사이트 내부의 모든 신뢰 문제를 해결하는 보안 경계로만 생각해서는 안 된다.
• 속성의 한계HttpOnly는 XSS가 쿠키 값을 직접 읽는 일부 경로를 줄여도 같은 출처에서 실행되는 스크립트가 사용자의 권한으로 요청하는 일까지 막지 않는다. Secure도 서버 로그에 세션 원문을 기록하는 실수를 해결하지 않는다.
• 생명주기 결합쿠키 속성은 발급·회전·만료와 함께 구성되는 여러 층 중 하나다.

11유휴 만료·절대 만료·로그아웃

• 유휴·절대 만료유휴 만료는 최근 활동 이후 시간이 길어질 때 세션을 끝내고 절대 만료는 활동이 계속되어도 발급 후 최대 수명을 제한한다. 로그아웃에서는 브라우저 쿠키 삭제와 서버 세션 무효화가 함께 관련된다.
• 서버 무효화쿠키만 지우고 서버에 기존 세션이 살아 있으면 이미 복사된 값이 계속 유효할 수 있다.
• 분산 저장소여러 애플리케이션 인스턴스가 세션을 공유한다면 무효화 정보도 일관되게 전달되어야 한다. 한 인스턴스에서만 삭제하면 부하분산 경로에 따라 로그인 상태가 다시 살아 있는 것처럼 보일 수 있다.
• 만료와 권한계정 비활성화나 권한 회수도 다음 요청에서 어떤 시점에 반영되는지 세션 저장·캐시 방식에 따라 달라진다.

12세션과 JWT 같은 자체 포함 토큰 비교

• 세션과 자체 포함 토큰서버 측 세션은 식별자로 저장소를 조회하므로 중앙에서 상태를 바꾸거나 폐기하기 쉽다. 서명된 자체 포함 토큰은 검증자가 토큰의 클레임을 읽고 서명과 조건을 검사할 수 있지만 발급 후의 즉시 폐기는 별도 상태나 짧은 수명 등의 설계가 필요할 수 있다.
• 서명과 암호화토큰에 담긴 내용이 서명되어 있다고 암호화된 것은 아니다.
• 검증 조건검증에는 서명뿐 아니라 발급자·대상 서비스·만료와 허용 알고리즘 같은 문맥이 들어간다. 브라우저 저장 위치를 바꾸는 것도 위협을 바꾼다.
• 저장 위치자바스크립트로 읽을 수 있는 저장소와 자동 첨부 쿠키는 XSS와 CSRF에서 다른 특성을 가지므로 이름 하나로 우열을 결정하지 않는다.

13실습 응답을 인증 상태로 해석하기

• 발급 응답가상 사용자의 로그인 전후, 권한 변경 전후, 로그아웃 이후 요청을 비교하면 세션의 생명주기를 볼 수 있다. 발급 응답에 새 Set-Cookie가 있는지, 이전 식별자로 보낸 요청이 어떤 결과가 되는지, 서버의 계정과 만료 정보가 바뀌었는지를 연결한다.
• 인증 상태 판정302 로그인 이동은 요청이 보호 기능까지 도달하기 전에 인증 상태가 사라졌다는 단서일 수 있다.
• IP·User-Agent다른 IP·User-Agent의 사용은 이상 징후가 될 수 있지만 이동통신·프록시·브라우저 업데이트도 값을 바꿀 수 있어 그 자체로 탈취 확정 증거는 아니다. 감사 기록은 원문 세션 ID 대신 사건을 연결할 별도 식별 방법을 사용한다.
• 안전한 감사 식별세션값을 마스킹해도 생성 규칙·쿠키 속성·만료 동작이라는 학습 핵심은 충분히 남길 수 있다.