XSS(Cross Site Script) mechanism

본 내용은 XSS가 어떠한 메커니즘을 통해 공격되고 우회되는지에 대한 내용이다.

XSS에 대한 기본적인 내용은 아래 링크에서 확인 할 수 있다.

https://hg2lee.tistory.com/entry/Cross-Site-Script-XSS

Cross-Site Script (XSS)

---

서버/클라이언트 측 필터링 메커니즘과 우회 허점

서버측에서는 요청을 처리할 때 "script, javascript:"등을 제거하거나 이스케이프 처리가 이루어지며, 브라우저 측 필터는 렌더링 전에 응답 내용 중 의심 패턴을 찾아 동작을 차단하려고 시도한다.

WAF와 같은 웹 방화벽 또한 통신 레벨에서 "<", ">"등의 특수 문자가 포함된 요청을 차단하는 시그니처 기반의 필터링을 수행할 수 있다.

그러나 이 모든것들은, 문자열 패턴에 의존한다는 것이다. 이러한 점은 한계가 존재한다. XSS공격만 해도 셀 수 없을정도의 수많은 변조 페이로드가 존재하기 때문이다. 지금도 여전히 다양한 사용자들에 의해 변종 페이로드는 개발되고 있다. 

 

현재 수많은 XSS공격에 대한 피해는 "블랙리스트 방식"의 필터링으로 인해 발생되고 있다.

특정 키워드 혹은 태그만 차단하게 되면 공격자는 우회 변형을 통해 필터링을 손쉽게 우회할 수 있다.

대소문자, 태그 쪼개기, \<와 같이 백슬래시 추가, 인코딩등 무수한 방법들이 존재한다.

 

현재 가장 많이 사용되는 우회 방법은 인코딩을 통한 우회 기법이다. 이는 다양한 악성 페이로드를 인코딩 하여 필터가 이를 알아보지 못하게 만든 후 브라우저가 디코드 하여 실행 하게끔 한다.

실제로 OWASP XSS Cheat Sheet에는 <문자 하나만 해도 70여가지가 넘는 인코딩 표현이 가능하다.

---

그렇다면 인코딩 된 데이터를 차단하면 괜찮을까?

이러한 필터링 제한은 이중 인코딩 기법을 통해 우회가 가능하다.

인코딩 된 데이터를 한번 더 인코딩하는 2중 인코딩된 문자열을 만들게 되면, 1차 디코딩 후 여전히 인코딩된 형태로 필터링을 우회할 수 있다. 이후 브루아저 혹은 서버의 후속 디코딩 단계에서 최종적으로 악성 페이로드로 해석되어 실행되게 된다.

 

이처럼 서버 및 클라이언트의 XSS 필터링은 복잡하며, 불완전하다. 크롬과 같은 브라우저는 한때 XSS Auditor과 같은 내장 필터를 사용하였지만, 패턴 매칭 기반의 한계로 인해 우회 및 오탐의 문제로 인해 현재는 폐지되었다.

 

현재 최선의 방어 대책은 출력 시 안전한 인코딩 처리와 CSP 적용등을 통한 다층 방어가 최선이다.

템플릿 사용시 Raw HTML(innerHTML 혹은 <%- %>) 사용

EJS, JSP, PHP등 다양한 템플릿 등에서 사용자 입력을 이스케이프 하지 않고 <%- 변수 %>를 통한 Raw HTML로 삽입하게 되면, 엔터티만 처리해도 결국 클라이언트 측에서 HTML로 변환되어 실행되게 된다. 현재 다양한 실무적인 환경에서 흔히 발견되는 예시를 들면 사용자 편의를 위해 <mark, strong>과 같은 태그를 넣기 위해 raw HTML로 처리하다 XSS공격이 가능해지는 경우가 있다. 

 

즉, 불완전한 블랙리스트 방식의 필터링, 서버 측 이스케이프 부재, 클라이언트 디코딩 구조는 실무적인 환경에서 흔히 마주하게 되는 취약한 패턴이다.

 

브라우저 단의 디코딩 원리

브라우저는 응답된 문자열을 HTML, CSS, JS 등의 렌더링 규칙에 따라 파싱하게 되며, 이때 자동 디코딩 동작을 수행하게 된다.

