웹 보안 정책 구현: 자바스크립트 콘텐츠 보안 가이드라인

오늘날 상호 연결된 디지털 환경에서 웹 애플리케이션 보안은 가장 중요합니다. 사이트 간 스크립팅(XSS) 공격 및 기타 코드 주입 취약점을 완화하는 가장 효과적인 방법 중 하나는 콘텐츠 보안 정책(CSP)을 구현하는 것입니다. 이 종합 가이드는 특히 자바스크립트 콘텐츠 보안 가이드라인에 초점을 맞춰 CSP의 복잡성을 자세히 설명합니다.

콘텐츠 보안 정책(CSP)이란 무엇인가?

콘텐츠 보안 정책(CSP)은 웹사이트 관리자가 특정 페이지에 대해 사용자 에이전트가 로드할 수 있는 리소스를 제어할 수 있도록 하는 HTTP 응답 헤더입니다. 이는 본질적으로 스크립트, 스타일시트, 이미지, 글꼴 및 기타 리소스의 출처를 지정하는 화이트리스트입니다. CSP를 정의함으로써 브라우저가 공격자에 의해 주입된 악성 코드를 실행하는 것을 방지하여 XSS 공격의 위험을 크게 줄일 수 있습니다.

CSP는 '기본 거부(default deny)' 원칙에 따라 작동합니다. 즉, 기본적으로 브라우저는 정책에서 명시적으로 허용되지 않은 모든 리소스를 차단합니다. 이 접근 방식은 공격 표면을 효과적으로 제한하고 다양한 위협으로부터 웹 애플리케이션을 보호합니다.

왜 자바스크립트 보안에 CSP가 중요한가?

자바스크립트는 클라이언트 측 스크립팅 언어이므로 악성 코드를 주입하려는 공격자들의 주요 표적이 됩니다. 공격자가 다른 사용자가 보는 웹사이트에 악성 스크립트를 주입하는 XSS 공격은 일반적인 위협입니다. CSP는 자바스크립트 코드가 실행될 수 있는 출처를 제어함으로써 XSS 공격을 완화하는 데 특히 효과적입니다.

CSP가 없으면 성공적인 XSS 공격을 통해 공격자는 다음을 수행할 수 있습니다:

• 사용자 쿠키 및 세션 토큰 탈취.
• 웹사이트 변조.
• 사용자를 악성 웹사이트로 리디렉션.
• 사용자 브라우저에 맬웨어 주입.
• 민감한 데이터에 대한 무단 접근 획득.

CSP를 구현함으로써 브라우저가 승인되지 않은 자바스크립트 코드를 실행하는 것을 방지하여 이러한 공격의 위험을 크게 줄일 수 있습니다.

자바스크립트 보안을 위한 주요 CSP 지시문

CSP 지시문은 허용된 리소스 소스를 정의하는 규칙입니다. 특히 자바스크립트 보안과 관련된 몇 가지 지시문이 있습니다:

script-src

script-src 지시문은 자바스크립트 코드를 로드할 수 있는 위치를 제어합니다. 이는 자바스크립트 보안에 있어 아마도 가장 중요한 지시문일 것입니다. 다음은 몇 가지 일반적인 값입니다:

• 'self': 문서와 동일한 출처의 스크립트를 허용합니다. 일반적으로 좋은 시작점입니다.
• 'none': 모든 스크립트를 허용하지 않습니다. 페이지에 자바스크립트가 필요하지 않은 경우 사용합니다.
• 'unsafe-inline': 인라인 스크립트(<script> 태그 내 스크립트) 및 이벤트 핸들러(예: onclick)를 허용합니다. CSP를 크게 약화시키므로 극도의 주의를 기울여 사용해야 합니다.
• 'unsafe-eval': eval() 및 Function()과 같은 관련 함수의 사용을 허용합니다. 보안상의 영향으로 인해 가능한 한 피해야 합니다.
• https://example.com: 특정 도메인의 스크립트를 허용합니다. 정확하게 지정하고 신뢰할 수 있는 도메인만 허용하십시오.
• 'nonce-value': 특정 암호화 nonce 속성이 있는 인라인 스크립트를 허용합니다. 이는 'unsafe-inline'에 대한 더 안전한 대안입니다.
• 'sha256-hash': 특정 SHA256 해시가 있는 인라인 스크립트를 허용합니다. 이는 'unsafe-inline'에 대한 또 다른 더 안전한 대안입니다.

