DEVELOPERS: SAMESITE=NONE; SECURE 쿠키 설정을 위한 준비

5월에 Chrome은 새로운 쿠키 분류 시스템을 통해 쿠키에 대한 기본 보안 모델을 발표했습니다. 이 이니셔티브는 웹에서 개인 정보 및 보안을 향상시키기위한 지속적인 노력의 일환입니다.

Chrome 변경 사항이 몇 개월 남았지만 쿠키를 관리하는 개발자는 준비해야 합니다. 개발자 지침은 web.dev에 설명 된 SameSite 쿠키를 참조하십시오.

교차 사이트 및 동일 사이트 쿠키 컨텍스트 이해

Understanding Cross-Site and Same-Site Cookie Context

웹 사이트는 일반적으로 광고, 콘텐츠 추천, 타사 위젯, 소셜 임베드 및 기타 기능을 위한 외부 서비스를 통합합니다. 웹을 탐색 할 때 이러한 외부 서비스는 브라우저에 쿠키를 저장한 다음 해당 쿠키에 액세스하여 개인화 된 경험을 제공하거나 사용자 참여를 측정할 수 있습니다. 모든 쿠키에는 도메인이 연결되어 있습니다. 쿠키와 연결된 도메인이 사용자 주소 표시 줄의 웹 사이트가 아닌 외부 서비스와 일치하는 경우 이는 교차 사이트 (또는 “타사 third party”) 컨텍스트로 간주됩니다.

동일한 엔터티가 쿠키와 웹 사이트를 소유하지만 쿠키의 도메인이 쿠키에 액세스하는 사이트와 일치하지 않는 경우에도 여전히 크로스 사이트 또는 “타사” 컨텍스트로 인식됩니다.

웹 페이지의 외부 리소스가 사이트 도메인과 일치하지 않는 쿠키에 액세스하는 경우 이는 사이트 간 또는 “타사” 컨텍스트입니다.

반대로 쿠키 도메인이 사용자 주소 표시 줄의 웹 사이트 도메인과 일치하면 동일 사이트 “first-party” 컨텍스트에서 쿠키 액세스가 발생합니다. 동일 사이트 쿠키는 일반적으로 사람들이 개별 웹 사이트에 로그인하고 선호 사항을 기억하며 사이트 분석을 지원하는 데 사용됩니다.

웹 페이지의 리소스가 사용자가 방문하는 사이트와 일치하는 쿠키에 액세스하면 동일한 사이트 또는 “first-party” 컨텍스트입니다.

A New Model for Cookie Security and Transparency

쿠키 보안 및 투명성을 위한 새로운 모델

현재 쿠키를 first-party 컨텍스트에서만 액세스하려는 경우 개발자는 외부 액세스를 방지하기 위해 두 가지 설정 (SameSite = Lax 또는 SameSite = Strict) 중 하나를 적용할 수 있습니다. 그러나 이 권장 사항을 따르는 개발자는 극소수이므로 사이트 간 요청 위조 공격과 같은 위협에 많은 same-site 쿠키가 불필요하게 노출됩니다.

더 많은 웹 사이트와 사용자를 보호하기 위해 새로운 기본 보안 모델은 달리 명시되지 않는 한 모든 쿠키가 외부 액세스로부터 보호되어야 한다고 가정합니다. 개발자는 새로운 쿠키 설정인 SameSite=None을 사용하여 사이트 간 접속을 위한 쿠키를 지정해야 합니다.

SameSite=None 속성이 있는 경우 HTTPS 연결을 통해서만 사이트 간 쿠키에 액세스할 수 있도록 추가로 Secure 속성을 사용해야 합니다. 이것은 사이트 간 접속(cross-site access)과 관련된 모든 위험을 완화시키지는 않지만 네트워크 공격에 대한 보호를 제공할 것입니다.

즉각적인 보안상의 이점 이외에도, 사이트 간 쿠키를 명시적으로 선언하면 투명성과 사용자 선택이 향상됩니다. 예를 들어, 브라우저는 여러 사이트에서 액세스하는 쿠키와는 별도로 단일 사이트에서만 액세스하는 쿠키를 관리하기 위한 세분화 된 제어 기능을 사용자에게 제공할 수 있습니다.

Chrome Enforcement Starting in February 2020

2월 Chrome 80에서는 Chrome에서 SameSite 값이 선언되지 않은 쿠키를 SameSite = Lax 쿠키로 취급합니다. 오직 SameSite=None; Secure 설정이 된 쿠키만이 보안 연결을 통해 액세스하는 경우에만 외부 액세스가 가능합니다.

