콘텐츠 보안 정책

콘텐츠 보안 정책(CSP)는 리소스를 로드할 수 있는 원본, 실행할 수 있는 인라인 스크립트, 위반 보고서를 보내야 하는 위치를 브라우저에 알려주는 HTTP 응답 헤더(및 이에 상응하는 메타 태그)입니다. 잘 구성된 CSP는 주입 취약점의 영향을 크게 줄입니다. 제대로 구성된 구성은 실제 보호가 거의 없는 잘못된 신뢰를 제공합니다.

CSP가 제어하는 것

정책은 지시문으로 구성되며 각 지시문은 리소스 유형에 대해 허용되는 소스를 지정합니다.

• script-src — 로드 및 실행이 허용되는 JavaScript 소스
• style-src — CSS 소스
• img-src — 이미지 소스
• connect-src — XHR, 가져오기, WebSocket 대상
• font-src — 글꼴 source
• media-src — 오디오 및 비디오 소스
• frame-src — iframes에 로드할 수 있는 항목
• frame-ancestors — 이 페이지를 프레임할 수 있는 항목(대체 X-Frame-Options)
• form-action — 양식을 제출할 수 있는 곳
• base-uri — base로 설정할 수 있는 URL
• upgrade-insecure-requests — HTTP를 다음으로 자동 업그레이드 HTTPS
• default-src — 지정되지 않은 지시문에 대한 대체

A 합리적인 시작 정책

Content-Security-Policy:
  기본-src '자기';
  script-src 'self' 'nonce-randomBase64Value';
  스타일-src 'self' '안전하지 않은 인라인';
  img-src '자체' 데이터: https:;
  connect-src 'self' https://api.example.com;
  프레임 조상 '없음';
  베이스-우리 '자신';
  형태-행동 '자기';
  report-uri https://example.com/csp-reports

이 정책은 다음과 같이 말합니다. 기본적으로 동일한 출처에서만 로드하고, 스크립트는 출처가 동일하거나 일치하는 nonce를 전달해야 하며, 다른 사이트의 iframe에 포함해서는 안 됩니다. nonce 기반 접근 방식은 대부분의 인라인 스크립트 XSS를 방지하는 동시에 서버가 올바른 인라인 스크립트를 내보내는 것을 허용합니다. nonce.

Nonces vs hashes vs whitelists

특정 인라인 스크립트를 허용하는 세 가지 방법:

• Nonce-based. 서버는 요청마다 새로운 무작위 nonce를 생성하고 허용된 각 인라인 스크립트의 CSP plus에 포함합니다. 엄격하고 동적이며 새로운 배포에 권장됩니다.
• Hash 기반. CSP는 허용되는 인라인 스크립트의 SHA 해시를 지정합니다. 브라우저는 인라인 스크립트를 해시하고 비교합니다. 내용이 변경되지 않는 정적 스크립트에 대해 작동합니다.
• 원본의 화이트리스트. 특정 외부 도메인의 스크립트를 허용합니다. 쉽지만 큰 공격 표면을 생성합니다. 화이트리스트에 있는 도메인이 손상되거나 공개 리디렉션이 있는 경우 정책이 우회됩니다.

strict-dynamic 키워드(CSP 3에 추가됨)는 스크립트를 더욱 제한합니다. nonce가 허용되지 않는 스크립트만 자체적으로 다른 스크립트를 로드하여 일반적인 XSS 체인을 깨뜨릴 수 있습니다.

Cargo-cult anti-pattern

많은 사이트는 기존 코드 손상을 방지하기 위해 script-src에 unsafe-inline 및 unsafe-eval가 포함된 CSP를 배포합니다. 이것은 본질적으로 전혀 CSP가 아닙니다. 전체 요점은 인라인 스크립트가 실행되는 것을 방지하는 것이며 unsafe-inline은 해당 보호를 제거합니다. 이 구성을 사용하는 사이트에는 CSP 이점이 없는 CSP 헤더가 있습니다.

실제 CSP 값에 대한 경로: 안전하지 않은 인라인을 제거하고 nonce 또는 해시를 사용하도록 코드를 리팩터링하고 위반 사항을 하나씩 처리합니다. 고통스럽지만 실제적입니다.

보고 전용 모드

CSP는 보고 전용 모드로 배포할 수 있습니다. 브라우저는 구성된 URI에 위반 사항을 보고하지만 이를 시행하지는 않습니다. 사이트를 손상시키지 않고 실제 트래픽에 대해 새 정책을 테스트하는 데 유용합니다.

Content-Security-Policy-Report-Only: ...

표준 출시: 보고 전용 모드로 배포하고 몇 주 동안 위반 사항을 수집하고 합법적인 위반 사항을 수정하고 시행 모드로 전환합니다. 많은 대규모 사이트에서는 이 반복 주기를 통해 여러 달에 걸쳐 CSP를 배포합니다.

CSP 및 XSS

제목 이점: XSS 주입이 성공하더라도 유효한 nonce가 없으면 주입된 스크립트를 실행할 수 없습니다. 공격자의 페이로드가 페이지에 도착합니다. 브라우저가 실행을 거부합니다. 취약점은 여전히 ​​존재하지만 영향은 크게 감소합니다.

이것은 XSS 수정을 대체할 수 없으며 심층적인 방어입니다. 두 레이어가 모두 있어야 합니다.

CSP 브라우저는 2016년 이후부터

모든 주요 브라우저를 지원합니다. CSP 3 기능(nonce, strict-dynamic, hash)은 폭넓게 지원됩니다. 남은 격차는 X-Frame-Options와의 프레임 조상 상호 작용, 보고 대상과 보고 대상의 다양한 동작, 오류 보고의 브라우저별 문제 등 극단적인 경우를 처리하는 데 있습니다.

운영 복잡성

실제 CSP 배포는 보기보다 어렵습니다.

• 타사 스크립트(분석, 광고, 모니터링)가 정책에 있어야 하거나 정책에 포함되어야 합니다. pass
• 인라인 이벤트 처리기(onclick="...")는 명시적으로 허용되지 않는 한 CSP를 위반합니다.
• 동적 콘텐츠가 있는 단일 페이지 앱은 신중한 nonce 처리가 필요합니다.
• 브라우저 확장 프로그램은 때때로 CSP를 위반하는 콘텐츠를 삽입하여 소음을 생성할 수 있습니다.
• 다른 팀에는 다른 CSP 조각이 필요할 수 있습니다. 정책 병합은 사소한 일이 아닙니다

CSP가 있어야 하는 많은 사이트에는 CSP가 없습니다. 운영 비용이 인지된 보안 이점보다 높게 느껴지기 때문입니다. 비용은 실제입니다. 이점도 실제적이지만 눈에 보이지 않습니다(발생하지 않은 공격은 볼 수 없음).