크롬(Google Chrome)80버전부터 새로운 쿠키 정책이 적용 되어 Cookie의 SameSite 속성의 기본값이 "None"에서 "Lax"로 변경
■ 그로 인한 어떠한 영향도가 있는가?? SameSite 를 None 으로 설정할 경우 모든 도메인에서 쿠키를 전송하고 사용할 수 있지만 사용자가 사이트 간 요청 위조(CSRF - Cross-site request forgery) 및 의도하지 않은 정보 유출에 취약해질 가능성이 있음. 이러한 취약점을 방지하기 위해 지금까지는 별도의 SameSite 속성 명시 없이 쿠키를 생성했을 때 "SameSite=None" 으로 설정한 것과 동일하게 동작 했지만 Chrome80 버전 이후에는 SameSite 속성 설정이 없는 쿠키는 "SameSite=Lax" 로 명시한 것과 동일하게 동작 즉 iframe, ajax를 이용하여 다른 도메인으로부터 받은 쿠키를 저장하지 않게 됨
■ SameSite 란? Cookie의 SameSite 속성은 서로 다른 도메인간의 쿠키 전송에 대한 보안을 설정.
"None"은 동일 사이트과 크로스 사이트에 모두 쿠키 전송이 가능. 그리고 "Strict"로 설정할 경우 서로 다른 도메인에서는 아예 전송이 불가능해 지기 때문에 CSRF를 100% 방지할 수 있으나 사용자 편의성을 많이 해치게 됩니다. 그래서 Strict 설정에 일부 예외( HTTP get method / a href / link href )를 두어 적용되는 설정이 이번에 기본값으로 변경되는 "Lax"
■ 크롬이 SameSite 정책을 변경한 이유 브라우저에서 기본 설정을 변경한 것은 크로스 도메인간 중요한 정보 유지는 CSRF 가능성이 있는 쿠키가 아닌 다른 안전한 방식으로 하기를 권장하기 때문. 제안하는 대로 Lax 설정에서도 문제 없게끔 쿠키에 대한 의존성을 낮추는 것이 권장 되지만 바로 수정개발이 힘든 경우는 쿠키의 SameSite설정을 기존의 기본값이었던 None으로 설정하여 임시로 해결 할 수 있음.
■ 해결방안 1. WEBTOB patch WebtoB-4.1.9.1-B308.50.18 로 패치
3. JEUS설정 변경 버전별 설정파일 상이 JEUS6 - JEUSMain.xml 의 다음과 같은 내용 추가 <node><engine-container><command-option>-Djeus.servlet.response.cookie.sameSite=None - WEBMain.xml 의 다음과 같은 내용 추가 <web-container><session-config><seasion-cookie><secure>true
JEUS7,8 Servers 메뉴 - MS선택 - Basic탭 - Basic Info 탭 이동 [Lock&Edit] 버튼 클릭 - Jvm Option 수정(-Djeus.servlet.response.cookie.sameSite=None) - 우측 상단 파란색 확인 버튼 클릭 - [Activate Changes] 버튼 클릭
Servers 메뉴 - MS선택 - Engine탭 - Web Engine 탭 - Session Config 탭 이동 [Lock&Edit] 버튼 클릭 - Secure 옵션 체크 - 우측 상단 파란색 확인 버튼 클릭 - [Activate Changes] 버튼 클릭
1. HSTS (HTTP Strict Transport Security) 란? 일반적으로 HTTPS를 강제하게 될 때 서버측에서 302 Redirect 를 이용하여 전환(웹서버 설정을 통해)시켜 줄 수 있음. 하지만 이것이 취약점 포인트로 작용될 수 있다.
이러한 이유로 클라이언트 (브라우저) 에게 HTTPS를 강제 하도록 하는 것이 권장되는데, 이것이 HSTS (HTTP Strict Transport Security) 다. 클라이언트 (브라우저)에서 강제 하기 때문에 Plain Text (HTTP) 를 이용한 연결 자체가 최초부터 시도되지 않으며 클라이언트 측에서 차단된다는 장점이 있음.
사용자가 최초로 사이트에 접속시도를 하게 되면 웹서버는 HSTS 설정에 대한 정보를 브라우저에게 응답하게 됨. 브라우저는 이 응답을 근거로 일정시간 (max-age) 동안 HSTS 응답을 받은 웹사이트에 대해서 https 접속을 강제화 함. (Response Header에 Strict-Transport-Security 값으로 존재)
크롬에서는 다음과 같은 명령어로 브라우저에 들어있는 HSTS값이 확인 가능
chrome://net-internals/#hsts
아래의 사이트에서 HSTS가 적용된 사이트인지 확인 가능
https://hstspreload.org
1.1. HSTS의 오점
HSTS를 웹서버에서 리스폰스 헤더로 제공하는건 최초의 HTTP로 연결시에 HSTS 헤더가 내려오기전에 SSL 스트립이 가능한 문제가 여전히 존재. 따라서 웹페이지에 들어가지 않고도 브라우저 내장 preload를 갖추는게 가장 안전한데, 크롬 측에 조건 갖추고 제출하면 크롬 preload 리스트에 들어갈 수 있음. 크롬 리스트는 다른 브라우저도 공유함. // END
2. HSTS (HTTP Strict Transport Security) 의 설정방법 WEBTOB 설정파일(http.m)에서 다음과 같은 설정 추가 *HEADERS HSTS ACTION="AddResponse", FIELDNAME="Strict-Transport-Security", FIELDVALUE="max-age=[시간ms]" *VHOST HEADERS="HSTS",
3. HSTS (HTTP Strict Transport Security) 를 이용한 SSL Strip 방어
MITM (Man in the Middle) 공격을 보안하기 위함. 일반적으로 TLS/SSL로 암호화 된 세션은 중간에서 공격자가 그 내용을 감청하더라도 암호화 되어 있기 때문에 데이터가 보호 될 수 있습니다. 따라서 MITM은 SSL Strip (SSL/TLS 로 암호화 된 세션을 강제로 암호화 하지 않은 HTTP 세션으로 유도) 을 통해 공격
정의 Ajax에는 Same Origin Policy 원칙이 적용. 현재 브라우져에 보여주고 있는 HTML을 응답해준 웹서버(Origin)에게만 Ajax 요청을 보낼 수 있음. OpenAPI등의 활성화로 인해 여러 개의 도메인을 사용해야하는 필요성이 높아짐. 따라서 크로스도메인간에도 Ajax 요청을 주고 받을 수 있는 방법을 표준화 함. 그것이 CORS(Cross-Origi Resource Sharing) 임. CORS는 크로스도메인에 위치한 웹서버가 응답에 적절한 Access-Control-Allow-류의 헤더를 보냄으로써 크로스도메인 Ajax를 허용 할 수 있음. ※IE는 IE8부터 지원
예시 기본적으로는 한 페이지에서 서비스 되는 도메인이 2개 이상이 되면 browser에서 다른 도메인 resource 사용을 reject 해당 기능을 쓰고 싶으면 WEB서버에서 크로스도메인 설정이 필요
