4.HTTP Strict Transport Security

만약 https를 생략하고 사이트를 입력할 경우, 잠재적으로 중간자 공격에 취약할 수 있음

심지어 웹 서비스가 https로 리다이렉트 해준다고 하더라도, 악성 유저는 초기 http 요청을 가로챌 수 있고, 결과적으로 응답을 조작할 수 있게됨

→ mybank가 아닌 https:mibank.example.com으로 리다이렉트하고 자격증명(credential)을 가로채는 원리

대부분의 사용자들이 https를 생략하고 사용하며, 그래서 만들어진 것이 HTTP Strict Transport Security(HSTS)

따라서 한 번 mybank.example.com이 HSTS 호스트에 추가되면, 브라우저는 mybank.example.com에 대한 모든 요청이 https://mybank.example.com으로 해석되어야 한다는 것을 미리 알 수 있음

결과적으로 중간자 공격을 획기적으로 줄일 수 있음

💡

Tip

RFC6797에 의하면, HSTS headers는 오직 HTTPS 응답에만 삽입되어야함

브라우저가 헤더를 확인하려면, 브라우저는 먼저 연결을 위해 사용된 SSL 인증서뿐만 아니라 SSL 인증서에 서명한 CA를 신뢰해야 함

서비스가 HSTS 호스트로 표시되기 위한 방법 중 하나는 호스트를 브라우저에 미리 로드하는 것

2.Strict-Transport-Security

HSTS를 적용하기 위한 다른 방법은 Strict-Transport-Security 옵션을 응답 헤더에 추가하는 것으로, 스프링 시큐리티는 기본적으로 해당 옵션을 헤더에 추가함
이 헤더는 브라우저가 도메인을 1년 동안 HSTS 호스트로 취급하도록 지시함


Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload

그 외 부가 옵션

includeSubDomains
브라우저에게 해당 서비스의 서브도메인도 HSTS 도메인으로 처리되도록 지정
ex) secure.mybank.example.com

preload
브라우저에게 해당 도메인이 HSTS 도메인으로 미리 로딩되도록 지정

preload 참고 사이트

네이버 메인페이지의 응답 헤더에 추가되어 있는 Strict-Transport-Security옵션