[기록일지] 📚 09주차 (XSS - Stored/Reflected)

XSS 란?

크로스 사이트 스크립팅(XSS)은 Cross Site Scripting의 약자로 간단히 말하면 '클라이언트 측 스크립트 삽입 공격'이다.

(줄여보면 CSS이지만 XSS인 이유는 이미 CSS라는 것이 존재하기 때문에 Cross와 일맥상통하는 X로서 대체한 것이다.)

크로스 사이트 스크립팅은 줄여서 '크사'라고 불리우는데 자세한 정의는 다음과 같다.

공격자가 실행시키고자하는 악성 스크립트를 페이지에 삽입하여 해당 페이지를 접근하는 이용자의 브라우저에서 스크립트가 실행되도록하는 공격이다.

이렇게 말하면 공격자가 서버의 페이지에 스크립트를 올려두었으니까? 서버를 공격하는 것 아닌가? 라고 생각할 수 있다. 그럴듯하게도 서버를 공격하는 것 같지만, 아니다.!!

중요한 것은 스크립트가 실행되는 위치라는 것이다.

XSS는 서버를 통해 삽입된 스크립트가 전달되는 것일 뿐 공격 대상이 서버가 아닌 클라이언트 측(피해자)의 브라우저에서 실행되는 것이기 때문에 '클라이언트 측 스크립트 공격' 이라는 것이다.

서버의 취약점이 아니라 클라이언트 측의 취약점이기 때문에 '피해자 = 이용자' 라는 사실을 잊으면 안된다.

(반면 SQL Injection은 서버측 공격이다.)

즉 XSS는 삽입한 스크립트가 클라이언트에 가게 하기 위한 것으로 '클라이언트 스크립트'이고 이용자의 브라우저에서 실행되는 스크립트를 말한다.

---

Server vs Client Script

Server Side Script : PHP, JSP, ASP
Client Side Script : HTML, CSS, Javascript

혹자는 HTML / CSS / JavaScript 에서 HTML은 스크립트가 아니고, 프로그래밍이 아니라고 말하기도 한다.

하지만 HTML 또한 클라이언트 측에서 실행되는 스크립트임에는 분명하다.

브라우저(Browser) 입장에서 HTML로 <input>을 작성하는 경우 (이를 해석하여) 화면에 입력란을 만들어주고
CSS로 color를 지정하는 경우 글자 색상을 변경해준다.

이와같이 여러가지 방식들을 통해 브라우저가 '읽고 해석하는 과정'을 거쳐 화면에 띄워주기 때문에 브라우저 입장에서는 HTML, CSS도 하나의 스크립트라 할 수 있다는 것이다.

---

XSS 컨셉

XSS는 스크립트(Script)를 삽입하는 공격이다.

그러므로 XSS 공격이 이루어지기 위해서는 공격자가 삽입한 스크립트(Script)가 요청(Request)을 통해 다른 용자에게 잘 전달(Response)되어야 하기 때문에 다음을 따져봐야한다.

1. 스크립트를 삽입할 수 있는지
2. 삽입한 스크립트가 응답(Response)에서 확인이 가능한지

그렇다면 어떻게?! How?! 스크립트를 삽입해야할까?

다음과 같은 여러가지 전략이 존재한다.

1. 서버에 저장
2. 서버에서 반사
3. 클라이언트 측에서 조립

이번에는 우선 '스크립트를 서버에 저장' 하는 전략과 '서버의 에코 기능을 이용'하는 전략을 알아볼 것이다.

 

Stored XSS

서버에 저장하는 전략으로 스크립트를 서버에 저장 한다고 해서 Stored XSS라고 하며, 이 사이트를 접속하는 사람들이 해당 페이로드를 가져가게 하는 것을 목표로 하는 전략이다.

취약점 Point

1. 스크립트를 삽입/저장하는 페이지
 ex) 회원가입, 게시판 글 작성(저장), 자기 소개 등록, 파일 업로드(파일 이름), 파일 업로드 (Script가 포함된 html 파일 저장)

2. 삽입된 스크립트가 로드되는 페이지
ex) 게시판 글 리스트, 게시판 글 읽기 · 수정 페이지, 마이페이지

