AI 요약
Scratch는 사용자로부터 입력받은 SVG 데이터를 분석하고 이를 메인 문서에 삽입하여 정확한 크기를 측정하는 방식을 사용하는데, 이는 보안상 매우 위험한 구조를 가지고 있습니다. 2019년 처음 발견된 <script> 태그를 통한 XSS 공격을 시작으로, Scratch는 정규식 기반의 필터링을 도입했으나 이는 대소문자 구분 누락 등 허점이 많아 금세 우회되었습니다. 2020년에는 CVE-2020-27428 취약점을 통해 인라인 이벤트 핸들러를 이용한 공격 방식이 확인되었고, 이에 대한 대응으로 DOMPurify 라이브러리가 도입되었습니다. 그러나 2022년에도 <image> 태그를 통한 HTTP 정보 유출 문제가 발견되는 등 보안 구멍은 여전히 존재합니다. 필자는 이러한 복잡한 인프라 구축을 통한 정화 방식이 근본적인 해결책이 될 수 없으며 실패할 운명이라고 지적합니다.
핵심 인사이트
- 2019년 첫 사고: Scratch 3 출시 몇 달 후, SVG 내
<script>태그를 실행할 수 있는 XSS 취약점이 공식 발견되었습니다. - CVE-2020-27428: 2020년 apple502j에 의해 발견된 이 취약점은 대소문자를 구분하는 정규식의 허점(
<SCRIPT>)과 인라인 이벤트 핸들러를 활용한 우회 기법을 포함합니다. - TurboWarp Desktop의 선제 조치: 2021년 3월 출시된 v0.2.0 버전부터 위험한 Node.js 통합 기능을 비활성화하여 보안 위험을 줄였습니다.
- 2022년 HTTP Leak: 정교한 정화 시도에도 불구하고, 2022년에는
<image>태그의 href 속성을 이용한 데이터 유출 취약점이 추가로 확인되었습니다.
주요 디테일
- 위험한 렌더링 방식: Scratch는 SVG의
viewbox나width/height속성보다 신뢰할 수 있는 바운딩 박스(bounding box) 측정을 위해 SVG를 실제 문서에 임시로 추가하는 방식을 고수하고 있습니다. - 데스크톱 버전의 위험성: Scratch Desktop은 Electron의 Node.js 통합 기능을 활성화하고 있어, 웹상의 XSS 취약점이 사용자 로컬 PC의 임의 코드 실행(ACE)으로 직결될 수 있는 치명적 구조를 지녔습니다.
- 불완전한 정화 도구: 초기에는 정규식(Regex)을 사용했으나, 이후 DOMPurify를 도입했음에도 불구하고 SVG의 복잡성으로 인해 모든 보안 위협을 차단하지 못하고 있습니다.
- 우회 공격의 다양성: 공격자들은
<foreignObject>내부에img태그를 삽입하고onerror이벤트 핸들러를 사용하는 등 브라우저의 파싱 특성을 이용해 보안 필터를 무력화했습니다.
향후 전망
- 샌드박스 강화 필요성: 단순한 텍스트 기반 정화보다는 SVG를 별도의 격리된 환경(Sandbox)에서 처리하거나 렌더링 엔진 자체를 교체해야 한다는 목소리가 커질 것입니다.
- 복잡성과의 싸움: SVG 명세가 계속 확장됨에 따라 정화 로직은 더욱 복잡해질 것이며, 이는 또 다른 보안 허점을 낳는 악순환이 반복될 것으로 예상됩니다.
출처:hackernews