댓글 : 서문 : HTML5가 나타난 후 네트워크 보안이 더 널리 알려졌습니다. 웹은 네트워크 보안에 어떤 개선 사항을 만들었습니까? 우리는 점점 더 위험한 사이버 사기와 공격에 직면합니까? 다음 기사는이 문제에 대한 W3C의 최신 솔루션에 대해 이야기합니다. 앞으로 기회가 있다면 XSS, P3P, 상 동성 정책, CORS (크로스 도메인 리소스 공유) 및 CSP에서 HTML5 컨텐츠를 수행 할 것입니다.
월드 와이드 웹의 보안 정책은 상동 정책에 뿌리를두고 있습니다. 예를 들어, 코드는 데이터에만 액세스 할 수 있지만 액세스 권한이 없습니다. 각 소스는 나머지 네트워크와 분리되어 개발자를위한 안전한 샌드 박스를 만듭니다. 이것은 이론적으로는 완벽하지만 이제 공격자들은 시스템을 파괴하는 영리한 방법을 찾았습니다.이것은 가짜 콘텐츠와 트릭 클릭을 통해 상 동성 정책을 우회하는 XSS 간 스크립팅 공격입니다. 공격자가 코드를 성공적으로 주입하면 상당한 양의 사용자 데이터가 유출됩니다.
이제 우리는 CSP (Contentsecurity Policy) 인이 위험을 완화하기위한 새롭고 효과적인 보안 방어 전략을 도입합니다.
소스 화이트리스트
XSS 공격의 핵심은 브라우저가 스크립트가 제 3자가 주입했는지 또는 실제로 응용 프로그램의 일부라는 것을 알 수 없다는 것입니다. 예를 들어, Google +1 버튼은 https://apis.google.com/js/plusone.js에서 코드를로드하고 실행하지만 코드가 실제로 APIS.google.com 또는 Apis.evil.example.com의 코드인지 브라우저의 그림에서 알 수 없습니다. 브라우저는 소스에 관계없이 모든 코드에 대한 페이지 요청을 다운로드하고 실행합니다.
CSP는 Content-Security-PolicyHTTP 헤더를 정의하여 신뢰할 수있는 소스의 화이트리스트를 생성 할 수 있도록하여 브라우저는 서버가 제공 한 모든 것을 맹목적으로 신뢰하지 않고 해당 소스에서 리소스 만 실행하고 렌더링합니다. 공격자가 스크립트를 주입 할 취약성을 찾을 수 있더라도 소스가 화이트리스트에 포함되지 않기 때문에 실행되지 않습니다.
위의 Google +1 버튼은 APIS.google.com이 유효한 코드를 제공 할뿐만 아니라 스스로를 제공한다고 생각하기 때문에 아래 두 소스 중 하나에서 브라우저가 스크립트를 실행할 수있는 정책을 정의 할 수 있기 때문입니다.
Content-Security-Policy : Script-Src 'self'https://apis.google.com
매우 간단하지 않습니까? Script-SRC는 지정된 페이지의 스크립트 관련 권한을 제어 할 수 있습니다. 이런 식으로 브라우저는이 페이지 자체에서 스크립트를 다운로드하여 실행합니다.
이 정책을 정의하면 브라우저는 주입 된 코드를 감지 할 때 오류가 발생합니다 (어떤 브라우저인지 참고).
컨텐츠 보안 정책은 모든 일반적인 자원에 적용됩니다
스크립트 리소스는 가장 분명한 보안 위험이지만 CSP는 또한 페이지가 다음 유형과 같은 다양한 유형의 리소스로드를 제어 할 수있는 풍부한 지침 세트를 제공합니다.
Content-SRC : 연결 유형을 제한합니다 (예 : XHR, WebSockets 및 EventsOURCE)
FONT-SRC : 네트워크 글꼴 소스를 제어합니다. 예를 들어, font-src https://themes.googleusercontent.com을 통해 Google 웹 글꼴을 사용할 수 있습니다.
Frame-SRC : 내장 할 수있는 프레임 소스를 나열합니다. 예를 들어 Frame-SRC https://youtube.com에서는 YouTube에 포함 된 비디오 만 허용합니다. .
IMG-SRC :로드 가능한 이미지의 소스를 정의합니다.
Media-SRC : 비디오 및 오디오 소스를 제한합니다.
Object-SRC : 플래시 및 기타 플러그인의 소스를 제한합니다.
Style-SRC : Script-SRC와 유사하게 CSS 파일에서만 작동합니다.
기본적으로 모든 설정은 제한없이 켜져 있습니다. 세미콜론으로 여러 지시 사항을 분리 할 수 있지만 Script-SRC https : //host1.com; Script-Src https://host2.com과 유사하게 두 번째 지침은 무시됩니다. 글을 쓰는 올바른 방법은 script-src https://host1.com https://host2.com입니다.
예를 들어, 컨텐츠 배포 네트워크 (예 : https://cdn.example.net과 같은 CDN)에서 모든 리소스를로드 해야하는 응용 프로그램이 있으며 프레임과 플러그인의 내용이 필요하다는 것을 알고 있으므로 전략이 다음과 같이 보일 수 있습니다.
Content-Security-Policy : Default-Src https://cdn.example.net; Frame-Src 'None'; Object-Src 'None'
세부 사항
예제에서 사용한 HTTP 헤더는 Content-Security-Policy이지만 현대식 브라우저는 이미 접두사를 통해 지원을 제공했습니다. Firefox는 X-Content-Security-Policy를 사용합니다. WebKit은 X-WebKit-CSP를 사용합니다. 앞으로는 점차 통합 표준으로 전환 할 것입니다.
다른 페이지에 대해 전략을 설정할 수 있으며, 이는 많은 유연성을 제공합니다. 사이트의 일부 페이지에는 Google +1 버튼이있을 수 있지만 다른 페이지에는 그렇지 않습니다.
각 명령어의 소스 목록은 상당히 유연 할 수 있습니다. 패턴 (데이터 :, https :)을 지정하거나 범위 (example.com, 호스트의 모든 소스, 모드 및 포트와 일치하는 example.com)를 지정하거나 완전한 URI (https://example.com:443, 특히 https 프로토콜, examain name, port 443)를 지정할 수 있습니다.
소스 목록에서 4 개의 키워드를 사용할 수도 있습니다.
없음 : 당신은 무엇이든 불일치 할 것으로 예상 할 수 있습니다
self : 현재 소스와 동일하지만 하위 도메인은 포함되지 않습니다.
불안한 인라인 : 인라인 JavaScript 및 CSS를 허용합니다
안전하지 않은-eval : eval과 같은 JS에 텍스트를 허용하는 메커니즘
이러한 키워드를 인용해야합니다.
모래 상자
여기서 논의 할 가치가있는 또 다른 지침이 있습니다 : 샌드 박스. 다른 지침과 다소 일치하지 않습니다. 주로 페이지가로드 할 수있는 리소스가 아닌 페이지에서 수행 된 동작을 제어합니다. 이 속성이 설정되면 페이지는 샌드 박스 속성 세트가있는 프레임처럼 작동합니다. 이는 양식 제출 등을 방지하는 등 페이지에 광범위한 영향을 미칩니다.이 기사의 범위를 초과하지만 HTML5 사양의 샌드 박스 로고 설정 섹션에서 더 많은 정보를 찾을 수 있습니다.
유해한 인라인 코드
CSP는 소스 화이트리스트를 기반으로하지만 XSS 공격의 가장 큰 소스 인 인라인 스크립트 주입을 해결하지는 않습니다. 공격자가 유해한 코드 (<cript> sendmydatatoevildotcom (); </script>)을 포함하는 스크립트 태그를 주입 할 수있는 경우 브라우저에는이 태그를 구별 할 수있는 메커니즘이 없습니다. CSP는 인라인 스크립트를 완전히 금지 하여이 문제를 해결할 수 있습니다.
이 금지에는 스크립트에 내장 된 스크립트 태그뿐만 아니라 인라인 이벤트 핸들러 및 Javascrpt : URL도 포함됩니다. 스크립트 태그의 내용을 외부 파일에 넣고 JavaScript를 대체해야합니다. <a… onclick = [javaScript]>를 적절한 addEventListener로 대체하십시오. 예를 들어 다음 양식을 작성할 수 있습니다.
<cript>
함수 doamazingthings () {
경고 ( '당신은 놀랍습니다!');
}
</스크립트>
<버튼> 내가 놀랍습니까? </button>
다음 형식으로 다시 작성하십시오.
<!-Amazing.html->
<script src = 'Amazing.js'> </script>
<버튼> 내가 놀랍습니까? </button>
// Amazing.js
함수 doamazingthings () {
경고 ( '당신은 놀랍습니다!');
}
document.addeventListener ( 'domcontentready', function () {
document.getElementById ( 'Amazing')
.addeventListener ( 'click', doamazingthings);
});
CSP 사용 여부에 관계없이 위의 코드는 실제로 더 큰 장점이 있습니다. 인라인 JavaScript는 구조와 동작을 완전히 혼합합니다. 그렇게해서는 안됩니다. 또한 아웃 리치 리소스는 브라우저에서 캐시하기 쉽고 개발자가 이해하기 쉽고 컴파일 및 압축하기 쉽습니다. 봉사 활동 코드를 사용하는 경우 더 나은 코드를 작성합니다.
인라인 스타일은 스타일 속성과 스타일 태그를 외부 스타일 시트로 추출해야합니다. 이렇게하면 모든 종류의 마법의 데이터 누출을 방지 할 수 있습니다.
인라인 스크립트와 스타일이 있어야하는 경우 스크립트 -SRC 또는 Style-SRC 속성에 대한 '안전하지 않은 인라인 값을 설정할 수 있습니다. 그러나 이것을하지 마십시오. 인라인 스크립트를 금지하는 것은 CSP가 제공하는 최대 보안 보증입니다. 동시에 인라인 스타일을 금지하면 응용 프로그램이 더 안전하고 강력해질 수 있습니다. 상충 관계이지만 그만한 가치가 있습니다.
평가
공격자가 스크립트를 직접 주입 할 수 없더라도 응용 프로그램이 삽입 된 텍스트를 실행 가능한 스크립트로 변환하여 자체적으로 실행하도록 유도 할 수 있습니다. Eval (), newFunction (), settimeout ([String], ...) 및 SetInterval ([String], ...)는 모두 위험한 캐리어가 될 수 있습니다. CSP 가이 위험을 목표로하는 전략은 이러한 벡터를 완전히 차단하는 것입니다.
이것은 앱을 구축하는 방법에 몇 가지 영향을 미칩니다.
Eval에 의존하지 않고 내장 JSON.PARSE를 통해 JSON을 구문 분석합니다. IE8 이후 브라우저는 로컬 JSON 작업을 지원하며 이는 완전히 안전합니다.
문자열 대신 인라인 함수로 settimeout 및 setInterval의 호출 메소드를 다시 작성하십시오. 예를 들어:
settimeout (document.querySelector ( 'a'). style.display = 'none';, 10);
다음과 같이 다시 작성할 수 있습니다.
settimeout (function () {document.querySelector ( 'a'). style.display = 'none';}, 10);
런타임에서 인라인 템플릿을 피하십시오 : 많은 템플릿 라이브러리는 새로운 기능 ()을 사용하여 템플릿 생성 속도를 높입니다. 이것은 역동적 인 프로그램에 좋지만 악의적 인 텍스트에는 위험합니다.
보고서
CSP는 서버 측에서 신뢰할 수없는 리소스를 차단할 수 있는데, 이는 사용자에게 매우 유용하지만, 다양한 알림을 서버로 전송하여 악의적 인 스크립트 주입을 식별하고 수정할 수 있도록 매우 유용합니다. 이를 위해 브라우저에 보고서 -URI 지침을 통해 JSON 형식의 인터셉트 보고서를 주소로 보내도록 지시 할 수 있습니다.
Content-Security-Policy : Default-SRC 'Self'; ...; report-uri /my_amazing_csp_report_parser;
보고서는 다음과 같습니다.
{
CSP-보고 : {
Document-uri :,
추천자 :,
Blocked-uri :,
Violent-Directive : Script-Src 'self'https://apis.google.com,
Original-Policy : Script-Src 'self'https://apis.google.com; 보고서-우리
}
}
포함 된 정보는 발생하는 문서 -URI, 페이지 참조 자, 페이지 정책을 위반하는 리소스, 위반 지침 및 모든 페이지 컨텐츠의 원래 정책을 포함하여 차단 상황을 식별하는 데 도움이됩니다.
현실적인 사용
CSP는 이제 Chrome 16+ 및 Firefox 4+ 브라우저에서 사용할 수 있으며 IE10에서 제한된 지원을받을 것으로 예상됩니다. Safari는 아직 지원되지 않지만 WebKit Nightly 빌드를 사용할 수 있으므로 아래 반복에서 Safari가 지원 될 것으로 예상됩니다.
아래에서 일반적으로 사용되는 일부 사용 사례를 살펴 보겠습니다.
실제 사례 1 : 소셜 미디어 위젯
Google +1 버튼에는 https://apis.google.com의 스크립트와 https://plusone.google.com에 포함 된 IFRames가 포함되어 있습니다. Google+1 버튼을 사용하려면 정책에 이러한 소스가 포함되어야합니다. 가장 쉬운 전략은 script-src https://apis.google.com입니다. Frame-Src https://plusone.google.com. 또한 Google에서 제공 한 JS 조각이 외부 JS 파일에 저장되어 있는지 확인해야합니다.
Facebook의 같은 버튼을위한 많은 구현 솔루션이 있습니다. 나머지 사이트에서 잘 분리되어 있으므로 iframe 버전을 고수하는 것이 좋습니다. 이를 위해서는 프레임 -src https://facebook.com 지시문을 사용해야합니다. 기본적으로 Facebook에서 제공하는 iframe 코드는 상대 경로 //facebook.com을 사용합니다. 이 코드를 https://facebook.com으로 수정하십시오. HTTP를 사용하지 않아도됩니다.
Twitter의 트윗 버튼은 https://platform.twitter.com의 스크립트와 프레임에 따라 다릅니다 (Twitter는 기본적으로 상대 URL을 제공합니다. 복사 할 때 코드를 편집하여 HTTPS로 지정하십시오).
다른 플랫폼은 비슷한 상황을 가지고 있으며 유사하게 해결할 수 있습니다. 기본 SRC를 NON으로 설정 한 다음 콘솔을보고 위젯이 올바르게 작동하는지 확인하기 위해 어떤 리소스를 사용해야하는지 확인하는 것이 좋습니다.
여러 위젯을 사용하는 것은 매우 간단합니다. 모든 정책 지침을 병합하고 동일한 지침의 설정을 하나로 묶는 것을 잊지 마십시오. 위의 세 가지 위젯을 사용하려면 전략이 다음과 같습니다.
script-src https://apis.google.com https://platform.twitter.com; Frame-Src https://plusone.google.com https://facebook.com https://platform.twitter.com
실제 사례 2 : 방어
은행 웹 사이트를 방문하여 필요한 자원 만로드했는지 확인하십시오. 이 경우 모든 것을 차단하기 위해 기본 권한을 설정하고 (기본 SRC 'None') 정책을 처음부터 구축하십시오.
예를 들어, 은행 웹 사이트는 https://cdn.mybank.net의 CDN의 이미지, 스타일 및 스크립트를로드하고 https://api.mybank.com/을 통해 XHR에 연결하여 다양한 데이터를 가져와야합니다. 또한 프레임을 사용해야하지만 프레임은 모두 3 명의 파티 로컬 페이지에서 나온 것입니다. 웹 사이트에는 플래시, 글꼴 및 기타 콘텐츠가 없습니다. 이 경우 가장 엄격한 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; 프레임 -SRC 'self'
실제 사례 3 : SSL 만 사용하십시오
웨딩 링 포럼 관리자는 모든 자원이 안전한 방식으로로드되기를 원하지만 실제로 너무 많은 코드를 작성하고 싶지는 않습니다. 많은 타사 포럼 인라인 스크립트와 스타일을 다시 작성하는 것은 그의 능력을 넘어선 것입니다. 따라서 다음 전략은 매우 유용 할 것입니다.
Content-Security-Policy : Default-SRC HTTPS :; Script-Src https : '안전하지 않은 인라인'; Style-Src https : '안전하지 않은 인라인'
Default-SRC는 HTTPS를 지정하지만 스크립트와 스타일은 자동으로 상속되지 않습니다. 각 지침은 기본 리소스 유형을 완전히 무시합니다.
미래
W3C의 웹 애플리케이션 보안 실무 그룹은 컨텐츠 보안 정책 사양에 대한 세부 정보를 개발하고 있습니다. 버전 1.0은 최종 개정 단계에 들어가서이 기사에 설명 된 내용에 매우 가깝습니다. Public-WebAppsec@ email Group은 버전 1.1에 대해 논의하고 있으며 브라우저 제조업체도 CSP의 구현을 통합하고 개선하기 위해 열심히 노력하고 있습니다.
CSP 1.1은 아르 보드에 별도로 나열할만한 몇 가지 흥미로운 것들이 있습니다.
메타 태그를 통해 정책 추가 : CSP를 설정하는 선호하는 방법은 HTTP 헤더이며 매우 유용하지만 태그 나 스크립트를 통해 더 직접적이지만 아직 완료되지 않았습니다. WebKit은 메타 요소를 통해 권한 설정의 기능을 구현 했으므로 이제 Chrome에서 다음 설정을 시도 할 수 있습니다. <metahttp-equiv = x-webkit-csp content = [정책은 여기에 간다]> 문서 헤더에 추가하십시오.
런타임에 스크립트를 통해 정책을 추가 할 수도 있습니다.
DOM API :이 기능이 다음 CSP 반복에 추가되면 JavaScript를 통해 페이지의 현재 보안 정책을 쿼리하고 다른 상황에 따라 조정할 수 있습니다. 예를 들어, eval ()를 사용할 수 있으면 코드 구현이 약간 다를 수 있습니다. 이것은 JS 프레임 워크의 저자에게 매우 유용합니다. API 사양은 여전히 매우 불확실하며 초안 사양의 스크립트 인터페이스 섹션에서 최신 반복을 찾을 수 있습니다.
새로운 지침 : 스크립트-비를 포함하여 많은 새로운 지시문이 논의 중입니다. 인라인 스크립트는 명시 적으로 지정된 스크립트 요소를 사용하는 경우에만 사용할 수 있습니다. 플러그인 유형 : 플러그인 유형을 제한합니다. 양식 액션 : 양식을 특정 소스에만 제출할 수 있습니다.
이러한 향후 기능에 대한 토론에 관심이 있으시면 메일 목록의 아카이브를 읽거나 메일 링리스트에 추가 할 수 있습니다.
이 기사는 다음에서 번역됩니다.
발췌 : Jiang Yujie의 블로그