위와 같이 데이터를 저장하는 곳에서 발생하게된다.

그렇다면 데이터를 저장하는 모든 곳에서는 크사(XSS)가 일어나는가? 그것은 아니다!

데이터가 저장되고, 출력! 되는 곳에서만 발생한다.

(취약점이 존재하는 곳이 예상 외의 의외의 곳일 수 있다.)

ex) 게시글 제목 작성 : 게시글 리스트가 아닌 팝업 메뉴의 공지사항에서 갑입된 스크립트가 실행될 수 있음

따라서 브라우저를 이용하는 것이 아니라 Burp Suite에서 확인해야한다.

서버 응답(Response)에 데이터(파라미터)가 찍혀서 나오는지를 확인하고, 거기에서 크사(XSS)가 가능한지 확인한다.

다음을 Burp Suite에서 확인 하면 크사를 생각해 볼 수 있다.

1. 요청에 파라미터가 출력되어 들어가는지 확인
2. 해당 데이터가 화면에 출력되는지 확인
3. 응답에서 출력되는 것을 확인

 

Stored XSS 삽입 과정

1. 작성한 데이터가 화면에 응답 되는 것을 확인한다.

입력 값에 대한 데이터가 응답에서 화면에 출력되는지를 확인하는 것이다.

2. 특수문자를 체크한다.

아무 문자나 넣는다고 스크립트로 인식하는 것이 아니다. 그래서 스크립트 삽입 공격을 위한 사전 확인이 필요한 특수 문자들이 존재한다.

다음의 4가지 HTML 특수 문자를 확인해줘야 한다.

< ' " >

< ' " > 를 저장하는 페이지에 넣어서 확인해본다.

파라미터 데이터 뒤에 넣어 확인하는 것으로, 어떤 특수문자를 사용할 수 있는지 확인하는 작업이다.

3. 스크립트를 삽입한다.

Javascript를 삽입하여 원하는 공격을 넣어준다.

HTML 의 <script> 태그를 이용한다.

<script> ____ </script>

스크립트 Tag을 안쓰고 javascript를 사용하는 방법도 있다.  (특수문자 ' / ' 를 체크하지 않는 이유)

4. 삽입한 스크립트가 응답상에 그대로 들어있는지 확인한다.

스크립트가 실행되어야 하기 때문에 스크립트(Script) 가 그대로 나오는 것이 아니라 문자의 형태로 전달되는 것은 의미가 없다.

---

Reflected XSS

서버에 스크립트를 저장하는 Stored XSS와 다르게 서버에 저장하지 않고 서버에서 반사되는 것(에코)을 이용하는 전략이 바로 Reflected XSS이다.

파라미터가 메아리처럼 응답에 그대로 박혀오는 경우에 생각할 수 있다.

취약점 Point

스크립트를 삽입하는 곳과 삽입된 스크립트가 응답되는 곳이 같은 경우
(서버에게 전달되는 파라미터, 데이터가 서버의 응답에 그대로 삽입되는 원리를 이용)

ex) 아이디 중복 체크, 검색 페이지, 기타 파라미터

ID 중복 체크
-> 내가 입력한 데이터에 관하여 알려주는 곳이다.
검색 페이지
-> 검색 데이터에 대한 결과를 보여준다.

위와 같이 내가 입력한 데이터에 대하여 반사적으로 결과를 보여주는 곳에서 Reflected XSS가 일어난다.

그러므로 Burp Suite에서 파라미터(Params)들을 잘 확인해야 한다.

모든 파라미터에 대하여 확인하는 것이 좋다.

요청에 입력한 값이 해당 응답에 바로 찍혀 나온다면 Reflected!!!! 를 의심해 볼 수 있다.

요청(Request)의 파라미터에 입력한 값이 응답(Response)에 그대로 나온다는 것을 인지해야한다.

Reflected는 무.조.건 같은 응답에 나온다.!!

반면 Stored XSS의 경우에는 요청에 입력한 값이 해당 응답이 아닌 다음(혹은 다른) 응답에 찍혀 나온다.

저장하는 곳, 출력되는 곳이 다를 수 있다는 것이다. 그래서 어느 응답에 찍혀 나오는지를 확인하고 이용한다.

