콘텐츠 보안 정책 (CSP)을 사용하면 페이지에 로드된 모든 콘텐츠를 사이트 소유자가 신뢰하도록 할 수 있습니다. CSP는 교차 사이트 스크립팅 (XSS) 공격을 완화합니다. 공격자가 삽입한 안전하지 않은 스크립트를 차단할 수 있기 때문입니다. 그러나 CSP가 충분히 엄격하지 않으면 쉽게 우회될 수 있습니다. 자세한 내용은 엄격한 콘텐츠 보안 정책 (CSP)으로 교차 사이트 스크립팅 (XSS) 완화를 참고하세요. Lighthouse는 기본 문서에 적용된 CSP를 수집하고 문제를 우회할 수 있는 경우 CSP Evaluator에 문제를 보고합니다.
<ph type="x-smartling-placeholder">
우회할 수 없는 CSP의 필수 권장사항
CSP를 우회할 수 없도록 다음 권장사항을 구현하세요. CSP를 우회할 수 있는 경우 Lighthouse에서 높은 심각도 경고를 표시합니다.
CSP가 XSS를 타겟팅함
XSS를 타겟팅하려면 CSP에 script-src, object-src, base-uri 지시어가 포함되어야 합니다. 또한 CSP에 구문 오류가 없어야 합니다.
script-src 및 object-src는 각각 안전하지 않은 스크립트와 안전하지 않은 플러그인에서 페이지를 보호합니다. 또는 script-src 및 object-src를 포함한 여러 지시어 대신 default-src을 사용하여 광범위한 정책을 구성할 수 있습니다.
base-uri는 모든 상대 URL (예: 스크립트)을 공격자가 제어하는 도메인으로 리디렉션하는 데 사용될 수 있는 승인되지 않은 <base> 태그가 삽입되는 것을 방지합니다.
CSP가 nonce 또는 해시를 사용하여 허용 목록 우회를 방지함
script-src의 허용 목록을 구성하는 CSP는 신뢰할 수 있는 도메인에서 오는 모든 응답이 안전하며 스크립트로 실행될 수 있다는 가정을 사용합니다. 그러나 최신 애플리케이션에는 이 가정이 적용되지 않습니다. JSONP 인터페이스 노출 및 AngularJS 라이브러리의 사본 호스팅과 같은 몇 가지 일반적이고 무해한 패턴을 통해 공격자는 CSP의 한계를 벗어날 수 있습니다.
실제로는 애플리케이션 작성자에게 명확하지 않을 수 있지만 XSS 버그가 있는 공격자가 대부분의 script-src 허용 목록을 우회할 수 있으며 스크립트 삽입에 대한 보호 기능이 거의 제공되지 않습니다. 반면, 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 또는 hash를 사용하여 스크립트를 개별적으로 허용하고 '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를 우회합니다. 또한 frame-ancestors, sandbox 및 보고는 메타 태그 CSP에서 지원되지 않습니다.
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 Evaluator를 사용하여 CSP의 우회 가능성을 확인할 수 있습니다. 기존 페이지가 손상될 위험 없이 새 CSP를 테스트하려면 Content-Security-Policy-Report-Only를 헤더 이름으로 사용하여 보고서 전용 모드에서 CSP를 정의합니다. 이렇게 하면 report-to 및 report-uri로 구성한 모든 보고 대상에 CSP 위반이 전송되지만 실제로 CSP가 시행되지는 않습니다.