와스킹의 사건현장

출처: https://ifuwanna.tistory.com/223

크롬(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 로 패치

2. JEUS patch
버전별 패치파일 상이
JEUS6 : jext_v6008_i215676_a1340679.jar
JEUS7: jext_v7004_i214319_a1333430.jar
JEUS8: jext_v8000_i215340_a1339733.jar

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] 버튼 클릭

출처 : https://blog.xenomity.com/Summary-Java-Agent-Bytecode-Instrumentation/

What are Java(JVM) Agent?
JVM Agent는 JVM에서 동작하는 Java 어플리케이션으로 JVM의 다양한 이벤트를 전달받거나 정보 질의, 바이트 코드 제어 등을 특정 API(Instrumentation API -java.lang.instrument-)를 통하여 수행할 수 있다.

보통 개발 도구 또는 모니터링 도구 개발에 응용된다.

바이트 코드 변조를 통한 개발의 편의성을 제공하는 AspectJ의 LTW(Load Time Weaver)나 Lombok과 같은 오픈소스가 대표적인 Java Agent의 활용 예이다.

Features
Agent는 지정된 JVM의 실행 가능한 최초 진입점인 ‘main’ 메서드를 가로채기 할 수 있다.
지정된 JVM에서 실행된다.
지정된 JVM의 동일한 System Class Loader 내에서 로드된다.
지정된 JVM의 Security Policy 및 Context의 영향을 받는다.
실행시간에 동적으로 bytecode를 조작할 수 있다.

Agent의 단일 진입점은 위와 같이 ‘premain’ 메서드를 구현하면 되며 바이트 코드를 포함한 추가적인 정보 수집 도구로 Instrumentation 인터페이스를 제공받을 수 있다.

출처 : https://m.blog.naver.com/PostView.nhn?blogId=rbtjqtjql&logNo=220993460343&proxyReferer=&proxyReferer=https:%2F%2Fwww.google.com%2F

■ BCI (Byte Code Instrumentation) ?
Java의 Byte Code에 직접 수정을 가해서, 소스 파일의 수정 없이 원하는 기능을 부여하는 기법
이러한 특징때문에 대부분의 Java 프로파일러나 모니터링 툴들이 BCI 기능을 사용하고 있다. Bytecode를 직접 수정할 수 있으므로 이를 통해 구현할 수 있는 기능은 무궁무진함.

■ Java Bytecode
JVM에서 인지할 수 있는 일종의 기계어(Machine Code)이며, 특정 OS / HW에 의존하지 않는, JVM에만 의존적이기 때문에 서로 다른 환경에서도 하나의 Bytecode로 구동이 가능(JVM은 공통이니까!!)

■ BCI를 활용하여 내가 생성한 클래스 파일 사용하게 하기
ClassReader 객체를 이용해 원래 클래스의 바이트 코드를 읽어들인다.
ClassAdapter 객체를 이용해 바이트 코드를 변경한다.
ClassWriter 객체를 이용해서 변경된 바이트 코드를 얻는다.

원래의 Exception 클래스를 변경(하진 않았지만)하여 새로운 Exception 클래스를 생성하고 파일을 확인하였다.

문제는 어떻게 하면 JVM의 rt.jar에서 제공하는 java.lang.Exception 클래스 파일이 아닌, 내가 생성한 Exception 클래스 파일을 쓰게 하느냐이다.

rt.jar파일을 직접 변경시킬순 없고 (매우 위험하고 법적인 문제가 될 수 있음!) 답은 -Xbootclasspath 옵션을 이용하는 것이다.

즉, -Xbootclasspath/p:<내가 작성한 Exception Class의 path>를 지정하면, JVM은 rt.jar보다 먼저(prepend) 내가 작성한 Exception Class 파일을 읽어들인다.

이렇게 함으로써 rt.jar 파일에 대한 수정을 가하지 않아도 된다.