콘텐츠 보안 정책 : 콘텐츠 보안 정책(CSP)

Mike West

Joe Medley

웹의 보안 모델은 동일 출처 정책 코드 https://mybank.com의 액세스 권한은 https://mybank.com의 절대로 https://evil.example.com에 액세스를 허용해서는 안 됩니다. 각 출처는 나머지 웹과 격리되므로 개발자가 만들고 실행하는 데 사용할 수 있는 샌드박스입니다. 이론상으로는 아주 훌륭합니다. 포함 공격자가 시스템을 파괴할 영리한 방법을 찾았습니다.

교차 사이트 스크립팅 (XSS) 예를 들어, 사이트를 속여 동일한 출처 정책을 우회하도록 의도한 컨텐츠와 함께 악성코드를 유포하는 데 사용됩니다. 이것은 브라우저는 페이지에 표시되는 모든 코드를 해당 페이지의 보안 출처의 적법한 부분을 차지할 수 있음을 의미합니다. 이 XSS 요약본 오래되었지만 공격자가 사용하는 방법 중 대표적인 악성 코드를 주입하여 이 신뢰를 위반하는 것을 보게 됩니다. 공격자가 성공적으로 어떤 코드든 전혀 삽입하지 않으므로 게임이 거의 끝났습니다. 사용자 세션 데이터는 기밀로 유지해야 하는 정보는 공격자에게 게이들. 가능하면 이를 방지하고 싶습니다.

이 개요는 위험을 크게 줄이고 최신 브라우저에서 XSS 공격이 미치는 영향: 콘텐츠 보안 정책 (CSP)

요약

• 허용 목록을 사용하여 클라이언트에게 허용되는 항목과 허용되지 않는 항목을 알립니다.
• 사용 가능한 지시어를 알아보세요.
• 이들이 사용하는 키워드를 알아보세요.
• 인라인 코드와 eval()는 유해한 것으로 간주됩니다.
• 정책 위반을 시행하기 전에 서버에 신고하세요.

소스 허용 목록

XSS 공격에 악용될 문제는 브라우저가 애플리케이션의 일부인 스크립트와 서드 파티에 의해 악의적으로 주입되는 경우. 예를 들어 코드 로드 및 실행 이 페이지의 출처에서 https://apis.google.com/js/plusone.js입니다. 이 코드를 신뢰하지만 브라우저가 스스로 해당 코드를 알아내고 apis.google.com의 코드는 훌륭하지만 apis.evil.example.com의 코드는 훌륭합니다. 그렇지 않을 수도 있습니다 브라우저가 페이지의 모든 코드를 다운로드하여 실행합니다. 모든 요청을 처리할 수 있습니다

CSP는 서버가 제공하는 모든 것을 맹목적으로 신뢰하는 대신에 다음의 허용 목록을 만들 수 있는 Content-Security-Policy HTTP 헤더입니다. 브라우저에 지시하며, 신뢰할 수 있는 콘텐츠의 소스만 실행하고 리소스를 배포합니다 비록 공격자가 구멍을 찾을 수 있고 스크립트를 삽입하면 스크립트가 허용 목록과 일치하지 않으므로 실행됩니다

Google은 apis.google.com의 유효한 코드 제공을 신뢰하고 있으며 Google도 이를 신뢰합니다. 마찬가지로 스크립트가 실행될 때만 스크립트가 실행되도록 허용하는 정책을 정의해 보겠습니다. 두 소스 중 하나에서 비롯됩니다

Content-Security-Policy: script-src 'self' https://apis.google.com

간단하죠? 짐작하셨겠지만 script-src는 특정 페이지에 대한 스크립트 관련 권한 집합을 제어합니다. 인코더-디코더 아키텍처를 'self'는 유효한 스크립트 소스 1개, https://apis.google.com는 유효한 스크립트 소스 있습니다. 브라우저는 올바른 위치에서 JavaScript를 다운로드하고 실행합니다. HTTPS를 통한 apis.google.com 및 현재 페이지의 출처에서 전송

이 정책을 정의하면 브라우저에서 스크립트를 로드할 수 있습니다. 영리한 공격자가 코드를 사이트에 삽입하면 되풀이되지 않고 계속 오류 메시지가 표시됩니다. 기대했던 것보다 더 큰 성과를 거두었습니다.

다양한 리소스에 적용되는 정책