예시:

script-src 'self' https://cdn.example.com;

이 정책은 동일한 출처와 https://cdn.example.com의 스크립트를 허용합니다.

default-src

default-src 지시문은 다른 fetch 지시문에 대한 대체(fallback) 역할을 합니다. 특정 지시문(예: script-src, img-src)이 정의되지 않은 경우 default-src 정책이 적용됩니다. 예상치 못한 리소스 로딩 위험을 최소화하기 위해 제한적인 default-src를 설정하는 것이 좋습니다.

예시:

default-src 'self';

이 정책은 기본적으로 동일한 출처의 리소스를 허용합니다. 다른 리소스 유형은 더 구체적인 지시문이 허용하지 않는 한 차단됩니다.

style-src

주로 CSS 소스를 제어하기 위한 것이지만, style-src 지시문은 CSS에 표현식이 포함되거나 악용될 수 있는 기능을 사용하는 경우 자바스크립트 보안에 간접적으로 영향을 미칠 수 있습니다. script-src와 마찬가지로 스타일시트의 소스를 제한해야 합니다.

예시:

style-src 'self' https://fonts.googleapis.com;

이 정책은 동일한 출처와 Google Fonts의 스타일시트를 허용합니다.

object-src

object-src 지시문은 Flash와 같은 플러그인의 소스를 제어합니다. Flash는 점점 덜 사용되고 있지만, 악성 콘텐츠가 로드되는 것을 방지하기 위해 플러그인 소스를 제한하는 것은 여전히 중요합니다. 일반적으로 플러그인에 대한 특정 요구 사항이 없는 한 이 값을 'none'으로 설정하는 것이 좋습니다.

예시:

object-src 'none';

이 정책은 모든 플러그인을 허용하지 않습니다.

자바스크립트로 CSP를 구현하기 위한 모범 사례

CSP를 효과적으로 구현하려면 신중한 계획과 고려가 필요합니다. 다음은 따라야 할 몇 가지 모범 사례입니다:

1. 보고서 전용(Report-Only) 정책으로 시작하기

CSP를 시행하기 전에 보고서 전용 정책으로 시작하는 것이 좋습니다. 이를 통해 실제로 리소스를 차단하지 않고 정책의 효과를 모니터링할 수 있습니다. Content-Security-Policy-Report-Only 헤더를 사용하여 보고서 전용 정책을 정의할 수 있습니다. 정책 위반은 report-uri 지시문을 사용하여 지정된 URI로 보고됩니다.

예시:

Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;

이 정책은 리소스를 차단하지 않고 /csp-report-endpoint로 위반 사항을 보고합니다.

2. 'unsafe-inline' 및 'unsafe-eval' 피하기

앞서 언급했듯이 'unsafe-inline'과 'unsafe-eval'은 CSP를 크게 약화시키므로 가능한 한 피해야 합니다. 인라인 스크립트와 eval()은 XSS 공격의 일반적인 표적입니다. 인라인 스크립트를 사용해야 하는 경우 nonce나 해시를 사용하는 것을 고려하십시오.

3. 인라인 스크립트에 Nonce 또는 해시 사용하기

Nonce와 해시는 인라인 스크립트를 허용하는 더 안전한 방법을 제공합니다. Nonce는 <script> 태그에 추가되고 CSP 헤더에 포함되는 임의의 일회용 문자열입니다. 해시는 스크립트 콘텐츠의 암호화 해시로, 이 또한 CSP 헤더에 포함됩니다.

Nonce 사용 예시:

HTML:

<script nonce="randomNonceValue">console.log('Inline script');</script>

CSP 헤더:

script-src 'self' 'nonce-randomNonceValue';

해시 사용 예시:

HTML:

<script>console.log('Inline script');</script>

CSP 헤더:

script-src 'self' 'sha256-uniqueHashValue'; (`uniqueHashValue`를 스크립트 내용의 실제 SHA256 해시로 대체)

참고: 스크립트에 대한 올바른 해시 생성은 빌드 도구나 서버 측 코드를 사용하여 자동화할 수 있습니다. 또한 스크립트 내용이 변경되면 해시를 다시 계산하고 업데이트해야 합니다.

4. 출처를 구체적으로 지정하기

