단일 페이지 애플리케이션에 CSP 배포

4959 단어 devopssecurityprogramming

단일 페이지 애플리케이션은 최신 CSP 기능과 충돌합니다. 이 기사에서는 CSP로 SPA를 보호하기 위한 구체적인 전략에 대해 설명합니다.






최신 CSP 정책에 대한 권장 모범 사례는 해시, 논스 및 'strict-dynamic' 에 의존합니다. 안타깝게도 이러한 기능은 최신 SPA와 충돌합니다. 이 문서에서는 SPA에 대한 보안 CSP 정책을 배포하기 위한 세 가지 구체적인 전략을 제안합니다. 첫 번째는 특정 상황에서 허용되는 'self' 를 허용하는 간단한 정책에 의존합니다. 두 번째 전략은 스크립트 로더를 사용하도록 기본 페이지를 다시 작성하여 CSP 해시를 활성화하는 것입니다. 세 번째 전략은 동적으로 제공되는 기본 페이지에 nonce를 삽입합니다.

CSP 요약



first article in this series에서는 XSS 공격에 대한 2차 방어선으로 CSP를 사용하는 방법에 대해 자세히 살펴보았습니다.

URL 기반 항목뿐만 아니라 highlighted why such policies are often insecure을 사용하여 CSP 구성을 다루었습니다. 이에 대한 응답으로 아래에 표시된 Google's "universal CSP policy" 에 대해 논의했으며 이는 보안과 복잡성 간의 탁월한 절충안을 제공합니다.

Content-Security-Policy: 
  script-src 'report-sample' 'nonce-3YCIqzKGd5cxaIoTibrW/A' 'unsafe-inline'
             'strict-dynamic' https: http: 'unsafe-eval';
  object-src 'none';
  base-uri 'self';
  report-uri /webchat/_/cspreport


이 정책은 nonce를 사용하여 페이지에서 합법적인 스크립트 블록 및 스크립트 파일의 초기 세트를 식별합니다. 이러한 스크립트가 실행되면 'strict-dynamic'의 자동 신뢰 전파 메커니즘을 사용하여 추가 스크립트를 로드할 수 있습니다.

불행하게도 이러한 유형의 정책은 conclusion of the first article에서 지적한 것처럼 단일 페이지 응용 프로그램에서 제대로 작동하지 않습니다.

그래서, 그게 무슨 일이야? SPA에서 CSP를 구성하는 문제를 살펴보고 몇 가지 솔루션에 대해 논의해 보겠습니다.

SPA의 과제



단일 페이지 응용 프로그램은 단일index.html 을 로드한 다음 필요한 JavaScript 코드를 부트스트랩하여 응용 프로그램을 시작합니다. 아래 코드 스니펫은 Angular 애플리케이션의 index.html 페이지를 보여줍니다.

<!doctype html>
<html lang="en">
<head>
  ...
</head>
<body>
  <app-root></app-root>
  <script src="runtime.7b63b9fd40098a2e8207.js" defer></script>
  <script src="polyfills.00096ed7d93ed26ee6df.js" defer></script>
  <script src="main.8e56a2a77fee2657fb91.js" defer></script>
</body>
</html>


SPA에 CSP를 배포하려면 먼저 애플리케이션의 JavaScript 번들이 로드할 수 있는 적법한 리소스임을 브라우저에 알려야 합니다. 위 스니펫에서 번들은 세 개의 개별 JavaScript 파일로 구성됩니다.

이를 수행하는 한 가지 방법은 응용 프로그램의 원본( https://example.com )에서 오는 스크립트를 승인하는 것입니다. script-src https://example.com 지시문이 있는 정책은 이러한 파일의 로드를 허용합니다.

불행하게도 previous article에서 논의한 것처럼 이러한 URL 기반 정책은 종종 안전하지 않으며 더 이상 사용되지 않습니다. 또한 URL 기반 표현식은 'strict-dynamic' 와 함께 사용할 수 없으므로 자동 트러스트 전파를 사용할 수 없습니다.

한 가지 대안은 CSP 레벨 2 기능인 해시를 사용하는 것입니다. 그러나 애플리케이션의 JavaScript 번들은 원격 파일로 호스팅되며 해시는 인라인 코드 블록에서만 작동합니다. 따라서 CSP 해시는 SPA와 호환되지 않습니다.

CSP 레벨 2는 원격 리소스 로드와 호환되는 nonce도 지원합니다. 그러나 one requirement for nonces은 모든 페이지 로드에서 고유하다는 것입니다. 본질적으로 이는 서버가 페이지를 제공할 때마다 새로운 nonce를 주입해야 함을 의미합니다. 그렇게 하는 것은 동적 서버 측 응용 프로그램에서는 쉽지만 SPA용 정적index.html 파일을 제공하는 것과는 호환되지 않습니다. 따라서 nonce도 SPA와 호환되지 않습니다.

해시와 nonce가 모두 나오면 SPA가 최신 CSP 정책을 사용할 수 있는 간단한 방법이 없습니다. 또한 추가 스크립트를 로드하기 위해 'strict-dynamic'를 사용할 수 없습니다. 'strict-dynamic'에 대한 지원 부족으로 인해 Twitter 타임라인과 같은 타사 구성 요소를 안정적으로 통합할 수 없습니다.

바로 지금, 나는 당신이 CSP에 다소 실망했을 것이라고 확신합니다. 그러나 걱정하지 마십시오. 이제 시작일 뿐입니다. SPA에서 CSP를 구현하기 위한 세 가지 구체적인 전략을 살펴보겠습니다.

Read more...
다양한 언어로 CPU 코어를 다 사용해 봅니다.
Perl Orientado a Objeto Part I

좋은 웹페이지 즐겨찾기

개발자 우수 사이트 수집

개발자가 알아야 할 필수 사이트 100선 추천 우리는 당신을 위해 100개의 자주 사용하는 개발자 학습 사이트를 정리했습니다
best100-homepage