인코딩 유형	브라우저 자동 처리 여부	예시	복원 결과
HTML Entity	O	&lt;script&gt;	<script>
URL Encoding	O	%3Cscript%3E	<script>
Hex/Unicode	O	\x3Cscript\x3E	<script>
Double Encoding	O	%26lt%3Bscript%26gt%3B	&lt;script&gt; → <script>
Base64 (data URI)	O	data:text/html;base64,...	디코딩 후 DOM 삽입

서버와 브라우저의 차이

구분	서버	브라우저
주 역할	요청 수신, 응답 생성	HTML 파싱, 렌더링, 스크립트 실행
인코딩 처리	대부분 raw 상태 그대로 응답	수신된 데이터 → 자동 디코딩 후 렌더링
주요 작업	텍스트 문자열을 반환	문자열을 의미 있는 DOM 객체로 변환

 

브라우저는 사람이 보는 화면을 만들기 위해 원래 의도된 의미로 복원(디코딩)을 수행하게 된다.

즉, 서버가 raw(문자열 그대로)데이터로 보냈더라도, 브라우저는 HTML 콘텐츠구나 라고 인식하고 자동으로 디코딩해서 실행된다.

HTML5 스펙상, HTML파서(HTML Parser)는 HTML Entity를 모드 디코딩한 후 파싱하도록 정의되어 있다.

디코딩 주체가 누구든 XSS는 렌더링 시점에서 공격 성공유무가 결정된다.

브라우저 렌더링 파이프라인과 XSS 우회 지점

웹 브라우저는 서버로부터 HTML 응답을 받으면, 이를 화면에 나타내기 전 여러 단계를 거치게 된다.

응답 디코딩 -> HTML 파싱 -> DOM 생성 -> 스크립트 실행 -> 렌더링 과정을 거치게 된다.

이중 HTML 파싱과 스크립트 실행이 분리되어 있다는 점을 이용하는 것이 XSS 공격 우회에 핵심이다.

 

예를 들어, <scr<!-- 과같이 주석을 통해 script 태그를 망가뜨리더라도, HTML 파싱 단계에서 태그 구조를 해석한 뒤 자바스크립트로 다시금 실행하게 된다. 혹은 </script> <img src=x onerror></img>를 삽입 하여도 파싱 단꼐에서 태그를 구조 해석 후 자바스크립트로 실행시 파싱 시점에 새로 삽입된 img 요소는 DOM에 정상 추가되고, 이후 자바스크립트를 실행할 때 script 태그의 오류가 존재하더라도 이미 파싱된 새로운 스크립트는 독립적으로 실행되게 된다.

 

또한 인코딩을 통한 데이터는 DOM에 적용되기 전에 해독되므로 필터가 미리 인코딩된 형태를 고려하지 못한다면 브라우저의 디코딩 단계에서 무력화 된다.

 

DOM 기반에서의 XSS공격시 최신 브라우저에서는 Window.location, location.hash값을 자바스크립트에서 참조할 떄 자동으로 일부 문자를 URL 인코딩하여 제공하지만, 구형 레거시 브라우저에서는 별도의 인코딩을 포함하지 않는다. 이와 같이 개발자가 별도 인코딩 처리를 하지 않았다면 악성 문자가 그대로 DOM 조작에 사용되어 공격에 성공하게 된다.

이러한 부분을 통해 브라우저 간 디코딩/파싱 차이 역시 XSS공격에 성공 유/무를 판단할 수 있다.

 

DOM 기반 XSS와 클라이언트 자바스크립트 메서드의 공격 흐름

DOM XSS의 경우 공격자가 조작한 데이터가 클라이언트의 자바스크립트의 source를 통해 sink함수로 흘러가 발생된다.

여기서 source는 "window.location, document.cookie, localStorage"등 공격자가 통제할 수 있는 입력을 의미하고, sink란 "eval(), document.write(), innerHTML" 처럼 전달된 데이터를 실제 HTML 혹은 코드로 실행하는 메서드를 의미한다.

• element.innerHTML / outerHTML / insertAdjacentHTML
  • 문자열을 HTML로 해석하여 요소의 내부에 DOM으로 삽입
  • 최신 브라우저에서는 innerHTML을 통한 스크립트 실행을 막고 있지만, IMG와 같은 태그를 통한 이벤트 핸들러는 아직 허용되어 있다.
