콘텐츠 보안 정책 - XSS 공격으로부터 웹사이트 보호

문제

Javascript의 경우 특정 타사 라이브러리를 사용하는 프로젝트를 빌드하는 동안 매우 일반적입니다. npm packages , 재귀적으로 더 많은 패키지를 사용하고 결국 코드에 엄청난 양의 타사 코드가 포함됩니다.
아무런 문제가 없으며 바퀴를 다시 발명할 필요가 없습니다. 필요한 라이브러리를 포함하고, 코드를 작동시키고, 테스트를 작성합니다. 스테이징 환경에 배포하고 자동화를 거쳐 최종적으로 프로덕션에 배포합니다.

문제는 도서관이 우리 웹사이트에 원격 콘텐츠를 로드하려고 할 때입니다. 이미지, 글꼴, 스타일 또는 Javascript일 수 있습니다. 이 콘텐츠는 모든 테스트와 확인을 우회하고 프로덕션에서 직접 실행됩니다. 더 나쁜 것은 콘텐츠가 제공되는 위치를 알 수 없다는 것입니다.

콘텐츠 보안 정책

콘텐츠 보안 정책(CSP)은 XSS 공격을 방지하는 데 도움이 되는 W3C specification입니다. CSP를 사용하면 개발자가 클라이언트 브라우저에서 리소스(이미지, 자바스크립트, 글꼴 등)를 가져오는 규칙을 정의할 수 있습니다. 개발자는 모든 리소스 로드를 허용/제한하고, 특정 도메인에서만 리소스를 로드하도록 제한하고, 다른 도메인에서는 허용하지 않는 정책을 정의할 수 있습니다. 예를 들어 CSP를 작성하여 브라우저가 example.com에서만 이미지를 로드하도록 제한할 수 있습니다. 다른 도메인의 이미지는 로드되지 않고 오류가 발생합니다. 리소스 외에도 CSP는 임베드에 대한 제어도 제공합니다.
다음 예제에서 CSP는 자체 도메인에서만 이미지/스크립트를 로드하도록 강제하고 다른 도메인에서 이미지를 로드하지 못하게 합니다.



W3c specification 문서에서:

One of the CSP goal is to mitigate the risk of content-injection attacks by giving developers fairly granular control over

• The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
• The execution of inline script
• Dynamic code execution (via eval() and similar constructs)
• The application of inline style

어떻게

CSP는 다음 두 가지 방법으로 구현할 수 있습니다.

HTTP 헤더에 지정

   Content-Security-Policy: __Policy__

META 태그에 지정

   <meta http-equiv="Content-Security-Policy" content=" __Policy__ ">

정책 정의

정책은 각 리소스의 허용된 위치를 정의하는 지시어의 축적이며 모든 지시어 수단은 허용되지 않습니다. 유용한 지시어 중 일부는 다음과 같습니다.

default-src : 모든 유형의 리소스에 대한 로딩 정책을 정의합니다.

script-src : javascript를 로드할 수 있는 모든 javascript에 대한 로드 정책을 정의합니다.

img-src : 이미지를 로드할 수 있는 모든 이미지에 대한 로드 정책을 정의합니다.

다른 리소스에 대한 지시문 목록은 here 입니다.

정책의 몇 가지 예는 다음과 같습니다.
1.

   Content-Security-Policy: default-src 'self';

이렇게 하면 동일한 도메인의 리소스만 허용되며 다른 모든 리소스는 로드되지 않습니다.
2.

   Content-Security-Policy: img-src example.com;

이렇게 하면 example.com 의 이미지만 허용되며 다른 모든 이미지는 로드되지 않습니다.
2.

   Content-Security-Policy: default-src 'self'; img-src example.com;

이렇게 하면 example.com의 이미지를 제외하고 동일한 도메인에 있는 경우에만 리소스를 로드할 수 있습니다.

보고

CSP는 로깅이 필요한 경우 report-uri 지시문을 통해 위반 보고서를 보내는 방법도 제공합니다.

`Content-Security-Policy: default-src 'self'; report-uri http://example.com/cspfails` 

보고서는 POST 요청 및 다음 JSON과 함께 전송됩니다.

{
 "csp-report": {
   "document-uri": "http://example.com/",
   "referrer": "",
   "blocked-uri": "http://example.com/some_malware.js",
   "violated-directive": "default-src self",
   "original-policy": "default-src 'self'; report-uri http://example.com/cspfails"
 }
}

위험

CSP를 정의하기 전에 웹앱에 필요한 모든 리소스와 해당 출처를 완전히 알고 있어야 합니다. 그렇지 않으면 일부 중요한 리소스가 차단되고 결국 임의의 버그가 발생할 수 있습니다.
웹 페이지를 원활하게 실행하는 데 필요한 모든 리소스가 무엇인지 확실하지 않은 경우 보고 모드에서 CSP를 구현할 수 있습니다. 이렇게 하면 위반이 보고되지만 리소스가 차단되지 않습니다. 정말 필요한 리소스, CSP를 구현할 수 있습니다. Content-Security-Policy 대신 이렇게 하려면 Content-Security-Policy-Report-Only 헤더를 사용해야 합니다.

Content-Security-Policy-Report-Only: __Policy__ + report-uri

자원

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

https://owasp.org/www-community/attacks/Content_Security_Policy