[XSS 점검 자동화] 1장. XSS 수동 점검이....노가다!?

개요

웹 취약점 점검을 하다보면 가장 많이 발견되는 취약점 중 하나가 XSS 취약점이다. 해당 취약점은 사용자의 입력 값으로 구성되는 페이지에서 발견될 수 있기 때문에  사실상 모든 페이지에서 발견될 수 있다. 그러다보니 가장 손쉽게 찾을 수도 있지만 또 귀찮은 무한반복작업이 동반되기 마련이다. 때문에 놓치는 부분도 당연히 나온다.

 

기계처럼 파라미터가 존재하는 모든 페이지에서 입력 값 검증하고 있노라니 시간도 시간이고 재미도 감동도 없고 내가 과연 전문인력인가라는 현타가 오면서 대충대충 샘플링을 한다던가 집에 가고 싶어질 때가 너무 많았다.

 

우회를 하는 것은 경우에 따라 난이도가 있을 수 있으나, 공격 포인트를 찾는 것이 의외로 복잡하지 않은 반복작업이라면 자동화를 할 수 있지 않을까? 라는 생각이 문득 들었다. 개알못의 허세이다.

 

한번 해보고 안되면 말지 뭐. 시도하는게 불법은 아니니까.

 

XSS란?

XSS(Cross Site Scriptin)는 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다. 삽입된 악성 스크립트를 이용해 다양한 공격을 수행할 수 있다. 대표적으로는 세션 탈취, 피싱, CSRF(Cross-Site Request Forgery),  DBD(Drive by Download) 등의 공격으로 활용된다.

 

XSS는 취약점의 동작방식에 따라 크게 Reflected(반응형) XSS와 Stored(저장형) XSS로 분류할 수 있다. 일반적으로 DOM XSS까지 포함시켜 3가지로 분류하지만 이 글은 간단하게 XSS를 설명하기 위함이기 때문에 생략한다.

 

XSS 점검 방법

XSS는 기본적으로 웹에서 사용자 입력 값이 요청되었을 때, 서버의 응답에 해당 요청이 포함되면서 악성 스크립트를 포함할 수 있는지 여부를 본다. 기본적으로 웹 요청을 통해 스크립트 태그를 삽입한 후, 세션 탈취나 리다이렉트 등 실제 공격으로 활용가능한 함수의 사용여부까지 확인해야 한다.

 

하지만 웹 진단 실무에서는 가성비를 뽑아야 하고 고객에게 보여줄 수 있어야 하기 때문에 보통은 alert(1), confirm(1), prompt(1) 등 스크립트를 통해 임의의 메시지를 출력하는 함수를 동작시키는 것으로 취약 유무를 판단해준다. 

* 시간이 여유롭거나 고객이 원한다고 하면 실제 공격 시연까지 해준다. 나는 생각보다 그렇게 나쁜 진단러는 아니다.

 

대부분의 진단러가 비슷하게 점검할 것 같다. 반응형/저장형 XSS의 점검 방법은 크게 다르지 않다.

step1. request에 사용자 입력 값이 포함되는 파라미터가 존재한다면 'aaa' 값을 입력한다.

 

step2. response에 'aaa'라는 값이 포함되는지 확인한다.

        * 게시글 등록과 같은 저장형 XSS로 보인다면 해당 게시글에 값이 포함되어있는지 확인한다.

 

step3. 'aaa'라는 값이 포함된 response가 존재한다면 request로 다시 돌아가 특수문자("", <>, (), // 등)를 이용해 해당 값이 포함된 HTML 태그 또는 자바스크립트 구문을 탈출하여 악성 스크립트 삽입이 가능한지 테스트한다.

 

step4. 악성 스크립트 기본 구문이 동작하지 않는다면 적절한 우회방법을 테스트 한 후 최종적으로 alert() 구문을 동작시켜 취약 여부를 판단한다.

 

XSS 점검 노하우(초보자 한정)

개요에서 언급했다시피 웹 사이트 규모가 크거나(페이지 수가 많거나) request에 포함되는 파라미터가 많은 경우 많은 페이지에서 많은 파라미터에 대해 XSS 취약 여부를 테스트 해야한다. 하지만 그 작업이 쉽지 않기 때문에 샘플링하여 점검하는 방법을 택한다. 

 

3.1 타 페이지, 동일 파라미터 점검 생략

XSS를 조치할 때 일반적으로 GET, POST로 넘어오는 특정 파라미터 값을 필터링하는데 이 필터링이 모든 페이지에 모듈 형태로 들어갈 수 있고, 각 페이지별로 모듈이 따로 만들어질 수도 있다. 대부분은 전자의 케이스가 많지만 후자의 경우도 존재하긴 한다.(딱 한번 봤다.)

 

프로젝트 수행 여건 상 모든 페이지에 대해 입력 값을 검증하는게 쉽지 않기 때문에 전자의 케이스로 가정을 하고 파라미터명이 같다면 동일한 필터링이 적용된다고 판단한다. 동일 파라미터가 여러 페이지에서 활용되는 경우가 많기 때문에 이 샘플링 방식으로 XSS 취약점 점검에 대한 소요시간을 줄일 수 있다.

 

3.2 hidden 파라미터 공략

사용자 입력 값이 서버 응답으로 반환될 때 HTML 태그의 value 값이나 Javascript 변수로 반환된다. 이 중에서 특히 HTML 구문으로 반환되는 경우는 대부분 hidden type의 input 태그 value로 들어온다. 

 

메인페이지 또는 게시글 작성 등 기능이 명확하게 나뉘어 있는 페이지에는 기본적으로 hidden type으로 정의되어 있는 input 태그들이 많이 존재한다. 필자는 해당 페이지 응답에서 hidden으로 검색하여 나오는 태그들의 name을 뽑아내서 burp의 intruder 기능을 이용해 각 파라미터에 'aaa'를 입력하여 작업을 자동화한다.

 

해당 파라미터들이 어떠한 request에서 활용되는지 GET 요청인지, POST요청인지 모르기 때문에 GET에도 돌려보고 POST에도 돌려본다. 이 자동화 작업으로 생략되거나 놓치는 파라미터가 있을 수 있으나, 웹 사이트 규모가 큰 경우에는 꽤나 큰 도움을 받을 수 있다.

 

결론

여건 상 모든 입력 값에 대한 검증을 수행하는게 쉽지 않다는 핑계로 샘플링하여 작업을 진행하는 등 일을 대충하여 사장님과 고객들에게 미안한 마음도 있고 또 반복작업으로 시간을 의미없이 소비하는 느낌을 받는 고통받는 나날들을 더이상 보내고 싶지 않기에 자동화 도구를 만들어보겠다고 결심했다. 의미있는 시간이 되기를...