쿠키 "보안"플래그는 어떻게 작동합니까?


101

secure플래그가 있는 쿠키 는 암호화되지 않은 연결을 통해 전송되지 않는다는 것을 알고 있습니다. 이것이 어떻게 작동하는지 깊이 궁금합니다.

쿠키 전송 여부를 결정하는 책임은 누구에게 있습니까?

답변:


91

클라이언트는 암호화 된 연결에 대해서만이를 설정하며 이는 RFC 6265에 정의되어 있습니다 .

Secure 속성은 쿠키의 범위를 "보안"채널로 제한합니다 (여기서 "보안"은 사용자 에이전트에 의해 정의 됨). 쿠키에 보안 속성이 있으면 사용자 에이전트는 요청이 보안 채널 (일반적으로 TLS (HTTP over Transport Layer Security) [RFC2818])을 통해 전송되는 경우에만 HTTP 요청에 쿠키를 포함합니다.

활성 네트워크 공격자로부터 쿠키를 보호하는 데 유용 해 보이지만 Secure 속성은 쿠키의 기밀성 만 보호합니다. 활성 네트워크 공격자는 안전하지 않은 채널의 보안 쿠키를 덮어 써서 무결성을 방해 할 수 있습니다 (자세한 내용은 섹션 8.6 참조).


4
클라이언트 측에 아직 쿠키가없고 서버 측에서 보내야하는 경우 (예 : 로그인) 응답에 쿠키를 포함할지 여부를 서버 측에서 결정합니까?
— ted

3
서버는 초기에 "Set-Cookie 헤더"를 통해 쿠키를 설정합니다
— Ivan

49

주제에 대한 또 다른 단어 :

secure웹 사이트 example.com가 완전히 https 이기 때문에 생략하는 것만으로는 충분하지 않습니다.

사용자가 명시 적으로에 도달 http://example.com하면로 리디렉션 https://example.com되지만 이미 너무 늦습니다. 첫 번째 요청에는 쿠키가 포함되었습니다.


6
나는 이것이 오래되었다는 것을 알고 있지만 HSTS 프리로드는이 문제가 자주 발생하는 것을 방지하여 이러한 상황을 도와줍니다. 여전히 100 % 수정은 아니지만 보안 쿠키를 정말로 피하고 싶다면 고려해야 할 또 다른 사항입니다.
— Mr. MonoChrome

5
@ Mr.MonoChrome 왜 보안 쿠키를 피하고 싶습니까?
— MEMark

@ Mr.MonoChrome 일부 구형 또는 저사양 브라우저이지만 HSTS도 지원하지 않습니다
— oldboy

1
좋은 지적. .NET 응용 프로그램의 경우 프로그래밍 방식 (예 : globals.asax)보다는 IIS (또는 web.config)에서 리디렉션을 수행하는 것이 좋습니다
— piris

따라서 http에서 https로 리디렉션하지 않고 https에서만 제공하는 경우 필요하지 secure않습니까?
— braks
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.