---

POC 

여기서 중요한 것은 모의 해킹은 때리는 코드가 아니고, 취약점을 찾는 것이라는 것을 인지해야한다는 것이다.

그래서 우리는 POC : Proof Of Content '보여주기 용도로 작성하는 코드' 를 이용하여 "여기에 크사 취약점이 있어요!" 라는 것을 보여준다.

우리가 삽입한 클라이언트 측 코드가, 실제 이용자의 브라우저에서 실행된다는 것을 보여주는 것이 중요하다.

그래서 가장 많이 쓰는 것이 alert(1) 이다.

그 이유는 무엇일까? 다음과 같은 이유들이 있다.

(모의) 해커들이 alert(1)을 많이 쓰는 이유

1. alert(1)을 삽입함으로써 경고창이 뜨기 때문에 캡쳐해서 쓰기 좋다.
2. 보고서 쓰는 것이 편해지기 때문이다.

그래서인가 XSS를 막아야하는데 alert 를 필터링하여 막아놓는 경우가 있다.

(모의) 해커들이 하도 써서 그런지.... 증명용 코드이기에... 필터링할 이유가 없지만.. 그래도 필터링해두는 경우가 있다.

하.지.만 우리에게는 자매품이 존재한다.

prompt : 글자를 입력하고 데이터를 주고 받는 것
confirm : 예/아니오 를 확인하는 것
console.log : 개발자 화면에서 보여주어 모양새가 별로긴하지만 이런것도 있음

위의 것들은 예시에 불과하고 더 다양한 많은 것들이 존재한다.

즉 크사 취약점을 보여주기 위해 많이 사용되는 것들은 다음과 같다는 것이다.

alert / prompt / confirm / console.log

 

생각할 점

넣어봤는데 중간에 잘린다면?

"아... 글자 수 제한이 있구나." 를 생각한다.

글자 수 때문에 ' or  " 에 의해서 잘려서 뒷부분이 먹통이되는 경우가 있으니 잘 살펴봐야한다.

뒷 글자들이 다 깨져버리게 된다는 것이다.

(꺾쇠 ( < ) 가 망가져서 사이트 자체가 망가지게 되는 경우가 있으니 조심해야 한다.)

 

스크립트 삽입에 관하여...

1.요청에서 스크립트를 넣어서 보낸다.
2.다음 응답에서 스크립트가 잘 보내졌음을 확인한다.
3.브라우저에서 실제로 실행되는지 확인한다.

클라이언트 측 스크립트를 잘 작성하는 것이 중요하다.

즉 Javascript를 얼마나 잘 다루냐가 관건이라는 것이다.(그러니 추가적으로 공부하자...)

 

사전 확인의 중요성

사용가능한 특수문자 < ' " >  를 먼저 체크하는 이유는 무엇일까?

미리 체크하지 않으면 나중에 하나하나 돌아가면서 체크해봐야 하기 때문이다.

또한 필터링의 가능성을 염두하고 많이 사용되는 것들에 대하여 미리 체크하는 것도 필요하다.

<script>
<img>
alert

많이 사용되어 막아둘만한 것들을 미리미리 체크해둬야한다.

확실히 되는 것을 체크하고, 조금씩 키워나가는 방법이 디버깅이 역으로 쉬워진다는 사실을 잊지말자!

결국 모든 코드/ 웹 개발 등의 방식과 동일하다.

조금씩, 조금씩 기능을 구현하고 돌아가는 것을 확인하고, 다시 기능을 구현하고 돌아가는 것을 확인하는 작업을 반복하는 것이 좋다.

이렇게 안하고 다 쓰고(작성하고) 안된다면?!

어디가 문제인지 찾는 것이 막막하다. 하나하나 체크하면서 가는 것이 신상에 좋다.

하나 하나 체크하는 것이 귀찮고, 시간이 더 걸릴것 같지만, 나중에 대참사가 일어날 수 있는 가능성을 생각한다면 오히려 시간이 덜 걸리는 방식일 수 있다.

'python으로 payload를 짜는 경우에는 print()로 데이터를 찍어보면서 필터링을 체크하고 실행하도록 하자.'

---

XSS의 위험성(과정)

