4학년 1학기/네트워크 보안

15. Browser Security

howl_2019 2024. 6. 1. 15:04

개요

현 시대 웹에서 빠질 수 없는 요소인 브라우저에 대해 이해하고 어떻게 공격이 이루어지는지, 이에 대한 보호기법은 어떻게 구성할 수 있는지 학습한다.

Security Goals

안전한 브라우저는 일반적인 웹사이트에 방문하던 악성 웹사이트에 방문하던 피해를 받으면 안된다. 따라서 웹사이트로부터 디바이스의 정보(웹캠, 파일 등)가 빠져나가면 안되고, 다른 웹사이트에 대한 정보도 빠져나가면 안된다. 

Web Attack Model

Web을 이용한 공격에는 여러 방식이 있을 수 있다.

1. Malicious Website

Website 자체가 공격자에 의해 만들어져 접속하는 것으로 공격을 하게 되는 모델로 브라우저의 취약점을 이용하는 경우가 많다. DBD 공격이 여기에 해당한다.

2. Malicious External Resource

사용자가 사용하는 외부 자원에 공격자가 공격을 심어두는 것으로 외부 라이브러리나 API에 공격을 심는 행위가 여기에 해당한다.

3. Network Attacker

네트워크를 통한 공격으로 중간자 공격(MitM)이나 DDoS공격이 여기에 해당한다.

4. Malware Attacker

네트워크를 통해 공격자가 만든 바이러스, 웜 등을 배포하는 행위로 랜섬웨어나 웜이 여기에 해당한다.

HTTP Protocol

7계층 프로토콜로 서버의 자원을 요청할 때 사용하는 프로토콜이다. 이에 HTML, 이미지, 비디오를 주고 받을 수 있다. 특징으로는 요청과 응답이 있는 구조이고, 비상태(Stateless) 프로토콜이라는 점이다. 

이러한 자원 요청은 URL(Uniform Resource Location)이라는 경로(옵션)을 통해 요청할 수 있다.

HTTP요청은 2개 부분으로 나눌 수 있으며 각각 Header와 Body로 부른다. 그리고 이를 보낼 때는 3가지가 필요하다. Method(GET, POST, etc), Path(URL), Version(HTTP/1.1 etc) 이렇게고 Method에 따라 Body가 아예 없는 경우도 있다.

 

GET: 특정 URL에 자원을 얻는 요청으로 Body가 없다는 특징이 있다. 이러한 특징으로 데이터에 대한 모든 정보가 URL로 특정되기에 위험할 수 있다.(여기서 위험하다는 건 상대적인 것이고 위험해서 사용하면 안된다 이런 의미는 아님)

POST: Payload를 통해 정보를 생성하거나 수정하는 요청으로 위와 달리 Payload가 있다는 특징이 있다. 

 

이외에도 PUT, PATCH, DELETE가 있는데 해당 수업에서는 위 2개만 다룬다.

 

먼저 웹페이지가 열리는 것 자체가 브라우저가 GET 으로 자원을 요청하는 것이다. 여기서의 자원은 HTML, JS 등으로 이를 통해 페이지를 구성하고 코드를 돌린다. 여기서 Tag를 이용한 공격이 가능하다.

<img src="http://bank.com/image.jpg"></img>

위와 같은 HTML 파일이 요청으로 올 시 어떤 URL로 GET 요청을 보내든 bank.com으로 요청이 가는 것을 알 수 있다. 이는 사용자가 모르게 bank에 요청을 보낼 수 있다는 의미로 스캐닝 목적으로도 사용이 가능하고, 만약 사용자 cookie를 이용하게 된다면 추가적인 Spoofing이 가능해진다. 이는 꼭 GET에만 해당하지 않고 POST의 form에서도 충분히 가능하다.

JS(Java Script)

브라우저에서 실행된다는 특징을 가진 언어로 웹에서의 동적인 부분(Ajax, etc)에 대한 구현을 담당한다. 그리고 이는 HTML에 <script></script>를 통해 Embedding이 가능하다. 따라서 웹에 대한 악성코드는 거의 대부분 JS를 기반으로 만들어진다.

DOM

 

Document Object Model로 페이지를 구성하는 tree 구조의 객체이다. 따라서 페이지의 요소는 위 객체로 구성되어있다는 의미인데 중요한 점은 JS는 위 객체에도 접근이 가능하다. 따라서 JS를 이용하면 페이지의 값도 변경이 가능하다.

<script>
	document.getElementById('demo').innerHTML = Data()
</script>

위 코드가 그 예시이다.

Iframe

페이지 안에서 또 다른 페이지를 load하는 기술로 아예 분리된 탭으로 load하는 Frame과는 달리 탭 내의 특정 영역에 페이지를 load할 수 있다.

Cookie

이전에 말했다시피 HTTP는 Stateless protocol이다. 문제는 이렇게 될 시 session 값을 유지할 수 없기에 로그인을 예시로 든다면 페이지가 변경될 때 마다 로그인을 새로 해주어야 한다. 

따라서 위 문제를 해결하기 위해 서버는 Cookie를 생성하고 이를 클라이언트의 browser에 저장하여 이를 일종의 key로 이용한다.