• document.write() / document.writeln()
  • 호출 시 전달된 문자열을 현재 문서 스트림에 삽입한다.
• eval() / new Function() / setTimeout(string)
  • 문자열을 실제 자바스크립트 코드로 실행된다.
• DOM 속성의 이벤트 핸들러 프로퍼티
  • 특정 DOM 속성의 이벤트 핸들어의 값에 사용자의 입력값이 들어가게 될 경우 이벤트 핸들러를 조작하여 공격이 가능하다.
  • 자바스크립트 런타임에서 동적으로 석성이 추가된다.
• 특정 라이브러리/프레임워크 함수
  • 구 버전의 jQuery의 $('#elem').html(test)는 내부적으로 innerHTML을 사용하므로 위험하다.
  •  $('#elem').attr('href', test)의 경우 test값에 javascript: 가 들어가면 XSS가 발생한다.

방어 측면에서 Stored/Reflected XSS와의 DOM XSS의 차이점은 서버 로그 등에 악의적인 스크립트 문자열이 남지 않을 가능성성이 있어 탐지가 어렵다 또한 SPA(Single Page Application)처럼 클라이언트 측 렌더링이 많은 현대 어플리케이션에서는 DOM XSS위험이 상대적으로 증가한다.

 

innerHTML  대신 textContent 혹은 innerText를 사용하여 입력값을 문자열 그 자체로 인식되게 하여야 한다.

또한 CSP 헤더에 require-trusted-types-for 'script'를 설정하면 취약한 sink에 문자열을 직접 대입하는 것을 원천 차단한다.

이 경우 innerHTML같은 코드가 에러를 내며 동작하지 않게 된다. 현재 Chrome등 지원하고 있으며 아직까지는 많은 사이트에서는 쓰이지 않고 있지만 점차 채택이 늘어나는 추새이다.

 

Content Security Policy(CSP)의 역할, 우회 기법 및 한계

CSP는 현대 브라우저에 내장된 보안 기능으로, 웹 페이지가 로드될 떄 브라우저가 어떤 리소스를 허용할지 제약을 거는 정책이다. 

특히 스크립트의 출처를 통제함으로써 XSS을 완화한다. 하지만 잘못된 CSP 구성은 충분히 공격자가 우회하여 무력화 시킬 수 있다.

• unsafe-inline 허용
  
  • script-src 'unsafe-inline'이 포함되면 <script>태그 혹은 HTML 요소의 이벤트핸들러, 그리고 javascript: URI등을 모두 허용하게 된다.
  • nonce/hash 기반 CSP를 적용하여 필요한 인라인 스크립트에만 예외적으로 실행을 하도록 해야한다.
• unsafe-eval
  • 일부 구버전 라이브러리의 필요성으로 인해 script-src 'unsafe-eval;이 설정되면 eval 혹은 new Function() 같은 동적 코드 생성 함수의 실행을 허용하게 된다.
• 와일드카드(*)
  • 너무 광범위한 도메인 패턴을 허용하게 될 경우 공격자 서버에서 스크립트를 호스팅 하고 script src="" 를 통해 태그를 삽입하는 방식으로 XSS를 실행할 수 있다.
• 기타 리소스 허용
  • object-src 나 base-uri등의 지시자를 설정하지 않으면, <base>, <object>등을 악용할 수 있다.
  • base-uri가 미설정된 경우 공격자가 를 삽입하면, 이후 페이지의 상대 경로로 된 자원 로드가 모두 공격자 사이트를 가리키게 되어 악성 스크립트가 로드될 수 있다.
  • object-src가 없다면 <object data="javascript:alert(1)"></object> 같은 구문이 브라우저에서 처리되는 것을 막지 못할 수도 있다.
• JSONP/API 악용
  • 특정 도메인을 신뢰하도록 화이트리스트로 지정하더라도 해당 도메인의 JSONP 앤드포인트를 악용할 수 있따.
  • JSONP란 요청 시 콜백 함수를 지정하여 함수 호출 형태로 데이터를 반환하는 API이다. 이 때 callback=<script>의 쿼리를 받아들일 경우 CSP상으로는 허용된 도메인이라는 것이 약점이다.
