Client-side Attack

Client-side Attack. 앞서 설명했듯이 서비스 사용자에 대한 공격이다.

 

공격자의 주 목적은 무엇일까?

:: 사용자로부터 본인을 식별하기 위한 정보, 즉 쿠키나 세션에 저장된 세션 아이디 정보를 탈취해 사용자 권한을 얻거나

사용자의 브라우저에서 자바스크립트 등을 실행하는 등의 특별한 행위를 수행해

사용자가 요청을 보낸 것처럼 하는 것이다.

 

 

그렇다면 클라이언트 사이드 취약점이 발생하는 이유는 무엇일까?

① 웹 브라우저는 Stateful한 상태를 유지하기 위해 모든 HTTP 요청에 쿠키를 함께 보낸다.

   (stateful : server side에 client와 server의 동작, 상태정보를 저장하는 형태)

:: 웹 브라우저는 HTTP 요청을 생성할 때 시작 주소(Referer)와 상관없이 대상 호스트가 발급한 쿠키를 삽입한다.

 

② 자바스크립트를 이용해 페이지 내의 요소들을 관리한다.

:: 외부 리소스를 불러오는 엘리먼트(iframe, img, video 등)를 자바스크립트로 관리하면 사용자의 동의없이 해당 내용을 읽거나 변조할 수 있게 된다.

 

이러한 공격을 막기 위해 Same Origin Policy(SOP) 정책이 탄생한다.

(*SOP : 서로 다른 오리진의 문서 또는 스크립트의 상호작용을 금한다)

(*오리진 : 프로토콜(protocol,scheme), 포트(port), 호스트(host)로 구성되며 구성요소가 모두 일치해야 같은 오리진이다)

 

일반적으로 SOP의 영향으로 서로 다른 리소스와 공유하지 못하지만 공유해야 하는 상황이 있을 수 있다.

따라서 SOP가 적용된 상태에서도 리소스를 공유하는 법인 Cross Origin Resource Sharing(CORS)가 등장한다.

(이는 나중에 따로 다뤄보기로 한다.)

 

---

이제 클라이언트 사이드 취약점을 알아보자

ⓐ Cross Site Scripting(XSS)

:: 공격자의 입력값이 크로스 사이트의 자바스크립트 일부로 웹 브라우저에서 실행되는 취약점이다.

:: 실행된 스크립트는 해당 사이트의 일부가 되어 SOP의 제약없이 사이트의 구조를 변경하거나, 임의의 HTTP 요청 등을 실행할 수 있다.

 

-- 성공적 공격을 위한 조건

   1. 입력 데이터에 대한 충분한 검증 과정이 없어야 한다.

   2. 서버의 응답 데이터가 웹 브라우저 내 페이지 출력 시 충분한 검증 과정이 없어야 한다.

 

-- 자바스크립트를 이용한 공격

    (ex; 화면 구성 바꾸기, 사용자 권한으로 정보 조회하기, 웹 브라우저 위치 바꾸기 등)

    :: 대표적 방법은 script 태그를 이용하는 방식 (script 태그 : 다른 프로그래밍 언어 연결시 사용하는 태그)

    공격자가 입력 데이터로 script 태그를 전송해 다른 사용자의 응답에 포함되면 공격자의 자바스크립트가 실행된다.

    :: on* 이벤트를 사용하는 방식

 

(1) Stored XSS

:: 악성 스크립트가 서버 내에 존재하는 데이터베이스 또는 파일형태로 저장되어 있다가

사용자가 이를 조회하는 순간 발생하는 형태

(ex; 게시판 조회)

 

(2) Reflected XSS 

:: 악성 스크립트가 사용자의 요청과 함께 전송되는 형태

:: 사용자가 요청한 데이터가 서버의 응답에 포함되어 HTML 등의 악성 스크립트가 그대로 출력된다.

(ex; 특정 링크 유도)

+ Click Jacking, Open Redirect 취약점과 연계되어 발생하는 경우도 있다.

 

-- 방어기술

ⓐ Server-side Mitigations(방어)

:: XSS를 유발할 수 있는 태그삽입 방지를 위해 서버 단에서 검증하는 방식

- 사용자의 입력값이 HTML 태그가 될 일이 없다면 특수문자를 HTML Entity Encoding을 이용해 태그로 인식되지 않도록 함

- 현재 IP 주소와 로그인했던 IP주소로 비교하는 방법 (요즘은 Wifi의 사용으로 동일 IP 검사가 아닌 동일 국가인지 탐지하는 것으로 변경)

 

ⓑ HTTPOnly Flag

:: 서버 측에서 응답 헤더에 Set-Cookie 헤더를 전송(Set-Cookie: session=sbdh1vjwvq; HttpOnly)해 자바스크립트로 해당 쿠키에 접근하는 것을 금지

- HTTPOnly로 설정한 쿠키는 document.cookie API를 통해 접근할 수 없다.

 

ⓒ Content Security Policy(CSP)

:: 응답 헤더(Content-Security-Policy: <지시어>; ...)나 meta 태그(<meta http-equiv="Content-Security-Policy" content="지시어")를 통해 선언 

:: 각각의 지시어를 적용하여 사이트에서 로드하는 리소스들의 출처를 제한

 

ⓓ X-XSS-Protection Header

:: 응답 헤더에 선언 X-XSS-Protection: <값>

:: 웹 브라우저에 내장된 XSS Filter의 활성화 여부를 판단

 

ⓑ Cross Site Request Forgery(CSRF 또는 XSRF)

:: 비정상적으로 사용자의 의도와 무관하게 HTTP 요청을 보내는 것(사용자 권한 이용). Forgery = '위조'

-- 기본

   : 웹 브라우저는 SOP에 위반되지 않는 모든 요청에 쿠키를 포함해 전송한다.

 

-- 공격자가 취할 수 있는 이득

   : 해당 세션 쿠키를 가진 사람만 사용할 수 있는 기능을 요청할 수 있다. 

   (ex; 금액 송금, 패스워드 변경)

 

-- 성공적 공격을 위한 조건

   1. 해당 웹 사이트가 쿠키를 이용한 인증방식을 사용해야 한다.

   2. 공격자가 사전에 알 수 없는 파라미터가 존재하면 안된다.

      (ex; 자동 입력 방지 문자, 기존 패스워드 등)

 

-- 방어기술

ⓐ 세션 쿠키 대신 커스텀 헤더를 사용하여 사용자 인증

:: 사용자 인증만을 위한 헤더를 추가 (e.g. Authorization)

 

ⓑ 공격자가 예측할 수 없는 파라미터 추가 및 검증

:: 같은 오리진에서만 접근 가능한 데이터 삽입 (CSRF Token)

:: CAPTCHA

:: 정상적 사용자만 알고있는 값 검증(ex; 현재 비밀번호)