03. Spring security Features 요약 : Security Http Response Headers

웹 애플리케이션의 보안을 위해 사용할 수 있는 HTTP 응답 헤더는 다양하다. 스프링 시큐리티는 자체적으로 지원하는 여러 HTTP 응답 헤더를 지원한다. 필요하다면 스프링 시큐리티에 커스텀 헤더를 설정할 수도 있다.

 

Default Security Headers

스프링 시큐리티는 기본적인 보안을 위한 HTTP 응답 헤더의 디폴트 셋을 제공한다.

Default Security HTTP Response Headers

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires:0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

Strinct-Transport-Security 헤더는 HTTP 요청에만 추가된다.

Cache-Control

스프링 시큐리티는 사용자 컨텐츠를 보호하기 위해 기본적으로 캐시를 비활성화한다. 따라서 특정 권한을 받은 사용자가 로그아웃했을 때, 다른 사용자가 악의적으로 뒤로 가기 버튼을 눌러도 해당 정보를 보지 못한다.

Cache-Control 헤더는 기본적으로 다음과 같이 전송한다.

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

만약 애플리케이션 자체가 Cache-Control 헤더를 사용한다면, 스프링 시큐리티는 기본 값을 추가하지 않는다. 이러한 특성을 활용해서 애플리케이션에서 원하는 정적 리소스를 캐시할 수 있다.

Content Type Options Security

악의적인 사용자는 브라우저를 통해 컨텐츠 스니핑을 사용해 요청의 타입을 추론할 수 있다.

스프링 시큐리티의 경우 기본적으로 HTTP dㅡㅇ답에 다음 헤더를 추가해서 컨텐츠 스니핑을 비활성화 한다.

X-Content-Type-Options: nosniff

 

HTTP Strict Transport Security (HSTS)

보통 특정 웹사이트를 직접 타이핑해서 방문할 때,https:// 문구를 생략하는 경우가 많다. 이러한 습관은 중간자 공격(Man in the Middle attack)에 취약하다.

이러한 취약점을 예방하기 위해 HSTS가 생겼다.

HSTS로 인해, 주소창에 프로토콜 입력을 생략해도, https 프로토콜로 접근해야한다는 것을 브라우저가 미리 알 수 있게 한다. 따라서, 중간자 공격을 받을 가능성이 현저히 떨어진다.

RFC6797 에 따르면 HTTPS 응답에만 HSTS 헤더를 추가한다. 또한 브라우저가 헤더를 인식하려면 먼저 브라우저가 신뢰할 수 있는 CA에서 서명한 SSL 인증서로 커넥션을 맺어야 한다. (단순히 SSL 인증서라고 다 되는 게 아니다.)

사이트를 HSTS 호스트로 표시하는 방법은 브라우저에 미리 호스트를 로드하는 것이다.

또 한가지 방법은 Strict-Transport-Security 헤더를 추가하는 방법도 있다. 스프링 시큐리티의 경우 이 방법을 채택하고 있고, 해당 브라우저에게 1년간 요청을 하는 도메인을 HSTS 호스트로 취급하라고 알린다.

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

• includeSubDomains는 선택 사항인데, 하위 도메인 역시 HSTS 도메인으로 취급해야 한다고 알리는 지시문이다.
• preload도 선택이며, 이는 브라우저에게 이 도메인을 미리 HSTS 도메인으로 로드하도록 알린다.
• 자세한 내용은 https://hstspreload.org를 참고하라.

HTTP Public Key Pinning (HPKP)

스프링 시큐리티는 하위 호환성을 위해 아직 해당 기능을 지원하고 있지만, HTTPS 활용도 증가 및 해당 기능의 복잡성으로 인해 이제는 사용을 권장하지 않는 방식이다.

HPKP는 특정 웹 서버에서 사용할 공개키를 웹 클라이언트에 지정하는 방식으로 중간자 공격을 방어한다. 이 기능의 복잡성으로 인해 크롬은 이 기능을 지원하지 않는다.

X-Frame-Options

프레임에 웹사이트를 넣을 수 있게 허용하는 것은 보안 이슈가 있다. CSS를 활용하여 클릭재킹(Clickjacking)을 당하게 할 수 있다.

• 클릭재킹을 방어하는 방법 중 하나는 컨텐츠 보안 정책(Content Security Policy, CSP)이 있다.
• 또 하나는 X-Frame-Options 헤더로 방어를 하는 것인데, 이 방법은 최신 브라우저에서 많이 사용되는 방법이고, 스프링 시큐리티가 기본적으로 지원하는 기능이기도 하다.