• 파일 업로드
  • 예로 이미지 업로드 기능의 경우 확장자 체크 이후 내용을 검증하지 않는 경우 이미지 파일에 HTML내용의 파일을 업로드하고 해당 경로를 script로 삽입하여 XSS를 실행할 수 있다. 이 경우 script-src 'self;라 하더라도 우회가 가능하게 된다.

이 외에도 다양한 CSP우회가 가능하며 이는 CSP 설명에서 깊게 다루도록 하겠다.

 

최신 브라우저 및 프레임워크의 XSS 방지 기능과 우회 사례

현대 웹 개발에서는 과거에 비해 XSS 방어 수준이 상당히 높아졌다.

프론트엔드 프에임워크들과 템플릿 엔진들은 기본적으로 출력 시 자동 이스케이프를 적용하여, 개발자가 별도로 신경쓰지 않아도 일반적인 XSS를 방지한다.

 

또한 CSP는 현재 널리 사용되고 있어, 브라우저 차원에서의 XSS필터와 같은 기능은 오히려 감소하는 추세이다. 

대표적으로 Chrome의 XSS auditor은 과거에 존재하였으나, 완벽하지 않았고. 종종 정상 기능을 차단하는 문제로 공식 제거되었다. 이를 계기로 CSP 적용과 Trusted Types API 등의 새로운 표준을 통한 방어 방법들이 나타났다.

 

최신 브라우저 기능과 다양한 프레임워크레벨에서의 안전장치들은 다량 마련되어 있어 단순 XSS 페이로드로 발견되는 빈도는 줄었으나, 프레임워크 레벨에서의 자동 방어를 개발자가 고의로 무시하거나 우회하는 경우 여전히 XSS가 발생되고 있다. 다양한 프레임워크들은 함수 명자체에서 위험성을 강조하고 있지만, 의외로 실무에서 남용되어 문제를 일으키는 경우가 존재한다. 프레임워크에서 제공하는 기본 보호를 해제하면 과거와 동일한 취약점에 노출되는 것이다.

 

프레임워크 자체의 취약점을 제외해서는 안된다.

AngularJS 혹은 Vue.js에서 발생되는 오류에서 XSS가 발생하고 있다. 

이러한 프레임워크는 SSTI 즉, 템플릿 인젝션 등의 간접적인 XSS우회가 가능하다는 것이다. 프레임워크가 XSS를 막아주지만, 해당 템플릿의 오사용으로 인한 SSTI가 존재할 경우 이로인해 XSS로 이어질 수 있는 아이러니한 상황이 발생한다.

 

또한 최신 브라우저들은 어플리케이션이 제공하는 보안 정책(CSP, Trusted Tyoes등)에 더 의존하고 있으며, 브라우저의 내장 기능은 권장되지 않거나 더이상 업데이트 되지 않고 있다.

 

하나 혹은 두개의 적은 수비 전략으로는 XSS를 막을 수 없다.

XSS는 꾸준히 OWASP Top 10에 등장하며 큰 공격 벡터를 나타내고 있따.

이러한 XSS는 다층적인 수비 전략만이 최선의 대응이라 할 수 있다.

 

참고자료

https://portswigger.net/web-security/cross-site-scripting/contexts#:~:text=The%20reason%20this%20works%20is,executed%20in%20the%20normal%20way https://web.dev/articles/trusted-types?  hl=ko#:~:text=To%20prevent%20server,Policy%20for%20additional%20bug%20mitigation  
https://www.vaadata.com/blog/content-security-policy-bypass-techniques-and-security-best-practices/#:~:text=,Bypassing%20CSP%20via%20file%20uploads
https://www.cobalt.io/blog/csp-and-bypasses#:~:text=attackers%20may%20still%20craft%20unique,but%20your%20defense%20in%20depth
https://owasp.org/www-community/Types_of_Cross-Site_Scripting#:~:text=Client%20XSS%20occurs%20when%20untrusted,could%20have%20been%20from%20a
https://www.acunetix.com/blog/articles/xss-filter-evasion-bypass-techniques/#:~:text=XSS%20filter%20evasion%20techniques%20allow,practices%20for%20preventing%20XSS%20attacks