CSP 지시문에서 와일드카드 문자(*) 사용을 피하십시오. 대신 허용하려는 정확한 출처를 지정하십시오. 이렇게 하면 신뢰할 수 없는 소스를 실수로 허용할 위험을 최소화할 수 있습니다.

예시:

다음 대신:

script-src *; (매우 권장하지 않음)

다음을 사용:

script-src 'self' https://cdn.example.com https://api.example.com;

5. 정기적으로 CSP 검토 및 업데이트하기

CSP는 웹 애플리케이션의 변경 사항과 진화하는 위협 환경을 반영하기 위해 정기적으로 검토하고 업데이트해야 합니다. 새로운 기능을 추가하거나 새로운 서비스와 통합할 때 필요한 리소스를 허용하도록 CSP를 조정해야 할 수 있습니다.

6. CSP 생성기 또는 관리 도구 사용하기

CSP를 생성하고 관리하는 데 도움이 되는 여러 온라인 도구와 브라우저 확장 프로그램이 있습니다. 이러한 도구는 강력한 CSP를 만들고 유지 관리하는 과정을 단순화할 수 있습니다.

7. CSP를 철저히 테스트하기

CSP를 구현하거나 업데이트한 후에는 모든 리소스가 올바르게 로드되고 기능이 손상되지 않았는지 확인하기 위해 웹 애플리케이션을 철저히 테스트하십시오. 브라우저 개발자 도구를 사용하여 CSP 위반 사항을 식별하고 그에 따라 정책을 조정하십시오.

CSP 구현의 실제 예시

다양한 시나리오에 대한 CSP 구현의 실제 예시를 살펴보겠습니다:

예시 1: CDN을 사용하는 기본 웹사이트

자바스크립트 및 CSS 파일에 CDN을 사용하는 기본 웹사이트:

CSP 헤더:

default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self' https://fonts.gstatic.com;

이 정책은 다음을 허용합니다:

• 동일한 출처의 리소스.
• https://cdn.example.com의 스크립트 및 스타일시트.
• 동일한 출처 및 데이터 URI의 이미지.
• 동일한 출처 및 Google Fonts(https://fonts.gstatic.com)의 글꼴.

예시 2: 인라인 스크립트 및 스타일이 있는 웹사이트

nonce를 사용하여 인라인 스크립트 및 스타일을 사용하는 웹사이트:

HTML:

<script nonce="uniqueNonce123">console.log('Inline script');</script> <style nonce="uniqueNonce456">body { background-color: #f0f0f0; }</style>

CSP 헤더:

default-src 'self'; script-src 'self' 'nonce-uniqueNonce123'; style-src 'self' 'nonce-uniqueNonce456'; img-src 'self' data:;

이 정책은 다음을 허용합니다:

• 동일한 출처의 리소스.
• nonce가 "uniqueNonce123"인 인라인 스크립트.
• nonce가 "uniqueNonce456"인 인라인 스타일.
• 동일한 출처 및 데이터 URI의 이미지.

예시 3: 엄격한 CSP를 사용하는 웹사이트

매우 엄격한 CSP를 목표로 하는 웹사이트:

CSP 헤더:

default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; base-uri 'self'; form-action 'self';

이 정책은 다음을 허용합니다:

• 동일한 출처의 리소스만 허용하며, 특별히 허용되지 않는 한 다른 모든 유형의 리소스를 명시적으로 비활성화합니다.
• 또한 기본 URI 및 양식 작업을 동일한 출처로 제한하는 등 추가적인 보안 조치를 시행합니다.

CSP와 최신 자바스크립트 프레임워크(React, Angular, Vue.js)

React, Angular 또는 Vue.js와 같은 최신 자바스크립트 프레임워크를 사용할 때 CSP 구현에는 특별한 주의가 필요합니다. 이러한 프레임워크는 종종 인라인 스타일, 동적 코드 생성 및 eval()과 같은 기술을 사용하며, 이는 CSP에 문제가 될 수 있습니다.

React

React는 일반적으로 컴포넌트 스타일링을 위해 인라인 스타일을 사용합니다. 이를 해결하기 위해 nonce나 해시를 지원하는 CSS-in-JS 라이브러리를 사용하거나 스타일을 CSS 파일로 외부화할 수 있습니다.

Angular

Angular의 JIT(Just-In-Time) 컴파일은 eval()에 의존하므로 엄격한 CSP와 호환되지 않습니다. 이를 극복하려면 빌드 과정에서 애플리케이션을 컴파일하고 런타임에 eval()의 필요성을 제거하는 AOT(Ahead-Of-Time) 컴파일을 사용해야 합니다.

Vue.js

Vue.js도 인라인 스타일과 동적 코드 생성을 사용합니다. React와 유사하게 CSS-in-JS 라이브러리를 사용하거나 스타일을 외부화할 수 있습니다. 동적 코드 생성을 위해 빌드 과정에서 Vue.js의 템플릿 컴파일러를 사용하는 것을 고려하십시오.

CSP 보고

CSP 보고는 구현 과정의 필수적인 부분입니다. report-uri 또는 report-to 지시문을 구성하여 CSP 위반에 대한 보고서를 받을 수 있습니다. 이러한 보고서는 정책의 문제를 식별하고 수정하는 데 도움이 될 수 있습니다.

report-uri 지시문은 브라우저가 CSP 위반 보고서를 JSON 페이로드로 전송해야 하는 URL을 지정합니다. 이 지시문은 report-to를 위해 더 이상 사용되지 않고 있습니다.

report-to 지시문은 Report-To 헤더에 정의된 그룹 이름을 지정합니다. 이 헤더를 사용하면 다양한 보고 엔드포인트를 구성하고 우선순위를 지정할 수 있습니다.

report-uri 사용 예시:

Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;

report-to 사용 예시:

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"/csp-report-endpoint"}]} Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

