[2020.03.31] Dreamhack 개념정리 - Client-side Basic

1. Client-side Basic

Client-side 취약점의 주목적

공격자는 사용자로부터 본인을 식별하기 위한 사용자 정보, 즉 쿠키나 쿠키에 저장된 세션 아이디를 탈취해 사용자 권한을 얻거나, 사용자의 브라우저에서 자바스크립트를 실행하거나 특별한 행위를 수행하도록 하여 사용자가 보낸 것처럼 요청을 전송하는 것이 클라이언트 사이드 취약점의 주 목적

​

취약점이 발생할 수 있는 이유

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

※ stateful: client의 이전 상태를 기록하고 있는 것

 

> 서로 다른 사이트인 dreamhack.io와 theori.io에서 dreamhack.io/resource1에 요청을 보내지만, 같은 쿠키가 함께 보내지는 것을 확인할 수 있다.(Referer는 시작주소를 말한다)

> 웹 브라우저는 어디에서 요청을 하느냐와 상관없이 도착 주소 즉, 대상 호스트가 발급한 쿠키를 삽입

ex. A와 B가 네이버에 접속 시 네이버가 발급한 같은 쿠키 삽입

 

● Same Origin Policy(SOP)

: 서로 다른 오리진의 문서 또는 스크립들의 상호 작용을 제한하기 위함

> 웹 브라우저를 통해 대상 호스트에 요청 시 쿠키도 함께 전송이 되기 때문에 외부 리소스를 불러오는 엘리먼트들(img, video, iframe)을 자바스크립트로 관리할 수 있다면 사용자의 동의 없이 해당 내용을 읽거나 변조우려 존재

> 이와 같은 공격으로 부터 웹 브라우저가 사용자를 보호하기 위해 만든 정책이 'SOP'

- 오리진 의 구성

1) 프로토콜

2) 포트

3) 호스트

이 세가지 구성요소가 모두 일치해야 동일한 오리진이다. 이해를 돕기 위해 밑의 예시를 보자.

https://same-origin.com/frame.html과 비교했을 때 모두 다른 오리진을 띄고 있음을 확인할 수 있다.

이 경우 웹 브라우저가 사용자를 보호하기 위해 다른 오리진의 문서, 스크립트의 내용을 읽지 못하게 한다.

 

Dreamhack.io에서 페이스북으로의 요청 블락

● Cross Origin Resource Sharing(CORS) 헤더 사용

일반적으로는 SOP 영향으로 다른 오리진과 리소스 공유 불가

But, 개발/운영 등의 목적으로 다른 오리진들과 리소스를 공유해야하는 상황 발생

​

<SOP가 적용된 상태에서도 리소스 공유방법>

> postMessage: 메시지를 주고받기 위한 이벤트 핸들러를 이용해 리소스를 공유

> JSONP: 스크립트 태그를 통해 다른 오리진의 리소스를 요청하고, 응답 데이터를 현재 오리진의 Callback 함수에서 다루는 방식을 통해 리소스를 공유

> Cross Origin Resource Sharing: 다른 오리진이 허용하는 설정 등을 HTTP 헤더를 통해 확인 한 후 허용하는 요청을 보내 리소스를 공유하는 방식(단, 이 방식의 경우 두 오리진의 프로토콜이 http/https로 다를 때는 허용하지 않을 수 있음)

​

2. Cross Site Scripting

Cross Site Scripting(XSS)란, 서버의 응답에 공격자가 삽입된 악성 스크립트가 실행되는 취약점

> 임의의 악성 스크립트를 실행해 웹 사이트의 사용자 쿠키 또는 세션을 탈취해 사용자 권한 얻거나, 페이지 변조 등 의 공격을 가할 수 있음

> 악성 스크립트란, 브라우저가 실행할 수 있는 웹 리소스, HTML/JS 등이 존재

​

<XSS 공격 성공 조건>

1) 입력데이터에 대한 충분한 검증이 없어야 한다.(악성 스크립트가 삽입될 수 있도록)

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

​

<공격 예시>

공격자의 악성 스크립트가 포함된 게시글이 검증이 이루어지지 않은 채 웹 서버에 업로드 되고 다른 사용자가 게시글을 조회하는 순간 공격자의 악성 스크립트가 사용자의 웹 브라우저에서 실행

​

<종류>_(악성 스크립트가 전달되는 방식에 따라 분류)

1) Stored XSS: 악성 스크립트가 서버 내에 존재하는 데이터베이스 또는 파일 등의 형태로 저장되어 있다가 사용자가 저장된 악성 스크립트를 조회하는 순간 발생하는 형태의 XSS

ex) 게시판 서비스에서 작성된 게시물을 확인하는 과정에서 악성 스크립트가 포함된 게시물을 조회할 때 악성 스크립트가 실행되는 공격 방식

dreamhack에서 강의안에서 게시글에 script구문 입력 결과

2) Reflected XSS: 사용자의 요청 데이터가 서버의 응답에 포함되는 과정에서 HTML 등의 악성 스크립트가 그대로 출력되어 발생하는 형태,요청 데이터에 의해 취약점이 발생하기 때문에, 변조된 데이터가 사용자의 요청으로 전송되는 형태를 유도(유도 방식 Click Jacking, Open Redirect)