How to Prepare; Known Complexities

cross-site 쿠키를 관리하는 경우 SameSite = None; Secure를 적용해야 합니다. 대부분의 개발자에게는 구현이 간단해야하지만 다음과 같은 복잡성과 특수 사례를 식별하기 위해 지금 테스트를 시작하는 것이 좋습니다.

• 모든 언어와 라이브러리가 아직 None 값을 지원하는 것은 아니며 개발자가 쿠키 헤더를 직접 설정해야합니다. 이 Github 리포지토리는 SameSite = None을 구현하기 위한 지침을 제공합니다. 다양한 언어, 라이브러리 및 프레임 워크로 보호하십시오.
• 일부 Chrome, Safari 및 UC 브라우저 버전을 포함한 일부 브라우저는 의도하지 않은 방식으로 None 값을 처리 할 수 있으므로 개발자가 해당 클라이언트에 대한 예외를 코딩해야 합니다. 여기에는 이전 버전의 Chrome으로 구동되는 Android WebView가 포함됩니다. 호환되지 않는 알려진 클라이언트 목록은 다음과 같습니다.
• 앱 개발자는 HTTP (S) 헤더와 Android WebView의 CookieManager API를 통해 액세스하는 쿠키 모두에 대해 None 값과 호환되는 Chrome 버전을 기반으로 Android WebViews에 적절한 SameSite 쿠키 설정을 선언하는 것이 좋습니다. 나중에까지 Android WebView에서 시행됩니다.
• 엔터프라이즈 IT 관리자는 Single Sign On 또는 내부 애플리케이션과 같은 일부 서비스가 2월 출시에 준비가 되지 않은 경우 일시적으로 Chrome Browser를 레거시 동작으로 되돌리기 위한 특별한 정책을 구현해야 합니다.
• first-party 및 third-party 컨텍스트 모두에서 액세스하는 쿠키가 있는 경우, first-party 컨텍스트에서 SameSite=Lax의 보안 혜택을 얻기 위해 별도의 쿠키를 사용하는 것을 고려할 수 있습니다.

SameSite Cookies Explained는 위 상황에 대한 특정 지침과 문제 및 질문을 제기하기 위한 채널을 제공합니다.

귀하가 관리하는 사이트 또는 쿠키에 대한 새로운 Chrome 동작의 영향을 테스트하려면 Chrome 76 이상에서 chrome://flags로 이동하여 “SameSite by default cookies” 및 “Cookies without SameSite must be secure(SameSite가 없는 쿠키는 안전해야 함)” 옵션을 활성화 하십시오. 또한 이러한 실험은 크롬 79 베타 사용자 중 일부에 대해 자동으로 활성화됩니다. 테스트가 가능한 일부 베타 사용자는 아직 새 모델을 지원하지 않는 서비스와 호환되지 않는 문제가 발생할 수 있습니다.

same-site 컨텍스트 (same-site 쿠키)로만 액세스되는 쿠키를 관리하는 경우 사용자가 취해야 할 조치는 없습니다. Chrome은 SameSite 속성이 없거나 값이 설정되지 않은 경우에도 외부 엔터티가 쿠키에 액세스하지 못하게 합니다.

그러나 모든 브라우저가 기본적으로 동일한 사이트 쿠키를 보호하는 것은 아니기 때문에 적절한 SameSite 값 (Lax 또는 Strict)을 적용하고 기본 브라우저 동작에 의존하지 않는 것이 좋습니다.

마지막으로, 웹 사이트에 서비스를 제공하는 공급 업체 및 다른 사람의 준비 상태에 대해 우려가 되는 경우 페이지에 필요한 설정이 누락된 cross-site 쿠키가 포함 된 경우 Chrome 77 이상에서 개발자 도구 콘솔 경고를 확인할 수 있습니다.

Posted by Barb Palser, Chrome and Web Platform Partnerships

원문 : https://blog.chromium.org/2019/10/developers-get-ready-for-new.html

HTTPS접속에서 MIXED MESSAGE가 더 이상 없다.

오늘은 https:// 페이지가 안전한 https 프로토콜인 하위 리소스만 로드할 수 있도록 Chrome이 점차 변화될 것이라고 발표합니다. 아래에 설명하는 일련의 단계에서 기본적으로 mixed content (https:// 페이지의 안전하지 않은 http:// 하위 리소스)를 차단하기 시작합니다. 이 변경은 웹에서 사용자 개인 정보 보호 및 보안을 향상시키고 사용자에게보다 명확한 브라우저 보안 UX를 제공합니다.