도구 및 리소스

CSP를 구현하고 관리하는 데 도움이 되는 몇 가지 도구와 리소스가 있습니다:

• CSP Evaluator: CSP를 분석하고 평가하기 위한 도구.
• CSP Generator: CSP 헤더를 생성하기 위한 도구.
• 브라우저 개발자 도구: 대부분의 브라우저에는 CSP 위반을 식별하는 데 도움이 되는 내장 개발자 도구가 있습니다.
• Mozilla Observatory: CSP를 포함하여 웹사이트에 대한 보안 권장 사항을 제공하는 웹사이트.

일반적인 함정과 이를 피하는 방법

CSP 구현은 어려울 수 있으며, 피해야 할 몇 가지 일반적인 함정이 있습니다:

• 지나치게 관대한 정책: 절대적으로 필요한 경우가 아니면 와일드카드 문자나 'unsafe-inline' 및 'unsafe-eval' 사용을 피하십시오.
• 잘못된 Nonce/해시 생성: nonce가 임의적이고 고유한지, 해시가 올바르게 계산되었는지 확인하십시오.
• 철저하지 않은 테스트: CSP를 구현하거나 업데이트한 후에는 항상 테스트하여 모든 리소스가 올바르게 로드되는지 확인하십시오.
• CSP 보고서 무시: 정기적으로 CSP 보고서를 검토하고 분석하여 문제를 식별하고 수정하십시오.
• 프레임워크 특성을 고려하지 않음: 사용 중인 자바스크립트 프레임워크의 특정 요구 사항과 제한 사항을 고려하십시오.

결론

콘텐츠 보안 정책(CSP)은 웹 애플리케이션 보안을 강화하고 XSS 공격을 완화하는 강력한 도구입니다. CSP를 신중하게 정의하고 모범 사례를 따르면 코드 주입 취약점의 위험을 크게 줄이고 사용자를 악성 콘텐츠로부터 보호할 수 있습니다. 보고서 전용 정책으로 시작하고, 'unsafe-inline' 및 'unsafe-eval'을 피하고, 출처를 구체적으로 지정하며, 정기적으로 CSP를 검토하고 업데이트하는 것을 기억하십시오. CSP를 효과적으로 구현함으로써 사용자를 위한 더 안전하고 신뢰할 수 있는 웹 환경을 만들 수 있습니다.

이 가이드는 자바스크립트를 위한 CSP 구현에 대한 포괄적인 개요를 제공했습니다. 웹 보안은 끊임없이 진화하는 분야이므로 최신 모범 사례와 보안 지침에 대한 정보를 계속 접하는 것이 중요합니다. 강력한 CSP를 구현하여 웹 애플리케이션을 보호하고 잠재적인 위협으로부터 사용자를 보호하십시오.