홈으로 돌아가기

Edge에서 XSLT 비활성화: 정책 및 위험

Microsoft가 Edge 147에서 보안 위험으로 인해 구식 XSLT를 비활성화하기 위해 XSLTEnabled 정책을 구현합니다. 이 기사는 사용량, JS로의 마이그레이션, 2027년까지 다른 브라우저의 계획을 분석합니다.

Edge가 XSLT를 포기하다: 개발자를 기다리는 미래
Advertisement 728x90

Microsoft Edge에서 XSLT 비활성화: 새로운 정책과 보안 위험

Microsoft는 2026년 4월 9일에 출시된 Edge 147 버전에서 XSLT를 비활성화하는 정책을 도입합니다. XSLTEnabled 기능은 관리자가 구식 XML 변환 언어에 대한 액세스를 제어할 수 있게 하여 관련된 취약점을 최소화합니다. 이는 Chromium, WebKit, Gecko의 계획을 반영한 완전한 폐기 단계입니다.

XSLT란 무엇이며 왜 구식이 되었나

XSLT(Extensible Stylesheet Language Transformations)는 1999년 W3C 표준으로, XML을 HTML이나 다른 형식으로 변환하는 데 사용됩니다. 이 언어의 최신 버전은 브라우저에서 널리 지원되지 않습니다. 사용 통계: 웹 페이지의 0.02%만 XSLT를 사용하며, 변환 작업은 0.001% 미만을 차지합니다.

현대 대안은 더 큰 유연성을 제공합니다:

Google AdInline article slot
  • JavaScript 프레임워크(React, Vue.js)를 통한 동적 데이터 처리.
  • Web Components와 Shadow DOM을 이용한 구조화된 변환.
  • 템플릿 엔진(Handlebars, Pug)을 사용한 서버사이드 렌더링.

이러한 도구들은 REST/GraphQL API와 통합되어 클라이언트 측 XML 파서를 피할 수 있습니다.

Edge v147의 XSLTEnabled 정책

Edge 147의 보안 업데이트는 XSLT를 제어하는 정책 그룹을 추가합니다:

  • XSLTEnabled: XSLT 프로세서를 전역적으로 활성화 또는 비활성화합니다.
  • XSLTBaseURL: 스타일시트의 기본 URL(엔터프라이즈 시나리오로 제한).
  • XSLTSecurityManager: DOM 및 네트워크 리소스 액세스 관리.

엔터프라이즈 고객은 이를 비활성화하는 테스트를 권장합니다: 레거시 앱에 미치는 영향 평가, 파싱 오류 로그 모니터링. Microsoft는 사이버 보안 위험을 강조합니다—libxslt는 적극적인 유지보수 부족으로 미패치 취약점이 있습니다.

Google AdInline article slot

이 정책은 Windows 레지스트리(HKLM\SOFTWARE\Policies\Microsoft\Edge\XSLTEnabled) 또는 Active Directory의 그룹 정책을 통해 적용됩니다. 레지스트리 구문:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge]
"XSLTEnabled"=dword:00000000

Edge를 재시작한 후 변환은 NS_ERROR_XSLT_NOT_AVAILABLE로 차단됩니다.

브라우저별 폐기 일정

  • Edge (Chromium): v147(2026년 4월)에 정책 도입, Chromium에 이어 완전 제거.
  • Chrome: 146(2026년 3월)에서 테스트, 176(2027년 8월)에 비활성화.
  • Safari (WebKit): 2027년 폐기 계획, XML 유사 작업에 SwiftUI 집중.
  • Firefox (Gecko): 유사 정책 개발 중, 변환에 WebAssembly 우선.

Chromium 개발자들은 마이그레이션을 조율 중입니다: chrome://flags/#enable-xslt 플래그가 단계적으로 제거됩니다.

Google AdInline article slot

보안 위험과 마이그레이션

XSLT 핵심 라이브러리인 libxslt는 XXE(XML External Entity) 공격에 취약하며, 공격자가 로컬 파일을 추출하거나 SSRF를 수행할 수 있습니다. 패치 부족으로 2026년에 사용하기 위험합니다.

중급/고급 개발자를 위한 마이그레이션 전략:

  • 코드 감사: grep -r 'xslt\.' 또는 스택 트레이스 분석.
  • JS의 XPath + DOMParser로 교체.
  • 테스트: Puppeteer를 사용한 XSLT 비활성화 시뮬레이션.
  • 대체: Modernizr 또는 네이티브 document.implementation.hasFeature('XSLT', '1.0')를 통한 기능 감지.

간단한 XSLT를 JS로 마이그레이션하는 예:

// Legacy XSLT
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const result = xsltProcessor.transformToFragment(xmlDoc, document);

// Modern JS alternative
function transformXML(xmlString, xslString) {
  const xmlDoc = new DOMParser().parseFromString(xmlString, 'text/xml');
  const xslDoc = new DOMParser().parseFromString(xslString, 'text/xml');
  const xsltProcessor = new XSLTProcessor();
  xsltProcessor.importStylesheet(xslDoc);
  return xsltProcessor.transformToDocument(xmlDoc);
}

주요 요약

  • Edge 147의 XSLTEnabled 정책으로 2026년 4월부터 XSLT의 제어된 폐기가 시작됩니다.
  • libxslt 취약점(XXE, SSRF)으로 패치 없이는 기술이 안전하지 않습니다.
  • JS 변환 또는 서버사이드 템플팅으로 마이그레이션—2027년 표준.
  • 모든 엔진(Chromium, WebKit, Gecko)이 2027년까지 폐기 일정을 맞춥니다.
  • 엔터프라이즈 관리자: GPO를 통해 테스트, 레거시 XML 앱 모니터링.

— Editorial Team

Advertisement 728x90

다음 읽기