[DVWA] CSP bypass

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

CSP 란

• Content Security Policy 의 약자로 Browers 에서 XSS  같은 코드 인젝션 으로 부터 보호하기위해 도입되었으며 웹 어플리케이션에서 콘텐츠 소스( javascript, images 등) 를 허용하는 선언적 메커니즘 입니다. 몇가지 지시문을 통해 코드가 실행될수 있는 콘텐츠를 지정하고 javascript를 인라인으로 실행하거나 신뢰하고 있는 어떠한 도메인의 js파일을 로드할수도 있습니다.

<옵션>
none : 어떠한 것도 허용 안함
self : 현재 출처에서만 허용 / 하위도메인 허용X
unsafe-inline nonce값 : nonce 속성값이 헤더값과 일치하면 <script> 또는 <style> 태그 실행
unsafe-eval : eval 같은 text - javascript 메커니즘 허용

<사용법>
default-src 'self' : 동일한 출처에서만 모든 것을 허용
script-src 'self'www.google-analytics.com ajax.googleapis.com; : Google 웹 로그 분석, Google AJAX CDN 및 동일한 출처 허용

 

① Low

(사진 1) 대상 폼

(사진 1) 하위 도메인의 웹 사이트 스크립트를 불러올수있는 폼이 있습니다. 해당 출처에서 허용하는 하위도메인을 확인하기 위해서는 개발자도구(F12) 또는 페이지의 소스를 확인하여 알수 있습니다.

(사진 2) Low 소스코드

(사진 2) https://pastebin.com/raw/R570EE00 이라는 하위 도메인을 허용하고 있는것을 알수 있습니다. 만약 약 공격자가 신뢰할수 있는 웹사이트를 확인하고 악성코드를 주입시켜두면 해당 주소를 include 할때 악의적인 스크립트가 실행될것입니다.

 

(사진 3) 하위도메인의 스크립트 불러오기

pastebin.com 에는 alert("pastebin") 이라는 내용을 담고 있습니다. 해당 하위도메인을 입력하면 pastebin 이라는 사이트에 내장된 javascript 가 실행된느것을 알수있습니다.

 

② Medium

(사진 4) Medium 소스코드

Low 단계와 다르게 POST 메소드를 사용하며 inline-javascript 를 금지하기위해 unsafe-inline 에 " nonce " 값을 설정해뒀습니다. 하지만 X-XSS-Protection : 0 즉 XSS 공격감지기능을 비활성화 시켜둔 상태임을 알수 있습니다.

Request 헤더에서 TmV2ZXIgZ29pbmcgdG8gZ2l2ZSB5b3UgdXA=" 으로된 inline 값은 허용하기 떄문에 속성과 헤더값을 같게 맞춰준뒤 뒤에 악의적인 스크립트 코드만 붙여 공격할 수가 있습니다.

 

(사진 5) javawcript 실행

-Before-
<script nonce="TmV2ZXIgZ29pbmcgdG8gZ2l2ZSB5b3UgdXA="악의적인코드삽입

-After-
<script nonce="TmV2ZXIgZ29pbmcgdG8gZ2l2ZSB5b3UgdXA=">alert("1");</script>

상위의 구문을 참고하여 nonce 속성 값과 헤더값이 일치하면 script 코드가 실행된다는점을 이용하여 해당 갑뒤에 악의적인스크립트 코드를 상비해주면 됩니다. 

 

③ High

 

(사진 6) High 소스코드

소스를 보면 POST 메소드를 이용하고 있으며 전 단계에서와는 다르게 데이터를 입력하는 형태가 아닌 Solve the sum 이라는 input type 이 button 형식을 통해 간단한 수식을 계산하는 코드가 보입니다. 상단에 script-src 'self';" 라는 옵션을 통해 현재 출처의 스크립트만 허용시키고 있습니다. 즉 High 단계에서는 외부나 inline 스크립트를 사용할수 없습니다.

(사진 7) 대상 폼

(사진 7) Solve the sum 버튼을 클릭하기전에 웹 프록시도구를 통해 매개변수 값을 확인해보도록 하겠습니다.

(사진 8) 프록시 도구로 잡은 모습

(사진 8) jsonp.php 는 입력된 데이터를 URL 정보에 붙여서 정보를 전달하는 GET 방식을 사용하고 있습니다. callback 이라는 매개변수에  아무런 검증을 하지 않는다면 solveSum 을 제거하고 악의적인 스크립트를 삽입하여 공격이 가능합니다.

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

-Befor-
callback=solveSum

-After-
callback=alert(document.cookie)

상위의 구문을 통해 악의적인 스크립트가 포함된 악성 URL 을 사용자들에게 전달하면 클릭한 사용자의 로그인 정보 인 쿠키값을 추출 할수가 있게됩니다.

 

(사진 10) 쿠키값 추출

 

◆ 대응방안

 

(사진 11) Impossible 소스코드

(사진 11) 을 보시면 JSON 은 그대로 사용하고 있지만 취약한 매개변수인 callback 변수는 사용을 안하고 있습니다. 콘텐츠 보안 정책이라고 불리는 CSP 를 사용할떄는 옵션을 잘 숙지해야하며 JSONP 보단 CORS 사용하는것이 보안상 안전합니다.

CORS는 크로스도메인을 해결하는 웹표준이며 허용하고자 하는 도메인에 정규표현식으로 표현이 가능하지만 JSONP의 경우 CORS가 활성화되기전의 데이터 요청방법인 GET 방식의 메소드만 지원하고

javascript 가 서로 다른 도메인에 대한 요청을 제한하는데 이러한 정책을 SOP(Same-Orgin Policy) 라고 합니다. SOP 정책으로 인해 생기는 이슈를 Cross-Domain issue 라고하는데 JSONP 는 html 문서의 script 태그로 다른 도메인을 요청 할 시 SOP 정책이 적용되지 않기 때문에 권장하는 편은 아닙니다.