HTTP 보안 헤더란? 5가지 주요 보안 헤더와 설정 방법

1. HTTP 보안 헤더의 필요성

웹의 기반 기술인 HTTP(HyperText Transfer Protocol)는 웹 상에서 정보를 교환하기 위해 설계된 프로토콜입니다. HTTP는 간단하고 확장 가능한 프로토콜이라는 장점을 가지고 있지만, 기본적으로 암호화되지 않은 텍스트 형태로 데이터를 전송한다는 점에서 보안 취약점을 내포하고 있습니다. 이러한 특성으로 데이터 도청, 변조, 그리고 중간자 공격(Man-in-the-Middle Attack)과 같은 사이버 공격에 노출될 수 있습니다.

이러한 문제를 해결하기 위해 HTTP 보안 헤더가 필요하게 되었습니다. 보안 헤더는 웹에서 동시에 작동함으로써 웹 애플리케이션을 다양한 공격으로부터 보호하는 포괄적인 보안 체계를 구축합니다. 보안 헤더는 HTTP 응답에 추가적인 요청 사항을 포함시켜서 브라우저가 데이터를 안전하게 처리하도록 유도합니다. 각 요청 사항은 데이터의 무결성을 보장하고, 사용자의 개인 정보를 보호하며, 악의적인 사용자로부터 애플리케이션을 보호하는 역할을 합니다.

2. 5가지 주요 HTTP 보안 헤더

보안 헤더는 각기 다른 측면을 목표로 하여 안전한 애플리케이션의 운영을 도와줍니다. 특히, XSS, 중간자 공격, 클릭재킹 등 다양한 사이버 위협에 대응하기 위해 설계된 주요 보안 헤더들은 웹 애플리케이션의 보안을 크게 향상시켜 줍니다. 이번 뉴스레터는 필수적인 5개의 HTTP 보안 헤더에 대해 소개해드리겠습니다.

1. Content-Security-Policy (CSP)

CSP는 웹 애플리케이션에 대한 XSS 공격을 방지하기 위한 역할을 합니다. CSP를 통해 개발자들은 웹 페이지에서 실행될 수 있는 스크립트의 출처를 제한할 수 있고, 이를 통해 악의적인 스크립트의 실행을 방지합니다. 또한, CSP는 웹 페이지에 로드될 수 있는 이미지, 폰트, 플러그인 등의 다른 리소스에 대해서도 동일한 정책을 적용할 수 있습니다.

자체 정책이 명시되지 않았을 경우, 다른 리소스 유형에 대한 기본 정책 역할을 하는 default-src 지시문을 포함해야 합니다. default-src 지시문은 다른 CSP 지시문이 정의되지 않은 상황에서 대체 기능을 수행합니다.

2. HTTP Strict-Transport-Security (HSTS)

HSTS는 웹 애플리케이션과 사용자 간의 모든 통신이 HTTPS 프로토콜을 통해 이루어지도록 강제합니다. 이는 중간자 공격을 통해 데이터를 가로채는 것을 방지하고, 사용자의 개인 정보와 민감한 데이터를 보호하는 데 효과적입니다.

preload 옵션을 활용할 경우, OWASP 권장 사항에 따라 max-age는 최소 31536000(1년) 이상으로 설정되어야 하며, includeSubDomains을 포함해야 합니다. includeSubDomains은 선택적 매개변수로, 이를 사용하면 설정된 규칙이 사이트의 모든 하위 도메인에도 적용됩니다. max-age 값은 0으로 설정하게 되면, 정책이 즉시 만료되어 HTTP 연결이 다시 허용되니 주의해야합니다.

HSTS는 이전에 뉴스레터로 설명드린 Secure 쿠키 플래그와 유사한 보안 목적을 가지고 있지만, 두 기술은 서로 다른 보안 측면을 다룹니다. HSTS는 클라이언트에 HTTPS 프로토콜 사용을 강제하는 반면, Secure 쿠키 플래그는 쿠키 데이터가 HTTPS를 통해서만 전송되도록 합니다. 여기서 의문이 생길 수 있습니다.

“쿠키 내용도 텍스트라 암호화되므로, HSTS만으로 충분하지 않을까?”

그러나, HSTS는 첫 번째 웹 사이트 방문 시 자동으로 보호하지 않고, 정책이 만료된 후 HTTPS 연결이 강제되기 전에 쿠키 정보가 노출될 위험이 있습니다. 반면, Secure 쿠키 플래그는 이러한 상황에서 추가적인 보호층을 제공할 수 있습니다. 또한, Secure 플래그는 특정 요구사항이나 규제 준수 목적으로도 중요합니다. 따라서, 두 설정은 각기 다른 보안 기능을 제공하므로, 별도로 고려되어야 합니다.

3. X-Content-Type-Options

X-Content-Type-Options는 브라우저가 MIME 타입 스니핑을 방지하여, 공격자가 MIME 타입을 활용하여 공격하는 것을 막습니다. MIME 타입은 RFC 6838에 정의된 ‘application/javascript’, ‘text/html’ 등과 같은 문서, 파일 또는 바이트 모음의 특성과 형식을 뜻합니다.

