관리자 권한을 준 뒤 세션 ID를 바꿔야 하는 이유

로그인이나 일반 사용자에서 관리자처럼 권한 수준이 바뀌는 순간 서버는 session ID를 새로 발급해야 합니다. 이전 ID는 보호된 요청에 더 이상 유효하지 않게 하고 서버 측에서도 파기해야 합니다.

쿠키 값만 새로 보내고 이전 세션을 계속 허용하면 세션 고정 위험이 남습니다. 새 ID 발급, 권한 부여, 이전 ID 폐기를 하나의 상태 전이로 확인하세요.

세션 ID는 로그인 상태를 대표하는 값입니다

세션 ID는 서버가 사용자 세션을 찾기 위해 요청마다 받는 식별자입니다. 인증 전에는 익명 상태를 가리키고 로그인 후에는 계정과 권한이 연결됩니다. OWASP Session Management 지침은 인증 과정이나 권한 수준이 바뀐 뒤 ID를 재발급하도록 요구합니다. 인증 전에 공격자가 알려진 ID를 사용자가 로그인한 뒤에도 재사용할 수 있으면, 기존 식별자가 더 높은 권한의 세션으로 이어지는 위험이 생깁니다.

교육용 추적표에서 잘못된 전이를 찾습니다

A·B·C는 설명을 위한 라벨입니다. 표에서 중요한 것은 문자열을 새로 만들었는지가 아니라 서버가 어느 ID를 유효하다고 인식하는지입니다. 응답에 새 쿠키 B가 보이더라도 서버 저장소가 A를 계속 허용한다면 이전 ID 폐기는 확인되지 않았습니다. 반대로 역할 변경을 거절한 요청에는 권한 상승 전이가 발생하지 않았으므로 ID 변경을 무조건 성공으로 기록하지 않습니다.

로그인뿐 아니라 권한이 바뀌는 순간도 봅니다

관리자 권한 승격, 비밀번호 변경처럼 권한 수준이 달라지는 이벤트는 기존 세션을 점검할 경계입니다. 세션 ID 재발급은 역할 검증이나 재인증을 대신하지 않습니다. 권한 변경을 승인한 뒤 현재 세션에 새 ID를 결합하고 이전 ID를 폐기해야 합니다. 다른 장치의 세션을 유지할지 전부 폐기할지는 제품 정책과 위험 수준에 따라 별도 결정합니다.

세션 상태 전이를 확인하는 순서

1. 테스트 계정에서 로그인 전 session ID를 민감값 없이 A라고 기록합니다.
2. 로그인 요청의 승인 여부와 새 응답 쿠키가 발급됐는지 확인합니다.
3. 새 ID B가 보호된 요청에서만 쓰이고 이전 A가 서버에서 거부되는지 확인합니다.
4. 역할 변경 전의 권한과 변경 후 승인 결과를 나눠 기록합니다.
5. 관리자 승격 성공 후 ID C 발급과 이전 ID B 폐기를 검증합니다.
6. 여러 서버·세션 저장소를 쓰면 이전 ID 무효화가 각 노드에 반영되는지 점검합니다.
7. 검증 로그에는 실제 ID를 쓰지 말고 안전한 추적 표식이나 salted hash 정책을 사용합니다.

새 쿠키를 받았다는 사실만으로 회전 완료는 아닙니다

브라우저가 쿠키 값을 B로 바꿔 보였다는 것은 응답 관찰입니다. A가 서버에서 거부되는지, 이전 ID로 관리자 페이지에 접근할 수 없는지 별도 시험해야 합니다. 세션 ID를 로그에 그대로 남기면 이 검증 과정에서 인증 비밀을 다시 노출할 수 있으므로 실제 값은 티켓·스크린샷·학습 예시에 넣지 않습니다.

복습: 역할을 높일 때 B를 계속 써도 될까요?

문제: 일반 사용자 B 세션의 소유자가 관리자 권한을 받았습니다. 서버는 쿠키에 새 C를 보내지만 B도 관리자 요청에 계속 받아들입니다. 무엇이 빠졌나요?

정답: 권한 변화 후 세션 ID를 새로 발급하고 이전 ID B를 거부·파기해야 합니다. 새 쿠키만 보내고 B를 계속 유효하게 두면 회전이 완료되지 않았습니다.