신뢰할 수 있는 유형으로 DOM 기반 교차 사이트 스크립팅 취약점 방지

Krzysztof Kotowicz

브라우저 지원

• 83
• 83
• x
• x

소스

DOM 기반 교차 사이트 스크립팅 (DOM XSS)은 사용자 제어 소스 (예: 사용자 이름 또는 URL 프래그먼트에서 가져온 리디렉션 URL)의 데이터가 eval()와 같은 함수 또는 임의의 JavaScript 코드를 실행할 수 있는 .innerHTML와 같은 속성 setter인 싱크에 도달할 때 발생합니다.

DOM XSS는 가장 일반적인 웹 보안 취약점 중 하나이며 개발팀에서 실수로 앱에 이 취약점을 도입하는 경우가 많습니다. 신뢰할 수 있는 유형은 기본적으로 위험한 웹 API 함수를 안전하게 보호하여 애플리케이션을 작성하고, 보안을 검토하며, DOM XSS 취약점을 없애는 도구를 제공합니다. 신뢰할 수 있는 유형은 아직 지원되지 않는 브라우저에서 polyfill로 제공됩니다.

배경

수년 동안 DOM XSS는 가장 일반적이고 위험한 웹 보안 취약점 중 하나였습니다.

교차 사이트 스크립팅에는 두 가지 종류가 있습니다. 일부 XSS 취약점은 웹사이트를 구성하는 HTML 코드를 안전하지 않게 만드는 서버 측 코드로 인해 발생합니다. 다른 경우에는 자바스크립트 코드가 사용자 제어 콘텐츠로 위험한 함수를 호출하는 근본 원인이 클라이언트에 있습니다.

서버 측 XSS를 방지하려면 문자열을 연결하여 HTML을 생성하지 마세요. 추가적인 버그 완화를 위해 nonce 기반 콘텐츠 보안 정책과 함께 안전한 상황별 자동 이스케이프 템플릿 라이브러리를 대신 사용하세요.

이제 브라우저에서 신뢰할 수 있는 유형을 사용하여 클라이언트 측 DOM 기반 XSS를 방지할 수 있습니다.

API 소개

신뢰할 수 있는 유형은 다음과 같은 위험한 싱크 함수를 잠그는 방식으로 작동합니다. 브라우저 공급업체와 웹 프레임워크에서는 보안상의 이유로 이러한 기능을 사용하지 못하도록 하고 있으므로 이 중 일부는 이미 알고 있을 수 있습니다.

• 스크립트 조작:
  <script src> 및 <script> 요소의 텍스트 콘텐츠 설정
• 문자열에서 HTML 생성:
  • innerHTML
  • outerHTML
  • insertAdjacentHTML
  • <iframe> srcdoc
  • document.write
  • document.writeln
  • DOMParser.parseFromString
• 플러그인 콘텐츠 실행:
  • <embed src>
  • <object data>
  • <object codebase>
• 런타임 자바스크립트 코드 컴파일:
  • eval
  • setTimeout
  • setInterval
  • new Function()

신뢰할 수 있는 유형을 사용하려면 데이터를 이러한 싱크 함수에 전달하기 전에 처리해야 합니다. 브라우저가 데이터를 신뢰할 수 있는지 모르기 때문에 문자열만 사용하면 실패합니다.

금지사항

anElement.innerHTML  = location.href;

신뢰할 수 있는 유형을 사용 설정하면 브라우저에서 TypeError가 발생하고 문자열과 함께 DOM XSS 싱크를 사용하지 못하게 됩니다.

데이터가 안전하게 처리되었음을 나타내기 위해 특수한 객체인 신뢰할 수 있는 유형을 만듭니다.

의견을 제시하지

anElement.innerHTML = aTrustedHTML;
  

신뢰할 수 있는 유형을 사용 설정하면 브라우저에서 HTML 스니펫을 예상하는 싱크에 TrustedHTML 객체를 허용합니다. 다른 민감한 싱크를 위한 TrustedScript 및 TrustedScriptURL 객체도 있습니다.

