와스킹의 사건현장

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 세션으로 유도) 을 통해 공격 

이러한 공격은 HSTS를 적용을 통해 SSL 연결을 강제화하여 방어 할 수 있음.

JEUS6
<commnad-option> -Djeus.servlet.jsp.modern=true </commnad-option>
 
- 오픈소스 등 웹 프레임워크를 보다 잘 지원하고 호환성 문제를 줄이기 위해서 톰캣 Jasper 기반의 JSP 파서를 사용

1. 웹서버

 1.1 KeepAlive 

   웹 서버와 웹 브라우저가 연결이 되었을 때 KeepAlive 기능이 켜져 있지 않으면, 매번 HTTP 연결을 맺었다 끊었다가 하는 작업을 반복한다.

 1.2 KeepAlive Timeout

   이 설정은 초 단위로 KeepAlive가 끊기는 시간을 지정, 즉 마지막 연결이 끝난 이후에 다음 연결이 될 때까지 얼마나 기다릴지를 지정함.


2. WAS

 2.1 DB Connection Pool 및 Thread Pool 설정

   최소 및 최대 값을 동일하게 하는 것이 좋음(Thread Pool, DB Connection Pool 공통), 만약 사용자 수가 갑자기 증가하면 DB Connection Pool의 개수도 증가되어야 하고, 증가할 때 대기 시간이 발생할 확률이 크기 때문(Thread Pool 또한 대기 시간 발생)

   DB Connection Pool은 보통 40~50개로 지정하며, Thread Pool은 이보다 10개 정도 더 지정. 이렇게 지정하는 이유는, Thread Pool의 수가 DB Connection Pool의 개수보다 적으면 적은 수만큼의 연결은 필요 없기 때문 (모든 애플리케이션이나 화면이 DB에 접속하는 것은 아님)

   그러나 최종적인 DB Connection Pool 과 Thread Pool의 수는 성능 테스트를 통해 결정하여야 함.

 2.2 WAS 인스턴스 개수 설정

   CPU 소켓당 1인스턴스를 하는 것이 좋음. 여러개의 인스턴스에서 경합을 하면서 CPU를 차지하려고 하기 때문에..

   Memory의 경우 Full GC가 발생할 때마다 많은 시간이 소요될 확률이 커지기 때문에 가급적이면 512MB~2GB 사이에서 지정

   단독 인스턴스를 구성하여 사용하는 것은 서버에 예기치 못한 상황이 발생했을 때 서비스가 불가능해지므로 되도록 피해야 함. 장비가 한 대여도, 두 개 이상의 인스턴스가 서로 클러스터링하도록 지정하여 사용자의 세션 정보를 공유하도록 하는 것이 좋음.

   Thread Pool 과 DB Connection Pool의 개수가 많을때 (통상적으로 100) 또한 인스턴스를 분리하는 것이 좋음.

 2.3 Session Timeout 시간 설정

   WEB-INF 폴더 하단의 web.xml 파일 통해 설정 

   해당 설정을 하지 않으면 세션정보를 삭제하지 않으니 필히 할 것.

 2.4 GC 설정

   GC야 말로 정답이 없음. 반드시 성능 테스트를 통해 최적의 퍼포먼스가 나오는 값을 찾아야 함.