콘텐츠 보안 정책 (CSP)은 페이지에 로드된 모든 콘텐츠가 사이트 소유자가 신뢰할 수 있도록 하는 데 도움이 됩니다. CSP는 공격자가 삽입한 안전하지 않은 스크립트를 차단할 수 있으므로 교차 사이트 스크립팅 (XSS) 공격을 완화합니다. 하지만 CSP가 충분히 엄격하지 않으면 쉽게 우회할 수 있습니다. 자세한 내용은 엄격한 콘텐츠 보안 정책 (CSP)으로 교차 사이트 스크립팅 (XSS) 완화를 참고하세요. Lighthouse는 기본 문서에 적용된 CSP를 수집하고 우회할 수 있는 경우 CSP 평가 도구의 문제를 보고합니다.
우회할 수 없는 CSP의 필수 관행
CSP를 우회할 수 없도록 하려면 다음 관행을 구현하세요. CSP를 우회할 수 있는 경우 Lighthouse에서 심각도가 높은 경고를 내보냅니다.
CSP가 XSS를 타겟팅함
XSS를 타겟팅하려면 CSP에 script-src, object-src, base-uri 지시어가 포함되어야 합니다. CSP에는 구문 오류가 없어야 합니다.
script-src 및 object-src는 각각 안전하지 않은 스크립트와 안전하지 않은 플러그인으로부터 페이지를 보호합니다. 또는 default-src를 사용하여 script-src 및 object-src를 비롯한 다양한 디렉티브 대신 광범위한 정책을 구성할 수 있습니다.
base-uri는 모든 상대 URL (예: 스크립트)을 공격자가 제어하는 도메인으로 리디렉션하는 데 사용할 수 있는 승인되지 않은 <base> 태그의 삽입을 방지합니다.
CSP가 허용 목록 우회를 방지하기 위해 nonce 또는 해시를 사용함
script-src의 허용 목록을 구성하는 CSP는 신뢰할 수 있는 도메인에서 발생하는 모든 응답이 안전하고 스크립트로 실행될 수 있다는 가정을 사용합니다. 그러나 이 가정은 최신 애플리케이션에는 적용되지 않습니다. JSONP 인터페이스 노출, AngularJS 라이브러리 사본 호스팅과 같은 일반적이고 무해한 패턴으로 인해 공격자가 CSP의 제약 조건을 회피할 수 있습니다.
실제로 애플리케이션 작성자에게는 명확하지 않을 수 있지만 대부분의 script-src 허용 목록은 XSS 버그가 있는 공격자가 우회할 수 있으며 스크립트 삽입에 대한 보호 기능이 거의 없습니다. 반면 nonce 기반 및 해시 기반 접근 방식은 이러한 문제가 없으며 더 안전한 정책을 더 쉽게 채택하고 유지할 수 있습니다.
예를 들어 이 코드는 신뢰할 수 있는 도메인에 호스팅된 JSONP 엔드포인트를 사용하여 공격자가 제어하는 스크립트를 삽입합니다.
CSP:
script-src https://trusted.example.com
HTML:
<script src="https://trusted.example.com/path/jsonp?callback=alert(document.domain)//"></script>
우회되지 않도록 하려면 CSP는 nonce 또는 해시를 사용하여 스크립트를 개별적으로 허용하고 허용 목록 대신 'strict-dynamic'을 사용해야 합니다.
안전한 CSP를 위한 추가 권장사항
보안 및 호환성을 강화하려면 다음 권장사항을 구현하세요. CSP가 권장사항 중 하나를 따르지 않으면 Lighthouse에서 중간 심각도 경고를 내보냅니다.
CSP 보고 구성
보고 대상을 구성하면 중단을 모니터링하는 데 도움이 됩니다. report-uri 또는 report-to 디렉티브를 사용하여 보고 대상을 설정할 수 있습니다. report-to는 현재 일부 최신 브라우저에서만 지원되므로 둘 다 사용하거나 report-uri만 사용하는 것이 좋습니다.
콘텐츠가 CSP를 위반하면 브라우저는 구성된 대상에 보고서를 전송합니다. 이 대상에 이러한 보고서를 처리하는 애플리케이션이 구성되어 있는지 확인합니다.
HTTP 헤더에서 CSP 정의
CSP는 다음과 같이 메타 태그에서 정의할 수 있습니다.
<meta http-equiv="Content-Security-Policy" content="script-src 'none'">
하지만 가능하면 HTTP 응답 헤더에서 CSP를 정의해야 합니다. 메타 태그 앞에 삽입하면 CSP가 우회됩니다. 또한 메타 태그 CSP에서는 frame-ancestors, sandbox, 보고가 지원되지 않습니다.
CSP가 하위 호환되는지 확인
일부 브라우저는 CSP nonce/hash를 지원하지 않으므로 규정을 준수하지 않는 브라우저의 대체로 unsafe-inline를 추가하는 것이 좋습니다. 브라우저가 nonce/hash를 지원하는 경우 unsafe-inline는 무시됩니다.
마찬가지로 strict-dynamic도 일부 브라우저에서 지원되지 않습니다. 규정을 준수하지 않는 브라우저의 대체로 허용 목록을 설정하는 것이 좋습니다. 허용 목록은 strict-dynamic를 지원하는 브라우저에서 무시됩니다.
엄격한 CSP를 개발하는 방법
다음은 nonce 기반 정책으로 엄격한 CSP를 사용하는 예입니다.
CSP:
script-src 'nonce-random123' 'strict-dynamic' 'unsafe-inline' https:;
object-src 'none';
base-uri 'none';
report-uri https://reporting.example.com;
HTML:
<script nonce="random123" src="https://trusted.example.com/trusted_script.js"></script>
random123는 페이지가 로드될 때마다 서버 측에서 생성되는 base64 문자열입니다. unsafe-inline 및 https:는 nonce 및 strict-dynamic로 인해 최신 브라우저에서 무시됩니다. 엄격한 CSP 채택에 관한 자세한 내용은 엄격한 CSP 가이드를 참고하세요.
Lighthouse 및 CSP 평가자를 사용하여 CSP에서 잠재적인 우회가 있는지 확인할 수 있습니다. 기존 페이지가 손상될 위험 없이 새 CSP를 테스트하려면 Content-Security-Policy-Report-Only를 헤더 이름으로 사용하여 보고서 전용 모드에서 CSP를 정의합니다. 이렇게 하면 report-to 및 report-uri로 구성한 모든 보고 대상에 CSP 위반이 전송되지만 실제로 CSP가 적용되지는 않습니다.