쿠키와 보안 속성
쿠키 보안 · Cookie security
쿠키는 서버가 브라우저에 저장하도록 지시하고 이후 조건에 맞는 요청에 브라우저가 보내는 이름·값이다. ··SameSite는 각각 다른 전송·접근 경계를 제한한다.
밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.
01무엇이고, 어떤 일을 하나
- HTTP 요청 간 세션 식별자를 전달한다.
- 허용할 전송 경로와 스크립트 접근 범위를 줄인다.
- 사이트 간 자동 인증 전송에 따른 위험을 제한한다.
02어떤 순서로 동작하나
- 쿠키 발급
서버가 응답으로 이름·값·경로·만료·보안 속성을 지정한다. 세션 저장소의 인증 상태는 별도로 관리된다.
- 브라우저 저장
브라우저는 도메인·경로·만료 등의 규칙에 맞게 쿠키를 보관한다. Path는 애플리케이션의 강한 보안 격리 경계와 같지 않다.
- 후속 전송
요청 목적지와 속성 조건을 충족하면 헤더에 값이 실린다. 서버가 원래 설정한 속성 전체를 요청마다 다시 보내는 것은 아니다.
- 서버 검증
서버가 값을 세션 상태와 연결하고 만료·권한을 검사한다. 로그아웃에서는 서버 상태 무효화와 브라우저 쿠키 삭제 조건을 함께 맞춘다.
03먼저 알아둘 용어와 구성요소
- 서버 응답에서 쿠키 저장과 속성을 지시하는 헤더.
- 브라우저 요청에서 조건에 맞는 쿠키 값을 전송하는 헤더.
- 브라우저 스크립트의 쿠키 직접 접근을 제한하는 속성.
- 안전한 전송 조건에서 쿠키가 보내지도록 제한하는 속성.
쿠키와 폼 토큰이 서로 다른 상태를 나타내는지 확인하기
세션 식별자와 요청 검증 토큰을 구분하고, 쿠키가 있다는 사실과 인증 성공을 분리한다.
실습 구성과 전제
- 폐기 가능한 실습 계정으로만 로그인한다.
- 다음 두 요청 화면은 서로 다른 웹 실습의 비교 자료다. 쿠키 값을 복사해 한 연결처럼 재사용하지 않는다.
서버가 상태를 찾는 단서를 분리한다
- 브라우저 개발자 도구에서 로그인 응답의 와 다음 요청의 를 구분한다. 응답이 저장 지시를 보내고 요청이 저장된 값을 되돌려 보낸다.
- 세션 쿠키가 있어도 서버 측 세션이 만료됐거나 해당 작업 권한이 없을 수 있다.
원본 크기로 보기 ↗- Cookie 헤더와 로그인 폼의 user_token이 서로 다른 위치에 있다.
- Origin·Referer·Content-Type도 함께 보이므로 서버가 검증할 수 있는 입력은 세션 값 하나만이 아니다.
확인 기준존재 여부와 로그인 응답 결과를 별도 칸으로 기록한다.
본문 토큰과 사용자 입력의 역할을 비교한다
- 교육용 실습 요청에는 token·phrase·send가 본문 필드로 전달된다. token이라는 이름만으로 서버 세션 토큰인지 토큰인지 결정할 수 없다.
- 응답·서버 코드·과제 설명을 함께 보아 어떤 값과 연결해 검증하는지 확인한다.
원본 크기로 보기 ↗- 상단 Cookie와 하단 Form item: token·phrase·send가 나뉘어 보인다.
- Content-Length 66과 Response in frame 링크가 있어 요청 본문 크기와 대응 응답을 추적할 수 있다.
확인 기준필드 이름이 아니라 생성 위치·저장 위치·검증 조건으로 역할을 설명한다.
로그아웃과 세션 만료를 재시험한다
- 정상 로그인→허가된 조회→로그아웃→같은 보호 자원 조회 순서로 결과를 기록한다. 로그아웃 뒤 서버가 세션을 더 이상 인정하지 않는지가 핵심이다.
- 인증 쿠키 삭제만으로 끝나는지, 서버 상태도 무효화되는지 구분한다. 예전 요청의 원문을 외부에 전송하지 않는다.
확인 기준로그아웃 뒤 보호 자원이 다시 보이면 캐시와 실제 서버 응답을 나누어 조사한다.
실습에서 확인한 동작 원리
- 쿠키·세션·폼 토큰은 같은 개념이 아니다.
- 상태 변화는 응답과 서버의 판단으로 확인해야 한다.
쿠키가 동반된 상태 변경 요청을 패킷에서 읽기
정상 로그인 상태가 사용자의 변경 의도를 증명하지 않는다는 점을 실제 요청 구조로 설명한다.
실습 구성과 전제
- 격리 의 폐기 가능한 계정으로만 상태 변경을 시험한다.
- 사진 속 요청과 테스트 값은 당시 교육 환경의 기록이다. 자신의 환경에서는 새 토큰과 무해한 변경 항목을 사용한다.
상태 변경을 유발하는 입력 위치를 찾는다
- 사진의 폼은 게시 메시지 안에 다른 기능을 향하는 링크를 넣은 사례다. 메시지 저장과 링크 목적지의 상태 변경은 서로 다른 요청이다.
- 링크를 봤다는 것·눌렀다는 것·서버가 변경을 수락했다는 것을 각각 구분한다.
원본 크기로 보기 ↗- URL-encoded 폼의 mtxMessage에 링크가 들어가며 별도의 변경 기능 경로를 가리킨다.
- 버튼 값은 Sign Guestbook이다. 겉으로 보이는 게시 기능과 링크의 목적 기능이 다르다.
확인 기준이 첫 화면은 입력 저장 요청이며 계정 변경 성공의 증거는 아니다.
자동으로 붙는 인증 자료를 확인한다
- 다음 캡처에는 변경 기능을 향한 GET과 가 함께 보인다. 브라우저가 인증 자료를 첨부해도 사용자가 그 변경을 의도했다고 증명할 수는 없다.
- GET은 안전한 조회 의미로 설계해야 하며, 상태 변경을 GET에 맡기지 않는다. 메서드를 POST로 바꾸는 것만으로 가 해결되는 것도 아니다.
원본 크기로 보기 ↗- 요청 행은 비밀번호 변경 기능을 향한 GET이고 Cookie 헤더가 포함된다.
- Referer는 다른 과제 페이지를 나타내며 Response in frame 링크가 제공된다. 실제 변경 판정에는 대응 응답과 계정 상태가 더 필요하다.
확인 기준응답 메시지뿐 아니라 서버 상태가 바뀌었는지 확인한다.
의도 검증 실패가 변경 전에 끝나는지 시험한다
- 정상 토큰·누락 토큰·다른 세션 토큰으로 요청을 구분한다. 토큰 검증 실패는 실제 변경 코드가 실행되기 전에 거부돼야 한다.
- SameSite·Origin·Fetch Metadata는 보조 조건이며 배포 환경의 정상 요청과 함께 시험한다.
확인 기준누락·불일치 토큰 요청 뒤 계정 정보가 그대로인지까지 확인한다.
실습에서 확인한 동작 원리
- 인증된 요청과 의도된 요청은 다르다.
- 거부 화면이 아니라 변경이 수행되지 않았다는 상태 증거가 필요하다.
04예제로 따라가기
- 인 세션 쿠키는 스크립트가 직접 읽기 어렵지만 가 페이지 권한으로 인증된 요청을 보내는 문제까지 없애지는 않는다.
- SameSite=Lax의 동작과 Strict·None의 전송 범위는 다르므로 정상 외부 링크·인증 리다이렉트 흐름과 함께 검토한다.
- 브라우저 쿠키가 남아 있어도 서버 세션이 만료되었으면 인증된 작업을 허용하면 안 된다.
05혼동하기 쉬운 점과 확인 기준
- 쿠키를 쓰지 않는다는 이유만으로 모든 ·토큰 탈취 문제가 없어지는 것은 아니다. 자격 증명이 어디서 자동 전송되는지 본다.
- 쿠키 삭제는 같은 이름뿐 아니라 Path·Domain 등 저장 범위와 맞아야 하며 서버 측 세션 폐기를 대신하지 않는다.
06상세 노트 · 실습 자료
헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.
공식 문서 · 표준
기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.