Session Management: 로그인, 장바구니, 점수 등의 세션 상태를 유지할 수 있게 해준다.

Personalization: 사용자 추천, 사용자 테마 등 setting 값을 유지할 수 있게 해준다.

Tracking: 사용자 행동을 분석하여 이를 저장 및 활용할 수 있게 해준다.

 

이러한 쿠키는 HTTP 요청을 Client가 보내면 Server쪽에서 임의의 Cookie를 생성한 뒤 이를 응답에 실어서 보낸다. 그럼 Client의  Browser는 해당 Cookie를 저장한 뒤 다음 요청에 이를 실어서 보내 사용할 수 있다. 특징으로는 이 쿠키는 도메인에 따라 저장되고 쿠키가 필요 없는 상황에도 도메인이 동일하다면 Cookie를 실어서 요청을 보낸다. 이러한 점이 취약점으로 이용되기도 한다.

Cookie Reusing Attack

요청에 대한 도메인이 동일하다면 Cookie가 전송되기 때문에 아래와 같은 방식으로 Cookie를 악용할 수 있다.

<img src="https://bank.com/transfer?
	Account=X
   	&toAccount=Y
    	&amount=1234"></img>

위 HTML을 보면 bank 도메인에 transfer 경로에 돈을 전송하는 요청을 보내는 것을 확인할 수 있는데 위 HTML이 attacker.com 도메인의 페이지라 하더라도 bank에 대한 Cookie가 Browser에 set 되어있다면 위 요청에 대해 bank의 Cookie를 같이 전송하게 된다. 그러면 공격자의 의도대로 해당 페이지에 접속한 사용자는 자신도 모르는 사이에 bank.com/transfer에 자신의 Cookie와 함께 요청을 보내게 되어 돈이 빠져나갈 것이다. 이러한 점이 문제가 되기 때문에 이를 방지하기 위해 SOP라는 것을 도입하게 된다.

SOP

Same Origin Policy라는 의미로 다른 origin에 대한 content 격리가 그 목적이다. 이는 기밀성과 무결성을 유지하기 위한 것으로 다른 도메인으로부터 Cookie가 빠져나가거나 악용되는 것을 방지할 수 있다.

Origin

Origin은 특정 웹 리소스의 출처를 식별할 수 있는 요소로 URL의 일부를 말한다. 이는 3가지로 구성되는데

1. Protocol (https://, rtsp:// etc)

2. Host (www.example.com)

3. Port number (:8080, :443 etc)

따라서 이를 바탕으로 같은 origin과 다른 origin을 구분할 수 있어야 한다.

Same origin

http://kw.ac.kr 

http://kw.ac.kr:80 (80=http)

http://kw.ac.kr/cs (host가 동일하기 때문에 아래 경로는 달라도 ㄱㅊ) 

Diff origin

http://kw.ac.kr

http://www.kw.ac.kr (www.으로 host가 다름)

http://kw.ac.kr:8080 (port 다름)

https://kw.ac.kr (Protocol 다름)

 

이러한 origin은 1차적으로 먼저 Window(Frame)로 구분이 가능하다. 별개의 창을 가진 페이지는 일단 다른 Origin으로 본다. 따라서 각 창 및 탭은 서로 영향을 줄 수 없다. 여기서 영향이란 content를 읽거나 cookie를 쓰거나 탭의 변경을 탐지하는 행위등을 포함한다. 

추가적으로 iframe에도 해당되는데 Window(Tab)과 iframe이 동일한 Origin이 아니라면 Window에서 해당 iframe에 접근이 불가능하다. 이는 iframe의 Cookie도 사용이 불가능하다는 의미이다.

위 화면은 FireFox의 쿠키 설정 화면으로 잘 보면 Cross-site에 대해 Cookie를 격리한다는 부분이 있다. 

Problem of SOP

같은 사이트라도 이게 Origin이 다른 경우가 있다 ex) facebook.com, cdn.facebook.com 이런 경우는 iframe을 통해 해당 페이지를 구성하더라도 다른 Origin이다보니까 요청에 Cookie를 같이 보낼 수가 없는데 결국 편의성에 문제가 발생한다. 따라서 이를 해결하기 위해 Domain Relaxation을 적용하여 SOP에 대한 완화 정책을 설정할 수 있다. 

a.domain.com == domain.com

b.domain.com == domain.com

a.domain.com != com

a.domain.co.kr != co.kr

이런식이다. 위에서 TLD만 겹친다고 되지 않은 이유는 Public Suffix List(PSL)에 포함되기 때문으로 이는 특정한 도메인 이름이 TLD나 공용 접미사로 기능하는지 결정하는 목록으로 여기에는 쿠키 설정을 제한하는 것이 포함된다. 

Bypass

위 편의성에 대한 정책은 이를 우회할 수 있게 하였는데

<script>
	document.domain=attacker.com
</script>

위와 같이 domain field를 변조하여 SOP를 Bypass할 수 있게 한다. 물론 현재는 브라우저에서 이를 방어하고 있다.