flawopen.com/XSS/CSP vs. escape
CSP와 출력 이스케이프: XSS 방어에 둘 다 필요할까요?
컨텍스트별 출력 인코딩은 신뢰할 수 없는 값을 실행 가능한 마크업이 아닌 데이터로 페이지에 넣습니다. Content Security Policy(CSP)는 두 번째 방어선입니다. 어떤 스크립트가 실행되고 어디에 연결될 수 있는지 확인하는 경비원처럼 인코딩 누락이 있을 때 일부 삽입 동작을 차단할 수 있습니다. 누락 자체를 고치지는 않으며, 느슨한 정책은 스크립트를 막지 못할 수 있습니다.
각 방어의 역할
데이터가 출력 컨텍스트에 들어가는 시점에 인코딩하세요. HTML 텍스트, 따옴표 속성, JavaScript, CSS, URL 구성요소는 파싱 규칙이 다르므로 정확한 컨텍스트에 맞는 인코더를 사용해야 합니다. 프레임워크 템플릿과 안전한 DOM sink를 우선하고 inline script나 이벤트 처리 속성과 같은 실행 컨텍스트에 신뢰할 수 없는 값을 넣지 마세요. 이것이 XSS의 기본 방어입니다.
강제 적용 Content-Security-Policy는 inline script, script 출처, connect-src 같은 연결 대상을 제한할 수 있습니다. 인코딩이 누락되어도 잘 설계된 정책은 특정 스크립트나 연결을 차단할 수 있습니다. 효과는 정책과 브라우저에 따라 다릅니다. CSP가 모든 payload, 데이터 유출, script gadget을 막는다고 보장할 수 없으며 삽입 결함은 남습니다.
CSP가 출력 인코딩을 대체할 수 없는 이유
느슨하거나 잘못 설정된 정책은 삽입된 코드 실행을 허용할 수 있습니다. 'unsafe-inline'을 허용하면 inline script 보호가 약해지고, 넓은 호스트 allowlist는 script를 제공할 수 있는 endpoint까지 허용할 수 있습니다. CSP 지시자는 역할이 다릅니다. script-src를 제한해도 네트워크 대상을 제한하려면 connect-src를 별도로 설정해야 할 수 있습니다. Content-Security-Policy-Report-Only는 위반을 보고할 뿐 차단하지 않습니다. 인코딩으로 결함을 고치고 CSP는 심층 방어로 사용하세요.
자주 묻는 질문
필요한 스크립트를 조사하고 'unsafe-inline'과 'unsafe-eval'을 피하는 nonce 또는 hash 기반 정책을 시험하세요. 먼저 Content-Security-Policy-Report-Only로 문제를 찾으세요. 이 헤더는 정책을 강제하지 않습니다. 보고서를 검토하고 필요한 의존성을 조정한 뒤 강제 적용 Content-Security-Policy를 배포하세요. 전 과정에서 컨텍스트별 인코딩을 유지하세요.