스크립트 리소스는 가장 명백한 보안 위험이지만, CSP는 다양한 리소스를 상당히 세밀하게 제어할 수 있는 정책 지시문 세트 지정할 수 있습니다. 이미 script-src를 봤으므로 개념은 분명해야 합니다.

나머지 리소스 지시문을 빠르게 살펴보겠습니다. 아래 목록은 수준 2 현재 지시어의 상태를 나타냅니다. 레벨 3 사양이 게시되었지만, 주요 코스에서 대부분 구현되지 않음 있습니다.

• base-uri는 페이지의 <base> 요소에 표시될 수 있는 URL을 제한합니다.
• child-src는 작업자와 삽입된 프레임 콘텐츠의 URL을 나열합니다. 대상 예: child-src https://youtube.com을(를) 사용하면 YouTube이지만 다른 출처는 아님을 알 수 있습니다.
• connect-src는 XHR을 통해 연결할 수 있는 출처를 제한합니다. WebSocket, EventSource)를 추가합니다.
• font-src는 웹 글꼴을 제공할 수 있는 출처를 지정합니다. Google의 웹 글꼴은 font-src https://themes.googleusercontent.com를 통해 사용 설정할 수 있습니다.
• form-action는 <form> 태그에서 제출할 수 있는 유효한 엔드포인트를 나열합니다.
• frame-ancestors는 현재 페이지를 삽입할 수 있는 소스를 지정합니다. 이 지시어는 <frame>, <iframe>, <embed>, <applet> 태그에 적용됩니다. 이 지시어는 <meta> 태그에서 사용할 수 없으며 HTML이 아닌 태그에만 적용됩니다. 리소스를 배포합니다
• frame-src는 레벨 2에서 지원 중단되었지만 레벨 3에서 복원되었습니다. 그렇지 않은 경우 이전과 같이 child-src로 대체됩니다.
• img-src는 이미지를 로드할 수 있는 출처를 정의합니다.
• media-src에서는 동영상 및 오디오를 전송할 수 있는 출처를 제한합니다.
• object-src를 사용하면 Flash 및 기타 플러그인을 제어할 수 있습니다.
• plugin-types는 페이지에서 호출할 수 있는 플러그인의 종류를 제한합니다.
• report-uri는 콘텐츠 보안 정책을 위반한 경우 이 지시어는 <meta>에서 사용할 수 없습니다. 태그 사이에 있어야 합니다.
• style-src는 script-src의 스타일시트에 해당합니다.
• upgrade-insecure-requests는 사용자 에이전트가 URL 스키마를 다시 작성하도록 지시합니다. HTTP를 HTTPS로 변경하는 것입니다. 이 명령어는 다시 작성해야 하는 이전 URL입니다.
• worker-src는 작업자, 공유 워커 또는 서비스 워커로 로드될 수 있습니다 2017년 7월 현재 지시어에는 제한적으로 구현되는 경우