신뢰할 수 있는 유형은 애플리케이션의 DOM XSS 공격 표면을 크게 줄여줍니다. 보안 검토를 간소화하고 브라우저에서 런타임 시 코드를 컴파일하거나 린트하거나 번들로 묶을 때 실행되는 유형 기반 보안 검사를 시행할 수 있습니다.

신뢰할 수 있는 유형 사용 방법

콘텐츠 보안 정책 위반 보고서 준비

오픈소스 go-csp-collector와 같은 보고서 수집기를 배포하거나 상응하는 상용 도구 중 하나를 사용할 수 있습니다. 브라우저에서 위반을 디버그할 수도 있습니다.

document.addEventListener('securitypolicyviolation',
    console.error.bind(console));

보고서 전용 CSP 헤더 추가

신뢰할 수 있는 유형으로 마이그레이션하려는 문서에 다음 HTTP 응답 헤더를 추가합니다.

Content-Security-Policy-Report-Only: require-trusted-types-for 'script'; report-uri //my-csp-endpoint.example

이제 모든 위반이 //my-csp-endpoint.example에 보고되지만 웹사이트는 계속 작동합니다. 다음 섹션에서는 //my-csp-endpoint.example의 작동 방식을 설명합니다.

주의: 신뢰할 수 있는 유형은 HTTPS 및 localhost와 같은 보안 컨텍스트에서만 사용할 수 있습니다.

신뢰할 수 있는 유형 위반 식별

이제부터 신뢰할 수 있는 유형에서 위반을 감지할 때마다 브라우저에서 구성된 report-uri에 보고서를 전송합니다. 예를 들어 애플리케이션이 문자열을 innerHTML에 전달하면 브라우저에서는 다음과 같은 보고서를 전송합니다.

{
"csp-report": {
    "document-uri": "https://my.url.example",
    "violated-directive": "require-trusted-types-for",
    "disposition": "report",
    "blocked-uri": "trusted-types-sink",
    "line-number": 39,
    "column-number": 12,
    "source-file": "https://my.url.example/script.js",
    "status-code": 0,
    "script-sample": "Element innerHTML <img src=x"
}
}

이는 39행의 https://my.url.example/script.js에서 innerHTML가 <img src=x로 시작하는 문자열로 호출되었음을 나타냅니다. 이 정보는 코드에서 DOM XSS를 도입할 수 있고 변경해야 하는 부분을 좁히는 데 도움이 됩니다.

참고: 이와 같은 위반은 대부분 코드베이스에서 코드 린터 또는 정적 코드 검사기를 실행하여 감지할 수도 있습니다. 이를 통해 대량의 위반을 빠르게 식별할 수 있습니다. 준수하지 않는 코드가 실행될 때 CSP 위반이 트리거되므로 린터 결과와 함께 CSP 위반을 계속 분석해야 합니다.

위반사항 수정

신뢰할 수 있는 유형 위반을 수정할 수 있는 몇 가지 옵션이 있습니다. 문제 코드를 삭제하거나, 라이브러리를 사용하거나, 신뢰할 수 있는 유형 정책을 생성하거나, 마지막 수단으로 기본 정책을 생성할 수 있습니다.

문제가 되는 코드를 다시 작성하세요.

준수하지 않는 코드가 더 이상 필요하지 않거나 위반을 일으키는 함수 없이 다시 작성할 수 있습니다.

의견을 제시하지

el.textContent = '';
const img = document.createElement('img');
img.src = 'xyz.jpg';
el.appendChild(img);

금지사항

el.innerHTML = '';

라이브러리 사용

일부 라이브러리는 싱크 함수에 전달할 수 있는 신뢰할 수 있는 유형을 이미 생성합니다. 예를 들어 DOMPurify를 사용해 HTML 스니펫을 정리하여 XSS 페이로드를 삭제할 수 있습니다.