그래서 XSS는 왜 위험한가?

XSS의 공격 시나리오

HTML, CSS 삽입
-> 피싱 공격 유도 가능

JavaScript 삽입
-> 세션 ID 탈취, 피싱 사이트 리디렉션, 키로거 등.

 

Stored XSS

1. ex)게시판 글 작성
2. 그 게시글을 읽는 사람들에게 스크립트 전달
 (스크립트가 들어 있는 응답을 이용자가 요청하게 되는 것)
3. 삽입되어 있는 스크립트가 실행됨

위험하다는 것을 알겠다.

그런데? Reflected XSS는?

 

Reflected XSS

Reflected의 경우에는 다른 사람의 컴퓨터가 아닌 내 컴퓨터에서 동작한 것이다...?!

그러므로 다른 전략을 세워야한다.

링크를 클릭하게 하는 것이다. '링크 전달 공격'

1. 요청의 파라미터가 GET 방식을 이용하여 응답에 파라미터가 포함되는 곳을 찾음
2. 파라미터 부분 스크립트를 삽입
3. 해당 URL을 클릭하도록 유도(스크립트가 들어가 있는 요청을 보냄)
4. 요청한 스크립트가 실행됨

http://~~/?<script>attack</script> 를 클릭하도록하여 피해자의 컴퓨터에서 실행되게 하는 것이다.

(이용자가 스크립트가 삽입된 요청을 보내도록 유도하는 것이다.)

스크립트가 삽입된 요청을 보내는 주체가 공격자가 아닌 이용자가 되는 것이다.

그래서 Reflected의 경우 사회공학기법과 같이 활용된다.

아는 사람인 척(혹은 실제 아는 사람에게 악의를 가지고) 링크를 클릭하게 유도한다.

공격자(지인) : 이거 클릭해봐! (링크 전달)
이용자 : 그래 (링크 클릭)

 

GET Method

링크를 전달해야 하기 때문에 페이로드가 GET 방식(Method) 이여야한다.

링크를 클릭하여 공격을 유발시킬 것이기 때문에 취약점이 일어나는 곳이 POST Method 였다면? 취약점이 아니다.

(POST Method에서는 공격으로 활용될 여지가 전혀 없다.)

하지만 Burp Suite에서 Change Request Method를 이용하여 POST 를 GET 방식으로 바꿔주었을 때도 정상적으로 동작된다면? 취약점으로 판단이 가능하다.

즉 GET 방식으로 바꿔주었음에도 동작된다면 취약점으로 판단하고 이어나가고, GET 방식으로 변환이 먹히지 않는 곳(바꿔 주었을 때 동작이 제대로 되지 않는 경우)은 넘긴다.

---

Stored vs Reflected

'Stored XSS 의 경우 광역기'라고 할 수 있다.

서버에 스크립트를 저장해둠으로써 해당 페이지에 접근하는 모든 이용자에게 스크립트가 실행되도록 하는 넓은 공격 범위를 가지고 있다는 것이다.

단점으로는 서버에 기록이 남기 때문에, 흔적이 남는다는 것을 들 수 있다.

반면 'Reflected XSS의 경우 타켓팅'이라고 할 수 있다.

링크를 클릭하는 이용자만 스크립트의 대상자가 되어 공격 범위가 좁다는 것이다.

링크를 클릭하게 해야한다는 단점이 있지만, 흔적이 남지 않고 클릭만 하도록 한다면 쥐도 새도 모르게 공격이된다는 장점이 있다.

XSS의 경우 찾으려고 작정하면 찾을 수 있을 정도로 매우 많이 나오는 취약점이다. 왠만하면 나온다는 것이다.

그래서 모의 해킹할 때 취약점이 안나오면 어떻게 하나요? 라는 질문에

우리들의 친구 크사! 가 있다고 해도 무방하다는 것이다.

이런 이유에서 버그 바운티(Bug Bounty)에서도 XSS는 너무 많이 발생하기 때문에 돈을 잘 쳐주지 않는다.

하지만 Stored XSS의 경우는 예외이다. 광역기 이기 때문에 위험성이 더 높기 때문이다.

 

---

질문 환영, 수정 및 보완에 대한 지적 환영