웹의 보안 모델은
동일 출처 정책 코드
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
및 현재 페이지의 출처에서 전송
![콘솔 오류: 'http://evil.example.com/evil.js' 스크립트 로드를 거부함 'script-src 'self'라는 콘텐츠 보안 정책 지침을 위반하기 때문입니다. https://apis.google.com](https://developer.chrome.google.cn/static/docs/privacy-security/csp/image/console-error-refused-l-524026adbb83a.png?authuser=0000&hl=ko)
이 정책을 정의하면 브라우저에서 스크립트를 로드할 수 있습니다. 영리한 공격자가 코드를 사이트에 삽입하면 되풀이되지 않고 계속 오류 메시지가 표시됩니다. 기대했던 것보다 더 큰 성과를 거두었습니다.
다양한 리소스에 적용되는 정책
스크립트 리소스는 가장 명백한 보안 위험이지만, 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
)을 포함해야 합니다.
보고서 전용
CSP를 이제 막 사용하기 시작했다면 현재
애플리케이션의 상태를 점검할 수 있습니다.
완전한 배포를 위한 디딤돌로, 브라우저에 현재과 같이
정책을 시행하고 위반을 신고하지만 제한을 시행하지는 않습니다. 대신
Content-Security-Policy
헤더를 전송하면
Content-Security-Policy-Report-Only
헤더.
Content-Security-Policy-Report-Only: default-src 'self'; ...; report-uri /my_amazing_csp_report_parser;
보고서 전용 모드에서 지정된 정책은 제한된 리소스를 차단하지 않지만 지정한 위치로 위반 보고서가 전송됩니다. 심지어 두 헤더를 모두 적용하여 한 정책을 적용하는 동시에 다른 정책을 모니터링합니다. 이것은 변경 시 애플리케이션의 CSP에 미치는 영향을 평가하는 방법: 위반 보고서를 모니터링하고, 정책 위반 가능성이 있는 모든 버그를 볼륨 높여 줘. 새 정책의 효력이 만족스러우면 새 정책을 시행하세요.
실제 사용
CSP 1은 Chrome, Safari, Firefox에서 사용할 수 있지만 매우 제한적입니다. Internet Explorer 10에서 지원됩니다. 다음과 같은 작업을 할 수 있습니다. caniuse.com에서 세부사항을 확인하세요. CSP 수준 2는 버전 40 Twitter, Facebook과 같은 대규모 사이트에서 이 헤더를 배포했습니다. (Twitter의 우수사례를 읽어볼 만한 가치가 있음) 표준이 매우 준비되어 있습니다. 자체 사이트에 배포를 시작할 수 있습니다.
애플리케이션에 적용할 정책을 수립하는 첫 번째 단계는 리소스를 많이 만들 수 있습니다 광고 수익을 늘리는 방법에 대해 잘 알고 있다고 생각되면 앱에 통합한 경우 이를 기반으로 정책을 요구사항을 충족해야 합니다 몇 가지 일반적인 사용 사례를 살펴보고 CSP의 보호 범위 내에서 이들을 가장 잘 지원할 수 있어야 합니다.
사용 사례 #1: 소셜 미디어 위젯
Google의 +1 버튼 의 스크립트가
https://apis.google.com
포함되고,<iframe>
https://plusone.google.com
입니다. 이 두 가지를 모두 포함하는 정책이 필요합니다. 원본이 있어야 합니다. 최소 정책은script-src https://apis.google.com; child-src https://plusone.google.com
입니다. 또한 이렇게 하면 Google이 제공하는 자바스크립트 코드를 외부 자바스크립트 파일로 이동해야 합니다.frame-src
을(를) 사용하는 수준 1 기반 정책이 있는 경우 레벨 2에서는 이를child-src
(으)로 변경해야 합니다. 더 이상 필요하지 않음 CSP 레벨 3에 있습니다.Facebook의 좋아요 버튼 다양한 구현 옵션이 있습니다. 따라서
<iframe>
버전이 사이트의 나머지 부분에서 안전하게 샌드박스 처리됩니다. 그것은 올바르게 작동하려면child-src https://facebook.com
지시어가 필요합니다. 참고 기본적으로 Facebook이 제공하는<iframe>
코드는 URL,//facebook.com
명시적으로 HTTPS를 지정하도록 변경합니다.https://facebook.com
꼭 필요하지 않다면 HTTP를 사용할 이유가 없습니다.Twitter의 트윗 버튼 는
https://platform.twitter.com
입니다. (트위터도 마찬가지로 default; 로컬로 복사/붙여넣기할 때는 HTTPS를 지정하도록 코드를 수정합니다.) JavaScript 스니펫을 이동하기만 하면script-src https://platform.twitter.com; child-src https://platform.twitter.com
가 모두 설정된 것입니다. 트위터에서 제공하는 외부 자바스크립트 파일로 직접 전송할 수 있습니다다른 플랫폼에도 비슷한 요구사항이 있으며 이와 유사하게 해결할 수 있습니다.
default-src
을'none'
로 설정하고 콘솔을 확인하여 다음 작업을 하는 것이 좋습니다. 위젯이 작동하도록 하기 위해 필요한 리소스를 결정합니다.
여러 위젯을 포함하는 것은 간단합니다. 정책을 결합하기만 하면 됩니다. 지시문을 사용하여 단일 유형의 모든 리소스를 단일 지시어를 사용합니다. 세 가지 소셜 미디어 위젯을 모두 원할 경우 정책은 다음과 같습니다. :
script-src https://apis.google.com https://platform.twitter.com; child-src https://plusone.google.com https://facebook.com https://platform.twitter.com
사용 사례 #2: 잠금
은행 사이트를 운영하고 있다고 가정해 보겠습니다.
직접 작성한 리소스만 로드할 수 있습니다. 이 시나리오에서는
모든 것을 완전히 차단하는 기본 정책 (default-src 'none'
)으로 시작하여 거기서부터 만들어집니다.
은행이 다음 위치에서 CDN으로부터 모든 이미지, 스타일 및 스크립트를 로드한다고 가정해 보겠습니다.
https://cdn.mybank.net
, XHR을 통해 https://api.mybank.com/
에 연결하여
다양한 비트의 데이터를 끌어내립니다. 프레임이 사용되지만
사이트 (서드 파티 출처 없음) 이 사이트에는 플래시도 없고, 글꼴도,
보너스 콘텐츠입니다. 보낼 수 있는 가장 제한적인 CSP 헤더는 다음과 같습니다.
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'
사용 사례 #3: SSL 전용
결혼반지 토론 포럼 관리자가 모든 리소스를 보안 채널을 통해서만 로드되지만 실제로 많은 코드를 작성하지는 않습니다. 재작성 서드 파티 포럼 소프트웨어의 대규모 덩어리를 그의 능력을 능가합니다. 다음 정책은 효과적:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'
https:
는 default-src
에 지정되어 있지만 스크립트와 스타일은
지시어는 해당 소스를 자동으로 상속하지 않습니다. 각 지시어는
해당 특정 리소스 유형의 기본값을 덮어씁니다.
앞으로
콘텐츠 보안 정책 수준 2는 입니다. Candidate Recommendation(후보 추천) W3C의 웹 애플리케이션 보안 실무 그룹 이미 사양의 다음 반복 작업을 시작했으므로 콘텐츠 보안 정책 레벨 3.
출시 예정인 기능에 관한 토론에 관심이 있으시면 public-webappsec@ 메일링 리스트 자료실 훑어보기 직접 해 보세요.