import DOMPurify from 'dompurify';
el.innerHTML = DOMPurify.sanitize(html, {RETURN_TRUSTED_TYPE: true});

DOMPurify는 신뢰할 수 있는 유형을 지원하며 TrustedHTML 객체로 래핑된 정리된 HTML을 반환하므로 브라우저에서 위반을 생성하지 않습니다.

주의: DOMPurify의 정리 로직에 버그가 있는 경우에도 애플리케이션에 DOM XSS 취약점이 있을 수 있습니다. 신뢰할 수 있는 유형은 값을 어느 정도 처리하도록 강제하지만 정확한 처리 규칙이 무엇인지, 그리고 사용하는 특정 규칙이 안전한지 여부는 아직 정의하지 않습니다.

신뢰할 수 있는 유형 정책 만들기

위반을 일으키는 코드를 삭제할 수 없는 경우도 있고 값을 정리하고 신뢰할 수 있는 유형을 만드는 라이브러리가 없는 경우도 있습니다. 이 경우 신뢰할 수 있는 유형 객체를 직접 만들 수 있습니다.

먼저 정책을 만듭니다. 정책은 입력에 특정 보안 규칙을 적용하는 신뢰할 수 있는 유형의 팩토리입니다.

if (window.trustedTypes && trustedTypes.createPolicy) { // Feature testing
  const escapeHTMLPolicy = trustedTypes.createPolicy('myEscapePolicy', {
    createHTML: string => string.replace(/\</g, '&lt;')
  });
}

이 코드는 createHTML() 함수를 사용하여 TrustedHTML 객체를 생성할 수 있는 myEscapePolicy라는 정책을 만듭니다. 정의된 규칙은 새로운 HTML 요소가 생성되지 않도록 HTML 이스케이프 < 문자를 사용합니다.

다음과 같이 정책을 사용합니다.

const escaped = escapeHTMLPolicy.createHTML('<img src=x onerror=alert(1)>');
console.log(escaped instanceof TrustedHTML);  // true
el.innerHTML = escaped;  // '&lt;img src=x onerror=alert(1)>'

참고: createHTML()으로 trustedTypes.createPolicy()에 전달되는 JavaScript 함수는 문자열을 반환합니다. 그러나 createPolicy()는 반환 값을 올바른 유형(이 경우 TrustedHTML)으로 래핑하는 정책 객체를 반환합니다.

기본 정책 사용

CDN에서 서드 파티 라이브러리를 로드하는 경우와 같이 문제가 되는 코드를 변경할 수 없는 경우도 있습니다. 이 경우 기본 정책을 사용하세요.

if (window.trustedTypes && trustedTypes.createPolicy) { // Feature testing
  trustedTypes.createPolicy('default', {
    createHTML: (string, sink) => DOMPurify.sanitize(string, {RETURN_TRUSTED_TYPE: true})
  });
}

default라는 정책은 신뢰할 수 있는 유형만 허용하는 싱크에서 문자열이 사용되는 모든 경우에 사용됩니다.

팁: 기본 정책은 드물게 사용하고, 일반 정책을 대신 사용하도록 애플리케이션을 리팩터링하는 것이 좋습니다. 이렇게 하면 보안 규칙이 처리되는 데이터에 가까운 설계와 값을 올바르게 정리하는 데 가장 많은 컨텍스트가 있는 설계가 촉진됩니다.

콘텐츠 보안 정책 시행으로 전환

애플리케이션에서 더 이상 위반을 생성하지 않으면 신뢰할 수 있는 유형을 시행할 수 있습니다.

Content-Security-Policy: require-trusted-types-for 'script'; report-uri //my-csp-endpoint.example

웹 애플리케이션이 아무리 복잡하더라도 정책 중 하나에 포함된 코드만으로 DOM XSS 취약점을 야기할 수 있으며, 정책 생성을 제한하여 이를 더욱 제한할 수 있습니다.

추가 자료

• 신뢰할 수 있는 유형 GitHub
• W3C 사양 초안
• FAQ
• 통합