기본적으로 지시어는 광범위하게 열립니다. 광고에 특정 정책을 설정하지 않은 경우 지시문을 font-src이라고 가정하면 이 지시문은 기본적으로 다음과 같이 동작합니다. *를 유효한 소스로 지정했더라도 (예: 제한 없이 어디서나 액세스 가능합니다.

default-src를 지정하여 이 기본 동작을 재정의할 수 있습니다. 지시어를 사용합니다. 이 지시어는 대부분의 지시어를 지정합니다. 일반적으로 이는 -src(으)로 끝납니다. default-src가 https://example.com로 설정되어 있고 실패한 경우 font-src 지시문을 지정하려는 경우 https://example.com 외 다른 곳에는 표시되지 않습니다. 우리는 script-src 즉, 이미지, 글꼴 등을 모든 출처에서 사용할 수 있습니다

다음 지시어는 default-src를 대체로 사용하지 않습니다. 기억할 사항 값을 설정하지 않는 것은 무엇이든 허용하는 것과 같습니다.

• base-uri
• form-action
• frame-ancestors
• plugin-types
• report-uri
• sandbox

이러한 명령어는 HTTP 헤더에 각각의 애플리케이션을 나열하기만 하면 지시어를 사용할 수 있습니다. 모든 단일 지시어에 특정 유형의 필수 리소스를 포함합니다. 만약 script-src https://host1.com; script-src https://host2.com 같은 두 번째 지시어는 무시됩니다. 예를 들면 다음과 같습니다. 두 출처를 모두 유효한 것으로 지정합니다.

script-src https://host1.com https://host2.com

예를 들어, 웹 프록시에서 모든 리소스를 로드하는 애플리케이션이 https://cdn.example.net처럼 콘텐츠 전송 네트워크 (예: https://cdn.example.net)를 사용하고 있고 프레임이 있는 콘텐츠나 플러그인이 필요하지 않으면 정책 위반이 다음과 같습니다.

Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'

구현 세부정보

X-WebKit-CSP 및 X-Content-Security-Policy 헤더가 다양한 위치에 표시됩니다. 웹 튜토리얼을 볼 수 있습니다. 앞으로는 있습니다. 최신 브라우저 (IE 제외)는 프리픽스가 없는 Content-Security-Policy 헤더. 바로 이 헤더를 사용해야 합니다.

사용하는 헤더에 관계없이 정책은 페이지별로 정의됩니다. HTTP 헤더를 전송하려는 모든 응답과 함께 있습니다. 이렇게 하면 세부사항을 조정할 수 있으므로 유연성이 뛰어납니다. 정책을 만들 수도 있습니다. 아마도 한 세트의 사이트의 페이지에는 +1 버튼이 있지만 다른 페이지에는 +1 버튼이 없습니다. 필요한 경우에만 로드되도록 할 수 있습니다.

각 지시어의 소스 목록은 유연합니다. 다음을 기준으로 소스를 지정할 수 있습니다. 스키마 (data:, https:) 또는 호스트 이름만의 특정 범위 지정 (example.com: 해당 호스트의 모든 출처: 모든 스키마, 모든 포트와 일치) 정규화된 URI (https://example.com:443는 HTTPS만 일치하고 example.com 및 포트 443만 지원). 와일드 카드는 허용되지만 체계로만 가능합니다. 포트 또는 호스트 이름의 가장 왼쪽 위치: *://*.example.com:*는 다음을 사용하여 example.com의 모든 하위 도메인 (example.com 자체는 아님)과 일치 모든 스키마, 모든 포트에서

소스 목록에는 다음과 같은 4개의 키워드도 허용됩니다.

• 'none'는 예상대로 일치하지 않습니다.
• 'self'는 현재 출처와 일치하지만 하위 도메인은 일치하지 않습니다.
• 'unsafe-inline'는 인라인 JavaScript 및 CSS를 허용합니다. 이 내용은 조금 더 자세히 살펴보겠습니다.
• 'unsafe-eval'는 eval와 같은 텍스트-JavaScript 메커니즘을 허용합니다. 이 과정에서 여기에도 해당됩니다.)

이러한 키워드에는 작은따옴표가 필요합니다. 예: script-src 'self' (따옴표 포함) 현재 호스트에서 JavaScript 실행을 승인합니다. script-src self (따옴표 없음)는 'self' 서버의 JavaScript를 허용합니다. ( 현재 호스트)이 아닐 수 있습니다.

샌드박스 기능

살펴볼 만한 명령어가 하나 더 있습니다. sandbox 약간 다른 것과는 차이가 있지만, 페이지가 로드할 수 있는 리소스보다 더 많이 가질 수 있습니다. 만약 sandbox 지시어가 있는 경우 페이지가 로드된 것처럼 처리됩니다. sandbox 속성이 있는 <iframe> 내부에 이것은 페이지에 영향: 페이지를 고유한 출처로 강제 설정 및 양식 방지 제출할 수 있습니다. 이 글에서 다루지는 않지만 유효한 샌드박싱 속성에 대한 자세한 내용은 '샌드박스' 섹션을 참조하세요.

메타 태그

CSP에서 선호하는 전송 메커니즘은 HTTP 헤더입니다. 유용할 수 있지만 을 사용하여 마크업에서 페이지에 직접 정책을 설정할 수 있습니다. 다음과 같이 <meta> 태그를 사용하여 실행합니다. http-equiv 속성:

<meta
  http-equiv="Content-Security-Policy"
  content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'"
/>

frame-ancestors, report-uri 또는 sandbox에 사용할 수 없습니다.

유해한 인라인 코드로 간주됨

CSP는 허용 목록 출처를 기반으로 한다는 점을 명확히 해야 합니다. 특정 리소스 집합을 처리하도록 브라우저에 지시하는 명확한 방법 나머지는 거부할 수 있습니다 출처 기반 허용 목록은 그렇지 않습니다. XSS 공격으로 인한 가장 큰 위협인 인라인 스크립트 삽입을 해결할 수 있습니다. 공격자가 일부 악성 코드가 포함된 스크립트 태그를 직접 페이로드 (<script>sendMyDataToEvilDotCom();</script>), 브라우저에는 합법적인 브라우저와 인라인 스크립트 태그에 삽입할 수도 있습니다. CSP는 인라인 스크립트를 완전히 금지하여 이 문제를 해결합니다. 그것이 확신할 수 있는 유일한 방법입니다.

이러한 금지에는 script 태그에 직접 삽입된 스크립트뿐만 아니라 인라인 이벤트 핸들러와 javascript: URL을 사용합니다. 다른 노트북의 콘텐츠를 script 태그를 외부 파일에 추가하고 javascript: URL과 <a ... onclick="[JAVASCRIPT]">를 적절한 addEventListener() 호출로 바꿉니다. 예를 들어 다음과 같은 코드를 다시 작성할 수 있습니다.

<script>
  function doAmazingThings() {
    alert('YOU AM AMAZING!');
  }
</script>
<button onclick="doAmazingThings();">Am I amazing?</button>

다음과 같이 변경할 수 있습니다.

<!-- amazing.html -->
<script src="amazing.js"></script>
<button id="amazing">Am I amazing?</button>

<div style="clear:both;"></div>

// amazing.js
function doAmazingThings() {
  alert('YOU AM AMAZING!');
}
document.addEventListener('DOMContentLoaded', function () {
  document.getElementById('amazing').addEventListener('click', doAmazingThings);
});

다시 작성된 코드는 CSP; CSP 사용과 관계없이 이미 권장사항입니다. 인라인 JavaScript는 잘못된 방식으로 구조와 동작을 혼합합니다. 외부 리소스는 브라우저에서 캐시하기가 더 용이하고, 컴파일 및 축소에 도움이 됩니다. 더 잘 쓸 수 있습니다 이 문제를 해결할 수 있습니다.

인라인 스타일은 style 속성과 style 모두 동일한 방식으로 처리됩니다. 태그는 외부 스타일시트로 통합되어야 다양한 놀랍도록 영리한 데이터 무단 반출 방법을 사용합니다.

인라인 스크립트와 스타일이 있어야 하는 경우, 이를 사용 설정할 수 있습니다. script-src 또는 style-src에서 허용되는 소스로 'unsafe-inline' 추가 지시어를 사용합니다. nonce나 hash (아래 참조)를 사용할 수도 있지만 실제로는 사용하면 안 됩니다. 인라인 스크립트 금지는 CSP가 제공하는 가장 큰 보안 이점입니다. 인라인 스타일을 금지하면 애플리케이션이 강화됩니다. 이것은 모든 코드를 이동한 후 올바르게 작동하도록 미리 노력 타협할 수 있지만 그만한 가치가 있는 절충점입니다.

꼭 이 방법을 사용해야 한다면

CSP 레벨 2는 다음을 통해 인라인 스크립트의 이전 버전과의 호환성을 제공합니다. 암호 nonce( 해시)를 사용할 수 있습니다. 번거로울 수 있지만 한 번에 안내해 드리겠습니다.

nonce를 사용하려면 스크립트 태그에 nonce 속성을 지정하세요. 해당 값은 1과 일치해야 합니다. 표시됩니다. 예를 들면 다음과 같습니다.

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">
  // Some inline code I can't remove yet, but need to asap.
</script>

이제 nonce- 키워드에 추가된 script-src 지시어에 nonce를 추가합니다.

Content-Security-Policy: script-src 'nonce-EDNnf03nceIOfn39fn3e9h3sdfa'

nonce는 모든 페이지 요청에 대해 재생성되어야 하며 있습니다.

해시도 거의 같은 방식으로 작동합니다. 스크립트 태그에 코드를 추가하는 대신 스크립트 자체의 SHA 해시를 만들어 script-src 지시어에 추가합니다. 예를 들어 페이지에 다음과 같은 항목이 포함되어 있다고 가정해 보겠습니다.

<script>
  alert('Hello, world.');
</script>

정책에는 다음이 포함됩니다.

Content-Security-Policy: script-src 'sha256-qznLcsROx4GACP2dm0UCKCzCG-HiZ1guq6ZZDob_Tng='

여기서 몇 가지 유의해야 할 사항이 있습니다. sha*- 프리픽스는 알고리즘을 지정합니다. 이 해시를 생성합니다. 위의 예에서는 sha256-가 사용됩니다. CSP 또한 sha384- 및 sha512-를 지원합니다. 해시를 생성할 때 <script> 태그. 또한 대문자와 공백(선행 또는 공백 포함)도 중요합니다. 후행 공백

SHA 해시 생성에 대해 Google에서 검색하면 있습니다. Chrome 40 이상을 사용하는 경우 DevTools를 연 다음 페이지를 새로고침합니다. '콘솔' 탭에는 sha256 해시를 사용하도록 설정합니다.

평가도

공격자가 스크립트를 직접 주입하지 못하더라도 비활성 텍스트를 실행 가능한 JavaScript로 변환하도록 맡길 수 있습니다 eval(), 새 메시지 Function() , setTimeout([string], ...) 및 setInterval([string], ...)는 모두 텍스트가 예기치 않게 악의적인 무언가를 실행하게 될 수 있습니다. CSP의 기본값 대응책은 이러한 모든 벡터를 완전히 차단하는 것입니다.

이는 애플리케이션을 빌드하는 방식에 몇 가지 영향을 미칩니다.

• 기본 제공 JSON.parse을 통해 JSON을 파싱해야 하며, eval입니다. 기본 JSON 작업은 다음에서 사용할 수 있습니다. 브라우저에서 완전히 안전하게 보호할 수 있습니다.
• 현재 수행 중인 setTimeout 또는 setInterval 호출을 다시 작성합니다. 인라인 함수를 사용해야 합니다. 예를 들면 다음과 같습니다.

setTimeout("document.querySelector('a').style.display = 'none';", 10);

다음과 같이 작성하는 것이 더 낫습니다.

setTimeout(function () {
  document.querySelector('a').style.display = 'none';
}, 10);

• 런타임 시 인라인 템플릿 방지: 많은 템플릿 라이브러리가 new Function()를 자유롭게 사용하여 런타임 시 템플릿 생성 속도를 높입니다. 이것은 동적 프로그래밍을 재밌게 응용할 수 있지만 검사하지 않습니다. 일부 프레임워크는 CSP를 즉시 지원합니다. eval가 없으면 강력한 파서로 돌아갑니다. AngularJS의 ng-csp 지시어 좋은 예입니다.

그러나 더 나은 선택은 (Handlebars는 실행하는 작업, 있습니다. 템플릿을 사전 컴파일하면 가장 빠른 런타임 구현보다 빠르며 더 안전합니다. If eval and 애플리케이션에 필수적이기 때문에 script-src에 허용된 소스로 'unsafe-eval'를 추가하여 사용 설정하세요. 권장하지 않습니다. 실행 능력 차단 문자열이기 때문에 공격자가 허가받지 않고 실행하기가 훨씬 더 어려워집니다. 코드를 삽입해야 합니다.

보고

신뢰할 수 없는 리소스를 클라이언트 측에서 차단하는 CSP의 기능은 알림을 받을 수 있도록 하는 것이 유용할 수 있습니다. 서버에게 다시 반환되기 때문에 악성 주입을 사전에 예방할 수 있습니다. 이를 위해 브라우저에서 위치에 대한 JSON 형식 위반 신고를 POST합니다. report-uri 지시어에 지정됩니다.

Content-Security-Policy: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

보고서는 다음과 유사합니다.

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/",
    "blocked-uri": "http://evil.example.com/evil.js",
    "violated-directive": "script-src 'self' https://apis.google.com",
    "original-policy": "script-src 'self' https://apis.google.com; report-uri http://example.org/my_amazing_csp_report_parser"
  }
}

여기에는 문제를 추적하는 데 도움이 되는 유용한 정보가 포함되어 있습니다. 위반의 구체적인 원인(예: 위반이 발생한 페이지) 발생한 경우 (document-uri), 해당 페이지의 리퍼러입니다 (HTTP 헤더 필드는, 키의 철자가 틀린 것이 아니며 페이지의 정책 (blocked-uri), 위반한 특정 명령 (violated-directive), 페이지의 전체 정책 (original-policy)을 포함해야 합니다.

Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;

script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com

Content-Security-Policy: default-src 'none'; script-src https://cdn.mybank.net; style-src https://cdn.mybank.net; img-src https://cdn.mybank.net; connect-src https://api.mybank.com; child-src 'self'

Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'