[XSS] XSS(Cross Site Scripting)

CHIKA·2024년 6월 26일

XSS (Cross Site Scripting)

웹 보안 취약점 중 하나로,
공격자가 클라이언트 측에 악성 스크립트를 삽입하여 브라우저에서 실행되게 하는 공격이다.
크게 Stored XSS, Reflected XSS, DOM-Based XSS로 나눌 수 있다.

1. Stored XSS (저장형 XSS)

회원가입, 게시판 글 작성 등 데이터가 저장되거나 출력되는 곳에서 가능하다.
서버 응답에 값이 찍혀 나오는지를 돌아다니면서 찾아야한다.
서버에 스크립트를 저장한다.

공격 시나리오

  1. 공격자는 게시글, 댓글 등 사용자 입력을 받는 부분의 취약점을 찾아 악성스크립트를 삽입. 서버에 저장.
  2. 피해자가 해당 게시글이나 댓글에 접근함.(request)
  3. 서버로부터 악성스크립트를 전달 받음.(response)
  4. 피해자의 브라우저에서 악성스크립트 실행.

찾는 순서

1) 작성한 데이터가 화면에 출력되는 것 확인하기
2) 특수문자 체크하기. <'">
입력하는 데이터 뒤에다가 그대로 써보기 . 못쓰는 경우가 있기 때문에.
3) javascript
<script>------</script>
POC (Proof of concept, 보여주기 용도)로 가장 많이 사용하는 코드는 alert(1)
alert,prompt,confirm,console.log 에 하나 사용하면 됌.

값 뒤에 +<script>alert(’xss attack!’)</script>
그리고 브라우저에서 스크립트가 잘 실행되는지 확인한다.

2. Reflected XSS (반사형 XSS)

아이디 중복체크 등 파라미터 데이터가 서버 응답에 삽입되는 곳에서 가능하다.
악성스크립트를 URL, 또는 HTTP 요청의 일부로 보내고, 피해자가 URL을 클릭하면 즉시 실행된다.
링크전달 공격으로, GET method로 전송이 가능해야한다.
ex) 'chika' 는 사용 가능한 아이디 입니다.
게시판에 'chika' 에 대한 결과가 없습니다.

공격 시나리오

  1. 공격자는 입력 값이 반영되는 곳을 찾아 악성 스크립트가 있는 URL 생성.
  2. 이 URL을 피해자가 방문하도록 유도
  3. 악성 스크립트가 실행

찾는 순서

1) 내가 입력한 데이터가 응답에 나오는지 확인하기.
2) 특수문자 체크하기 <'">
3) script 넣어보기

<script>alert(1)</script>

Stored XSS vs Reflected XSS

1. 출력위치

Stored XSS 는 저장하는 곳, 출력되는 곳이 달라 출력위치가 다를 수 있다.
Reflected XSS 는 삽입하는 곳, 출력하는 곳이 같다.

2. 공격방법

Stored XSS 가 게시판에 글을 작성하고 게시글을 읽는 사람에게 스크립트를 전달, 실행한다면
Reflected XSS 는 링크전달 공격으로 링크를 클릭하게 만들어야한다.

3.위험도

Stored XSS 는 광역기로, 흔적이 남으며 위험도가 높다.
그에 반해 Reflected XSS 는 타겟팅으로. 서버에 흔적이 남지 않는다.

3. DOM-Based XSS

DOM이란?
Document Object Model의 약자로 원본 HTML 문서의 객체 기반 표현방식이다.
Document.write, Document.cookie 같은 스크립트로 DOM 구조에 접근 할 수 있다.

서버가 아닌 클라이언트 측 자바스크립트의 코드에서 DOM을 조작하여 발생하는 취약점이다.
특정 값을 입력했을때 브라우저 화면에는 값이 나오지만 response에는 없을 경우
DOM-Based XSS라고 볼 수 있다.

Reflected XSS vs DOM-Based XSS

둘 다 동적페이지를 구성하는 과정에서 발생한다.
Reflected XSS는 서버 측에서 동적 페이지를 구성하는 환경에서 발생하며,
DOM-Based XSS는 클라이언트 측에서 사용자 입력 값을 통해 동적 페이지를 구성하는 환경에서 발생한다.

XSS 공격 대응방안

1. HTML Entity

<,',",>등의 문자를 HTML Entity 표현으로 치환한다.
예를 들어 < 를 &It; 로 치환하여 브라우저 화면에서는 < 로 보이지만 실제 태그로는 작동하지 않는다. 우회는 거의 불가능하다.

2. HttpOnly

세션 하이재킹 방지를 위해 HttpOnly 속성을 사용하여 클라이언트 측 스크립트가 쿠키에 접근하는 것을 막을 수 있다.

HTML Editor

HTML Editor에서는 HTML Entity를 적용할 수 없다.
HTMl Editor 기능을 삭제 할 수 없다면
1. 파라미터에서 HTML 특수문자들을 전부 HTML Entity로 치환.
2. 화이트 리스트 기반 필터링으로 img, a, h1, h2 등등 허용해줄 tag를 식별하고 다시 살린다.
3. 블랙 리스트 기반 필터링으로 살려준 tag내에 악의적인 Event Handler를 제거한다.

XSS가 위험한 이유

alert(1)만 출력하면 이것이 왜 위험한지 잘 모를 수 있다.
스크립트가 작동 된다는 것은 악성스크립트가 작동될 수 있다는 것이다.
예를 들어 쿠키 탈취, 키로거 등 악성스크립트가 삽입되어 피해가 발생할 수 있다.

참고자료
https://wit.nts-corp.com/2019/02/14/5522
https://berr-my.tistory.com/entry/XSS-%EA%B3%B5%EA%B2%A9
https://junhyunny.github.io/information/security/spring-mvc/stored-cross-site-scripting/

그림출처
Andrean Prabowo 제작 아이콘
Eucalyp 제작 아이콘
Icongeek26 제작 아이콘

0개의 댓글