ex) 게시판 서비스에서 작성된 게시물들을 조회하는 과정에서 조회하기 위해 입력한 데이터에 의해 발생하는 방식

-> 악성 스크립트의 전달 방식의 차이일 뿐 악성 스크립트를 실행한다는 취약점 원인은 동일​

​

● XSS with Javascript

- Javascript(자바스크립트)는 사용자의 웹 브라우저에서 화면을 동적으로 보여줄 수 있도록 자동으로 버튼을 누르거나 화면 구성을 바꾸는 등의 작업을 할 때 많이 사용

- 사용자의 권한으로 정보를 조회하거나 변경하는 등의 요청을 주고 응답받는 것도 가능

- 웹 브라우저에서 출력되어지는 페이지의 내용을 조작하거나, 웹 브라우저의 위치를 공격자가 원하는 주소로 변경 가능

​

<자바스크립트 실행 방법>

> 공격자가 입력 데이터로 script 태그를 전송해 다른 사용자의 응답에 포함시키는 방법

> on* 이벤트 사용

 

XSS 취약점 방어기술

● Server-side Mitigations

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

HTML 태그가 입력될 일이 없다면, 특수문자를 HTML Entity Encoding을 이용해 태그로써 인식이 안되도록 수정

HTML 태그형태 지원이 필요하다면, "화이트리스트 필터링" 필요

* 화이트리스트 필터링이란? 허용해도 안전한 일부 태그, 속성을 제외한 모든 값을 필터링 하는 것

※ 유의할 점

요청의 URI Query 값이나 POST Body 값만 필터링 할 것이 아니라 User-Agent, Referer와 같은 헤더도 모두 포함하여 사용자로부터 온 값에 모두 적용해야함

HTML 필터링 라이브러리: Mozilla 사 Bleach

https://github.com/mozilla/bleach

 

- 사용자 로그인 시 세션에 로그인한 IP주소 함께 저장 후 접속할 때마다 비교

BUT, 오늘날 접속하는WIFI가 바뀔 때마다 IP주소가 바뀌기 때문에 '접속한 국가'가 변경된 경우를 탐지하는 형태로 변경

​

● HTTPOnly Flag

HTTPOnly 플래그는 서버 측에서 응답 헤더에 Set-Cookie 헤더를 전송해 쿠키를 생성할 때 옵션으로 설정 가능하며 자바스크립트에서 해당 쿠키에 접근 하는 것을 금지(세션쿠키 설정 시 추천)

​

● Content Security Policy(CSP)

CSP는 응답 헤더나 meta 태그를 통해 아래와 같이 선언해서 사용할 수 있으며, 각각의 지시어를 적용하여 사이트에서 로드하는 리소스들의 출처를 제한할 수 있음

​

● X-XSS-Protection Header

- 선언 방식

> 해당 정책은 웹 브라우저에 내장된 XSS Filter를 활성화할 것인지를 설정

> XSS Filter는 웹 브라우저에서 전송된 Request 값이 XSS 공격 코드와 유사하게 생겼고, Response에 해당 공격 코드가 포함되었을 경우에 XSS 공격이 수행되었다고 판단하여 XSS 공격이 발생했음을 유저에게 알리고 차단

> Reflected XSS 공격을 막는 데에 적합한 방법

<사용법>

0 : XSS Filter를 사용하지 않음

1 : 브라우저 기본 값, XSS 공격이 감지되면 해당 부분만 제거 뒤 페이지 결과를 화면에 출력

(mode=block일 경우 XSS 공격이 감지되면 페이지 전체의 렌더링을 중단하며, report를 선언할 경우에 XSS 공격이 감지된 사실을 미리 설정된 주소에 신고하여 운영자가 대처하기 쉽도록 도와줄 수 있음)

​

3. Cross Site Request Forgery(CSRF)

: 비정상적으로 사용자의 의도와 무관하게 다른 사이트에 HTTP요청을 보내는 것

- CSRF 공격

출처: https://swk3169.tistory.com/24

1) 공격자는 게시판에 관리자가 관심가질 만한 제목의 글을 게시(이 글에는 CSRF스크립트 포함) 2) 관리자가 CSRF 스크립트가 포함된 해당 게시물을 확인한다. 3) 관리자 권한으로 공격자가 원하는 CSRF 스크립트 요청 발생한다. 4) 공격자가 원하는 CSRF 스크립트 결과가 발생하여 피해 발생

공격자가 얻을 수 있는 이득: 해당 세션 쿠키를 가진 사람만 사용할 수 있는 기능을 요청할 수 있다는 것(즉, 희생자 권한 획득)

EX) 공격자에게 임의 금액을 송금하게 만들어 금전적 이득을 얻음

 

<공격방식>

- 사용자의 패스워드를 공격자가 임의로 설정한 값으로 변경해 계정 탈취

- 관리자 권한을 가진 사용자를 공격해 공지항 작성하여 혼란 야기