nosniff 설정으로 웹 서버가 명시한 MIME 타입을 브라우저가 변경하지 않도록 하여, 스크립트나 스타일시트가 비정상적으로 실행되는 것을 방지합니다.

4. X-Frame-Options

X-Frame-Options 헤더는 클릭재킹 공격에 대응하여 웹 페이지가 다른 페이지의 프레임 내에 표시되는 것을 방지합니다. X-Frame-Options은 웹 페이지가 <frame>, <iframe>, <object>, <embed> 태그를 통해 다른 사이트에 의해 포함되는 것을 제한함으로써, 사용자가 의도치 않은 조작을 수행하게 하는 공격을 방지합니다.

X-Frame-Options는 deny, sameorigin, allow-from uri 세 가지로 사용됩니다. 이 중 DENY 옵션을 사용하는 것은 가장 엄격한 방식으로, 페이지가 어떠한 경우에도 다른 페이지 내에 포함되지 않도록 보장합니다. 보안상의 이유로 많은 웹 사이트가 DENY를 사용하고, OWASP에서도 권장하는 방식입니다. 하지만 웹 사이트가 자체 리소스 내에서 페이지를 프레임으로 사용하는 경우가 필요하다면, SAMEORIGIN 옵션이 적합할 수도 있습니다.

5. X-XSS-Protection

X-XSS-Protection은 과거에 브라우저의 내장 XSS 보호 기능을 활성화하고 구성하는 데 사용되었습니다. 특히, Internet Explorer에서 XSS 공격을 탐지하고 차단하는 데 효과적이었습니다. 그러나 XSS를 탐지하는 XSS Auditor를 우회하는 취약점을 시작으로 pure 자바스크립트 삽입, DOM 기반 XSS는 Auditor가 탐지하지 못하는 등 여러 취약점들이 드러나면서 지원이 중단되었습니다.

현재 X-XSS-Protection은 OWASP를 비롯한 보안 커뮤니티에서 권장하지 않는 헤더로, 사용 시 오히려 애플리케이션이 취약해질 수 있습니다. Chrome, Firefox, Edge 등 최신 브라우저들도 이 헤더의 지원을 중단했습니다.

3. 안전한 보안 헤더 구성 예시

1. Content-Security-Policy: default-src ‘self’; form-action ‘self’; object-src ‘none’; frame-ancestors ‘none’; upgrade-insecure-requests; block-all-mixed-content

2. Strict-Transport-Security: max-age=31536000; includeSubDomains

3. X-Content-Type-Options: nosniff

4. X-Frame-Options: deny

5. X-XSS-Protection: 0

이 보안 헤더 설정은 OWASP Secure Headers Project의 권장 사항을 바탕으로 구성되었습니다. 자세한 정보는 OWASP의 공식 문서에서 확인 가능합니다. 자주 사용되는 JavaScript 애플리케이션의 경우, Helmet과 같은 라이브러리를 활용하면 보안 헤더 설정을 손쉽게 진행할 수 있습니다.

웹 보안 헤더는 웹 애플리케이션을 다양한 공격으로부터 보호하는 데 중요한 역할을 합니다. OWASP Secure Headers Project에서 권장하는 보안 헤더로 구성하면 웹 애플리케이션의 보안 수준을 현저하게 강화할 수 있습니다. HTTP 보안 헤더는 공격자들이 악용할 수 있는 보안 취약점을 효과적으로 줄여줍니다. 그러나 X-XSS-Protection와 같이 보안 연구와 브라우저의 발전에 따라 더 이상 권장되지 않는 경우도 있으니 주의가 필요합니다. 이는 보안 헤더 설정이 일회성 작업이 아니라 지속적인 관심이 필요함을 의미합니다. 따라서, OWASP와 같은 신뢰할 수 있는 자료를 정기적으로 참조하여 최신 보안 기준을 확인하고, 웹 애플리케이션의 보안을 지속적으로 강화하는 노력이 필요합니다.

[참고 자료]
1. OWASP: https://owasp.org/www-project-secure-headers/index.html#configuration-proposal
2. MDN: https://developer.mozilla.org/ko/docs/Web/HTTP/CSP
3. Helmet: https://www.npmjs.com/package/helmet
4. X-XSS-Protection: https://github.com/helmetjs/helmet/issues/230
5. X-XSS-Protection 관련 논의 : https://www.zdnet.com/article/google-to-remove-chromes-built-in-xss-protection-xss-auditor/
6. X-XSS-Protection 크롬 지원 중단 사례 : https://chromestatus.com/feature/5021976655560704
7. X-XSS-Protection 파이어폭스 지원 중단 사례 : https://bugzilla.mozilla.org/show_bug.cgi?id=528661
8. X-XSS-Protection 엣지 지원 중단 사례 : https://blogs.windows.com/windows-insider/2018/07/25/announcing-windows-10-insider-preview-build-17723-and-build-18204/
9. RFC 6838: https://datatracker.ietf.org/doc/html/rfc6838