X-Frame-Options: DENY

 

X-XSS-Protection

일부 브라우저는 기본적으로 reflected XSS 공격을 필터링 한다. 완벽하진 않지만, 일차적으로 막아주는 것은 맞다.

이 필터링 기능은 디폴트로 활성화되어 있기 때문에 이 헤더를 추가하는 것만으로 확인할 수 있고, 브라우저가 XSS 공격을 감지했을 때 할 일을 지시할 수 있다. 대부분의 경우 가장 덜 극단적인 방법을 채택하여, 컨텐츠를 수정하고 페이지를 전부 렌더링하게 만들 수 있다. 하지만 수정하는 것 자체로도 XSS 취약점이 되기도 한다. 따라서 컨텐츠를 수정하는 것보다는 아예 막아버리는 것이 가장 좋다. 스프링 시큐리티는 기본적으로 다음 헤더를 사용해서 컨텐츠 허용을 막는다.

X-XSS-Protection: 1; mode=block

 

Content Security Policy (CSP)

컨텐츠 보안 정책(CSP)는 XSS와 같은 컨텐츠 인젝션 공격에 대한 취약성을 개선할 수 있는 메커니즘이다. CSP는 애플리케이션이 로드할 수 있는 리소스를 개발자가 직접 명시해서 클라이언트 (user-agent)에게 알리는 정책이다.

CSP는 모든 인젝션 공격 취약점을 해결해 주지 않는다. 다만 피해를 최소화해준다고 봐야 한다. 일차적인 방어는 애플리케이션에서 입력을 검증하고 출력을 인코딩하는 것이다.

애플리케이션이 CSP를 사용하려면 다음 헤더 중 하나를 HTTP 응답에 추가하면 된다.

• Content-Security-Policy
• Content-Security-Policy-Report-Only

이 헤더는 클라이언트에게 보안 정책을 전달하는 매커니즘으로 사용된다. 아래 예시에서 다음과 같은 헤더를 추가하면, 신뢰할 수 있는 특정 리소스에만 스크립트를 로드한다.

Content-Security-Policy: script-src https://trustedscripts.example.com

script-src에 선언한 리소스 외의 다른 리소스에서 스크립트를 로드하려고 하면 user-agent에서 막힌다. 추가로 보안 정책에 report-uri를 선언하면 지정 url에 보고한다.

Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/

Violation reports는 표준 JSON 구조를 따르며, 웹 애플리케이션 자체 API로 수집할 수도 있고, https://report-uri.io/ 같은 공개적으로 호스팅되는 CSP violation 리포팅 서비스를 이요해도 된다.

Content-Security-Policy-Report-Only 헤더를 사용하면 보안 정책을 바로 적용하는 대신, 개발자와 관리자가 보안 정책을 모니터링할 수 있다. 이 헤더는 보통 보안 정책이 실험/개발 단계일 때 사용한다.

실제로 보안 정책을 시행할때는 Content-Security-Policy 헤더 필드를 대신 사용한다.

Content-Security-Policy-Report-Only: script-src 'self'
https://trustedscripts.example.com; report-uri /csp-report-endpoint/

 

Referrer Policy

이 정책은 사용자가 마지막으로 방문한 페이지를 가지고 있는 referrer 필드를 관리할 수 있는 메커니즘이다.

스프링 시큐리티는 다양한 정책을 지원하는 Referrer-Policy 헤더를 사용한다.

Referrer-Policy: same-origin

응답 헤더에 Referrer-Policy를 사용하면 브라우저로 하여금 사용자가 이전에 방문했던 곳을 도착지에 알린다.

Feature Policy

Feature 정책은 웹 개발자가 원하는 대로 특정 API와 브라우저의 웹 기능을 활서오하, 비활성화하는 동작을 수정할 수 있게 해 준다.

Feature-Policy: geoloaction 'self'

해당 정책을 사용하면, 개발자가 브라우저의 정책 집함에 관여해서 사이트 전체에서 사용할 특정 기능을 강제할 수 있다.

Clear Site Data

Clear Site Data는 HTTP 응답에 아래 헤더를 추가해서 쿠키, 로컬 스토리지 등의 브라우 단 데이터를 삭제할 수 있는 메커니즘이다.

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"

데이터 삭제는 로그아웃할 때 실행하기 알맞은 작업이다.

Custom Headers

스프링 시큐리티는 좀 더 일반적인 보안 헤더를 애플리케이션에 편리하게 추가할 수 있는 메커니즘을 제공한다. 또한, 커스텀 헤더를 추가할 수 있는 hook도 함께 제공한다.