* 실제로 옥션 해킹 사고도 해당 공격을 사용(해커가 옥션 운영자에게 CSRF 코드가 포함된 이메일을 보내 관리자 권한 획득)

​

<CSRF 공격 성공요건>

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

2) 공격자가 사전에 알 수 없는 파라미터가 존재해서는 안됨(ex. 자동입력 방지 문자)

​

<CSRF 공격을 막기 위한 방법>

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

> 사용자 인증만을 위한 헤더 추가

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

> Same Origin에서만 접근 가능한 데이터 삽입

> 정상적인 사용자만 아는 기존의 값을 검증(ex.현재 비밀번호)

​

● SameSite Cookie

다만, 위의 방법은 서버 사이드에서 추가적인 검증을 통해 방어를 하기 때문에 오버헤드가 어쩔 수 없이 발생

: 크로스사이트에서 출발한 요청에 제한적으로 쿠키를 포함시키게 하는 옵션

: Strict(모든 크로스 사이트에서 출발한 요청에 해당 쿠키 삽입x), Lax(Link, Prerender, Form GET을 제외한 요청에는 삽입x), Normal(모든 요청에 삽입) 값을 설정할 수 있음

"크롬 브라우저는 2020년부터 개발자가 강제로 SameSite=None; Secure; 을 넣지 않는 이상 웹 브라우저는 모든 쿠키에 SameSite=Lax를 강제"

​

4. Open Redirect

Redirect란? 사용자의 location을 이동시키기 위해 사용하는 기능 中 하나

이 때 이동하는 주소가 공격자에 의해 변경될 경우 발생하는 취약점이 "Open Redirect" 취약점

​

<Open Redirect 취약점>

- 사용자가 접속한 도메인 사이트에 대한 신뢰를 무너뜨릴 수 있음

- 이를 통해 피싱사이트로 접속 유도 or 다른 취약점과 연계 공격 가능

​

<Open Redirect 공격 방법>

- 리다이렉트가 발생하는 경로에서 공격자의 입력 값에 의해 리다이렉트 되는 주소가 변경 될 경우, 해당 경로와 공격자의 값이 함께 전달되도록 사용자를 유도하여 리다이렉트가 실행되도록 하는 방법

​

<방어방법>

- 리다이렉트 기능 구현시 이동을 혀용할 주소들에 대해서만 이동시키는 방법

- 사용자의 입력 값으로 리다이렉트 되는 기능을 사용해야 하는 경우 서버에서 해당 링크에 대한 검증을 거친 후 사용자에게 배포하거나, 외부 링크로 이동하는 것을 사용자가 알도록 하는 방법

5. Click Jacking

- Click Jacking(클릭 재킹)은 웹 브라우저 화면에 출력되는 내용에 HTML, CSS, JS 등과 같이 화면 출력에 영향을 미치는 요소들을 이용하여 사용자의 눈을 속여 사용자의 클릭을 유도하는 공격 방법

- 외부 페이지 리소스를 불러올 수 있는 태그 엘리먼트(<frame>, <iframe>, <object>, <embed>, <applet>)를 사용

​

<공격 방법>

클릭 유도하는 페이지 구성 -> 페이지 위에 iframe 등의 태그로 누르게 할 페이지 로드 -> CSS의 opacity(투명도 조정) 이용해 사용자의 눈에 보이지 않도록 숨기는 방법

​

<방어 방법>

1) X-Frame-Options

- 부모 페이지의 URL 제한하는 방식

- HTTP 응답 헤더를 통해 DENY/SAMEORIGIN 두개의 값으로 설정

값	내용
DENY	부모페이지 URL 상관없이 모두 차단
SAMEORIGIN	부모 페이지 URL이 Same Origin이라면 허용

2) frame-ancestors

- 부모 페이지의 URL 제한하는 방식

- Content Security Policy(CSP)의 frame-ancestors 지시어를 통해 값을 설정

- frame-ancestors 지시어는 CSP를 HTTP 응답 헤더를 통해 설정해야 하며 <meta> 태그로는 설정할 수 없음

값	내용
'none'	X-Frame-Options DENY와 동일
'self'	X-Frame-Options SAMEORIGIN과 동일
http://, https://	scheme이 같으면 모두 허용
*.dreamhack.io, dreamhack.io, https://dreamhack.io	host나 scheme+host가 같으면 모두 허용, 와일드카드(*)를 사용할 수 있음.

예시)

Content-Security-Policy: frame-ancestors http://dreamhack.io *.google.com https://

> http://dreamhack.io와 google.com의 모든 서브도메인 그리고 https:// scheme을 모두 허용

​

"X-Frame-Options vs CSP frame-ancestors" W3C에 따르면 X-Frame-Options 은 최상위 parent의 URL을, frame-ancestors은 모든 parent의 URL들을 검사해야 한다고 명시 하지만, 대부분의 브라우저에서는 호환성과 보안 문제로 모든 parent URL들을 검사하지만 X-Frame-Options보다는 최신 기술인 CSP frame-ancestors를 사용하는 것을 권고

 

 

※ 해당 글의 모든 사진과 내용의 출처는 Dreamhack.io 에 있습니다 ※

해커들의 놀이터, DreamHack