지난 몇 년 동안 웹은 HTTPS로 전환하는데 큰 진전을 보였습니다. 이제 Chrome 사용자는 주요 플랫폼에서 90% 이상을 HTTPS로 사용합니다. 이제 웹에서 HTTPS 구성이 안전하고 최신 상태가 되도록 주의를 기울이고 있습니다.

HTTPS 페이지는 일반적으로 페이지의 하위 자원이 http://를 통해 안전하지 않게 로드되는 mixed content라는 문제로 인해 어려움을 겪습니다. 브라우저는 스크립트 및 iframe과 같은 여러 유형의 mixed content를 기본적으로 차단하지만 이미지, 오디오 및 비디오는 계속 로드되어 사용자의 개인 정보 및 보안을 위협합니다. 예를 들어 공격자는 주식 차트의 혼합된 이미지를 조작하여 투자자를 오도하거나 추적 쿠키를 로드되는 혼합된 리소스 사이에 주입 할 수 있습니다. mixed content를 로드하면 페이지가 안전하지 않다고 표시되어 브라우저 UX가 혼란스러워집니다.

Chrome 79에서 시작하는 일련의 단계에서 Chrome은 기본적으로 모든 mixed content를 점차 차단합니다. 파손을 최소화하기 위해 자원을 https://로 자동 업그레이드하므로 하위 자원이 https://를 통해 이미 사용 가능한 경우 사이트가 계속 작동합니다. 사용자는 특정 웹 사이트에서 mixed content 차단을 거부하도록 설정을 활성화 할 수 있으며, 아래에서는 개발자가 mixed content를 찾고 수정하는 데 도움이 되는 리소스에 대해 설명합니다.

Timeline

모든 mixed content를 한 번에 모두 차단하는 대신 이러한 변경을 단계적으로 진행할 것입니다.

• 2019년 12월 출시되는 Chrome 79에서는 특정 사이트에서 mixed content를 차단 해제할 수 있는 새로운 설정을 도입합니다. 이 설정은 Chrome에서 현재 기본적으로 차단하는 mixed script, iframe 및 기타 유형의 컨텐츠에 적용됩니다. https:// 페이지에서 잠금 아이콘을 클릭하여 사이트 설정을 클릭하여 이 설정을 전환할 수 있습니다. 이전 버전의 데스크탑 Chrome에서 mixed content를 차단 해제하기 위해 검색 주소창 오른쪽에 표시되는 방패 아이콘이 대체됩니다.

• Chrome 80에서는 mixed 오디오 및 비디오 리소스가 https://로 자동 업그레이드되며 https://를 통해 로드하지 못하면 Chrome에서 기본적으로 이를 차단합니다. Chrome 80은 2020년 1월 초기 릴리즈 될 예정입니다. 사용자는 위에서 설명한 설정으로 영향을 받는 오디오 및 비디오 리소스를 차단 해제 할 수 있습니다.
• 또한 Chrome 80에서는 mixed 이미지를 계속 로드할 수 있지만 검색 주소창에 Chrome에 ‘보안되지 않음 Not Secure’ 칩이 표시됩니다. 이는 사용자에게 보다 명확한 보안 UI이며 웹 사이트에서 이미지를 HTTPS로 마이그레이션하도록 동기를 부여 할 것으로 예상됩니다. 개발자는 이 보안 경고를 피하기 위해 upgrade-insecure-requests 또는 block-all-mixed-content 보안 정책을 사용할 수 있습니다. 계획은 다음과 같습니다.

• Chrome 81에서는 mixed 이미지가 https://로 자동 업그레이드되며 https://를 통해 로드하지 못하면 Chrome에서 기본적으로 이미지를 차단합니다. Chrome 81은 2020년 2월 초기 릴리즈 될 예정입니다.

Resources for Developers

개발자는 웹 경고와 파손을 피하기 위해 mixed content를 https://로 즉시 마이그레이션해야 합니다. 다음은 그 방안입니다.

• 컨텐츠 보안 정책 및 Lighthouse’s mixed content 감사를 사용하여 사이트에서 mixed content를 검색하고 수정하십시오.
• 서버를 HTTPS로 마이그레이션하는데 대한 일반적인 조언은 이 가이드를 참조하십시오.
• CDN, 웹 호스트 또는 컨텐츠 관리 시스템에 mixed content 디버깅을 위한 특수 도구가 있는지 확인하십시오. 예를 들어 Cloudflare는 mixed content를 https://로 다시 작성하는 도구를 제공하며 WordPress 플러그인도 사용할 수 있습니다.

Posted by Emily Stark and Carlos Joan Rafael Ibarra Lopez, Chrome security team
원문 : https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html