Embed Size (px)
Citation preview
Ⅰ.�개요
1.�배경� ······································································································· � 3
2.�목적� ······································································································· � 4
3.�요약� ······································································································· � 4
4.�적용환경� ································································································· � 5
5.�활용대상� ································································································· � 5
6.�문서의�한계� ··························································································· � 5
Ⅱ.�웹�호환성
1.�보안� ····································································································· � 10
2.�인증� ····································································································· � 26
3.�전자결제� ······························································································ � 47
4.�멀티미디어� ··························································································· � 61
5.�그래픽� ·································································································· � 72
6.�전자문서� ······························································································ � 88
7.�파일처리� ······························································································ � 96
8.�게임� ····································································································· � 99
9.�시스템�정보�확인�및� PC제어� ··························································· � 102
Ⅲ.�멀티�운영체제�및�브라우저�정책
1.�멀티�운영체제�지원�정책� ·································································· � 111
2.�브라우저�서비스�개발�정책� ······························································ � 113
Ⅳ.�멀티�환경�지원�방안
1.�멀티�브라우저�지원�방안� ·································································· � 119
2.�멀티�스크린�지원�방안� ····································································· � 126
Ⅴ.� NPAPI� 대체기술
1.� NPAPI�대체기술�개요� ······································································· � 153
2.� NPAPI�국내�사용�현황�및�분류� ······················································· � 156
3.� NPAPI�대체�기술� ·············································································· � 158
4.�주요�기능별�대체�기술�적용�방안� ···················································· � 166
5.� NPAPI�전환�적용�사례� ····································································· � 171
6.�비표준�대체기술,�실행파일�보안�이슈� ·············································· � 172
Ⅵ.� HTML5
1.� HTML5�표준�개요� ············································································ � 177
2.� HTML5�신규�기능별�보안�이슈� ······················································· � 178
3.� HTML5�브라우저�수용도� ·································································· � 192
4.� HTML5�글로벌�동향�분석� ································································ � 208
Ⅶ.�부록
1.�용어집� ······························································································· � 225
2.�약어집� ······························································································· � 227
3.�참고자료�및�인용� ·············································································· � 228
<표� 2-1>�제거�API�및�대체�기능� ·································································· � 22
<표� 2-2>�주요�인증방법� ················································································ � 27
<표� 2-3>�브라우저별�웹�암호�API� ································································ � 33
<표� 2-4>�해킹�및�금융사기�주요�기법� ·························································· � 43
<표� 2-5>�대체�인증�방식� ··············································································· � 44
<표� 2-6>�국내�간편�결제�현황� ······································································ � 49
<표� 2-7>�해외�간편�결제�현황� ······································································ � 50
<표� 2-8>�주요�인증방법� ················································································ � 51
<표� 2-9>�결제서비스�제공�주체별�분류� ························································ � 52
<표� 2-10>�플랫폼�기반�분류� ········································································· � 53
<표� 2-11>�해외�신용카드� ·············································································· � 55
<표� 2-12>�결제단계별�플러그인�사용요소�및�개선방안� ······························· � 58
<표� 2-13>� <video>�요소�속성� ······································································ � 62
<표� 2-14>� <video>�요소의�재생�관련�속성,�자바스크립트�API� ·················· � 63
<표� 2-15>�브라우저�제조사별�지원�코덱,� DRM� ·········································· � 64
<표� 2-16>� <audio>�요소�속성� ······································································ � 66
<표� 2-17>� ActiveX의�그래픽�기능을�대체할�수�있는�웹�기술� ···················· � 73
<표� 2-18>� Canvas와� SVG의�비교� ································································ � 77
<표� 2-19>�주요�애니메이션�및�전환�기능의�비교� ········································ � 78
<표� 2-20>� Canvas�및� SVG�라이브러리� ······················································· � 83
<표� 2-21>�주요�차트�라이브러리� ·································································· � 84
<표� 2-22>�웹�에디터�종류� ············································································ � 89
<표� 2-23>�주요�리포팅�솔루션� ····································································· � 90
<표� 2-24>�주요�플러그인�기반�그리드�컴포넌트� ··········································· 91
<표� 2-25>�전자문서�보호�솔루션�제품들� ······················································ � 92
<표� 2-26>�국내외�오픈�에디터의�특징� ························································· � 93
<표� 2-27>�웹�표준�그리드�컴포넌트� ····························································· � 95
<표� 2-28>�파일전송�ActiveX�사용현황� ························································ � 96
<표� 2-29>� XMLHttpReqeust� readyState� ···················································· � 97
<표� 2-30>�웹�표준� File� API�컴포넌트� ·························································· � 98
<표� 2-31>� PC�원격제어�솔루션� ·································································· � 104
<표� 2-32>�이용자�에이전트�문자열�토큰�설명� ··········································· � 106
<표� 2-33>�윈도우� IE� Trident�토큰� ····························································· � 106
<표� 3-1>�운영체제�연동�기술�현황� ····························································· � 112
<표� 3-2>�브라우저�개발자�지원�정책�현황� ················································ � 113
<표� 3-3>�브라우저별�확장�기능�지원�사이트� ············································· � 113
<표� 3-4>� IE�고유�기술�및� Edge�대응�기술� ··············································· � 114
<표� 4-1>� HTML5�주요�기능� ······································································· � 120
<표� 4-2>�브라우저별�확장�기술�요약� ························································· � 124
<표� 5-1>� NPAPI�대체�기술� ········································································· � 155
<표� 5-2>�국내�NPAPI�사용�현황� ································································ � 156
<표� 5-3>�국내�NPAPI�사용�현황�및�분야� ·················································· � 157
<표� 5-4>�크롬�플러그인�실행�현황� ····························································· � 157
<표� 5-5>�manifest�파일�구성�필드� ···························································· � 159
<표� 5-6>�OS별�manifest�파일�위치� ·························································· � 159
<표� 5-7>�국내� 기능별�대체� 기술� ····························································· � 166
<표� 5-8>�전자결제�대체�기술� ····································································· � 167
<표� 5-9>�키보드�보안�대체�기술� ································································ � 167
<표� 5-10>�공인인증서�대체�기술� ································································ � 168
<표� 5-11>�대체�기술�구분� ·········································································· � 172
<표� 5-12>� EXE�보안�취약점� ······································································· � 173
<표� 6-1>� HTML5�신규�기능�요약� ······························································ � 178
<표� 6-2>� CORS�관련�보안�위협� ································································· � 181
<표� 6-3>�Web� Storage�설명� ····································································· � 182
<표� 6-4>�OWASP� HTML5보안�위협�항목� ················································· � 190
<표� 6-5>�브라우저별�웹표준�수용도� ··························································· � 198
[그림� 2-1]�바이오정보와�공인인증서를�연계한�간편인증�기술� ····················· � 12
[그림� 2-2]� FIDO(Fast� IDentity� Online)인증기술�동작과정� ·························· � 12
[그림� 2-3]�추출된�인증서로�별도�웹서버�운영(파밍)� ··································· � 13
[그림� 2-4]�대칭키�알고리즘을�이용한�데이터�흐름에�대한�시퀀스�다이어그램·· � 20
[그림� 2-5]� Cookie를�이용한�동작�명령�전달� ··············································· � 23
[그림� 2-6]� CORS를�이용한�외부�애플리케이션과�정보�교환� ······················· � 24
[그림� 2-7]�웹�표준�기반�공인인증서�서비스�모델�제시� ······························· � 31
[그림� 2-8]�공인인증서�저장매체� ···································································· � 35
[그림� 2-9]� IndexedDB에�공인인증서�저장�예� ·············································· � 36
[그림� 2-10]�보안토큰과�브라우저�간�연동�모델� ··········································· � 38
[그림� 2-11]�스마트인증�이용�절차�예시� ······················································· � 39
[그림� 2-12]� Same-Origin�환경에서의�공인인증서�이용� ······························ � 40
[그림� 2-13]�공인인증서�상호연동� ·································································· � 41
[그림� 2-14]�Web�Messaging�메시지�통신�기능� ········································· � 42
[그림� 2-15]� FIDO�인증�시나리오� ·································································· � 45
[그림� 2-16]� TrustZone� Hardware� Architecture� ········································ � 46
[그림� 2-17]�mPay�결제�프로세스� ································································· � 52
[그림� 2-18]�페이핀�결제�프로세스� ································································ � 53
[그림� 2-19]� Paypal�프로세스� ········································································ � 56
[그림� 2-20]� video.js의�비디오�재생기� ·························································· � 65
[그림� 2-21]� audio.js�재생기�화면� ································································ � 66
[그림� 2-22]�WebRTC 브라우저 지원현황� ···················································· � 67
[그림� 2-23]� YouTube� ··················································································· � 69
[그림� 2-24]�이퀄라이저�시각화� ····································································· � 70
[그림� 2-25]� Canvas� 2D�샘플�코드�실행�결과� ············································· � 74
[그림� 2-26]� SVG�예제�코드의�실행�결과(좌)와�결과물의�부분�확대(우)� ···· � 76
[그림� 2-27]� Canvas�활용�게임(앵그리버드)� ················································· � 81
[그림� 2-28]� SVG를�이용한�D3.js�차트� ························································ � 82
[그림� 2-29]�레이아웃�발생의�예� ··································································· � 86
[그림� 2-30]� Layouting으로�인한� Repaint�발생의�예� ·································· � 86
[그림� 3-1]�운영체제�및�브라우저�정책�우선순위� ······································· � 111
[그림� 3-2]� 2016년�이후� IE�지원계획� ························································· � 115
[그림� 4-1]�웹�애플리케이션�개발을�위한�연관�표준�기술� ························· � 119
[그림� 4-2]�크롬�지원�NPAPI�대체�플러그인�기술� ····································· � 125
[그림� 4-3]� <meta>태그�미적용/적용�사례� ·················································· � 128
[그림� 4-4]�기기에�따른�Media� Query�적용�화면� ····································· � 129
[그림� 4-5]�웹�폰트�그래픽� ·········································································· � 130
[그림� 4-6]�고정폭/가변폭�콘텐츠�예시� ························································ � 131
[그림� 4-7]� Bootstrap� Button� ····································································· � 133
[그림� 4-8]� Bootstrap� Button� Group� ························································ � 134
[그림� 4-9]� Ionic� Simulator� ········································································ � 140
[그림� 4-10]� Ionic� Folder� Tree� ··································································· � 140
[그림� 4-11]�코드변화가�적용된� Ionic� Simulator� ······································· � 141
[그림� 4-12]� Alert�예시� ··············································································· � 146
[그림� 4-13]� Custom�Alert�예시� ································································ � 148
[그림� 5-1]� asm.js�처리�플로우� ··································································· � 163
[그림� 6-1]�브라우저�점유율� ········································································· � 177
Ⅰ.� 개요
- 3 -
Ⅰ. 개 요
1. 배경
1989년 웹 초기 개발 목적은 웹을 탄생시킨 스위스 유럽원자핵공동연구소(CERN)의
연구자들이 이기종의 운영체제(OS)와 개발 환경에서도 연구 자료를 쉽게 공유할 수 있
도록 하는 것이었다. 그러나 현재의 웹 기술은 초고속 인터넷 인프라 발전에 힘입어 전
자결제, 보안, 공공서비스, 전자문서, 멀티미디어, 소셜 네트워크 등 다양한 생활 서비스
를 제공하는 기반 기술로 사용되고 있다. 특히 국내에서는 2000년 초반부터 초고속 인
터넷 인프라 확산 정책이 진행되면서 단기간에 온라인 뱅킹, 오픈 마켓, 포털 등 다양한
웹 서비스가 급속도로 보급되었다. 그러나 이러한 웹 기술 확산은 2000년 후반부터 특
정 운영체제(OS, Operating System) 및 브라우저에 포함된 비표준 기술 때문에 오히려
웹 서비스 발전을 저해하는 한계를 맞이하게 되었다.
특히 비표준 기술은 보안, 결제, 인증, 멀티미디어, 게임 등에서 이용자 요구를 충족시키기
위한 브라우저 개발사의 서로 다른 플러그인(plug-in) 기술 때문에 파편화(Fragmentation)된
상태에서 빠르게 확산되었다.
국내 웹 사이트 개발자들도 2000년 초에 Microsoft의 ActiveX, Firefox Netscape Plug-in
API(이하 NPAPI) 등 비표준 기술들을 쉽게 사용함으로써 브라우저별 비호환성 때문에
많은 어려움을 겪게 되었다. 2009년 아이폰 등 스마트 단말 시대를 맞이하여 애플의 사
파리, 구글의 크롬 등 멀티 브라우저 및 모바일 웹 서비스 이용이 확산되면서 비표준
기술 전환에 비용과 시간이 필요하게 되었다. 특히 최근 Windows 10에 기본 탑재된 Edge
브라우저에서 비표준 기술인 ActiveX 사용을 전면 금지하거나, 2016년부터 구글 Chrome,
Firefox 브라우저에서 NPAPI를 비활성화 하는 등 브라우저 자체에서 비표준 기술을 지
원하지 않는 방향으로 정책이 변하고 있다.
이러한 비표준 기술을 더 이상 적용할 수 없는 웹 서비스 환경에서 개발 인력과 구축
비용을 절약하기 위해서는 한 번의 개발로 다양한 기기 및 브라우저에서 웹 서비스를
제공할 수 있는 HTML5 표준 기술과 반응형 웹 기술에 대한 지속적인 기술 투자가 필요
하며, 보안, 인증, 결제, 장치제어와 같이 운영체제와 연동하는 기술 적용 방식은 서버
연동을 통한 인증과 보안에 문제가 생기지 않게 하거나 운영체제 개발 업체가 디지털
서명을 인증하는 방식으로 개발 방법을 변경해야 한다.
- 4 -
국내에서는 비표준 기술로 인해 발생한 인터넷 이용환경 문제를 개선하기 위해 2011년
부터 인터넷 이용환경 개선 기술안내서 보급 및 웹 표준 전환 지원 컨설팅 사업을 벌이
고 있다. 하지만 10여 년 동안 특정 브라우저와 비표준 기술에 의존해왔던 웹 서비스
환경과 관련 법제도 변경 지연 등의 복합적인 요인으로 인해 비표준 기술 퇴출이 지연
되고 있다.
2. 목적
본 안내서는 국내 웹 개발자 및 웹 사이트 운영자가 ActiveX, NPAPI와 같은 비표준
기술을 개선하고자 할 때 참고할 수 있도록 주요 분야별 비표준 기술 사용 현황, 브라
우저 개발사의 정책, 비표준 대체 기술의 기술별 특징, 구현 방법, 적용 시 고려사항 등
에 대한 내용을 제공한다. 더불어 신규 웹 서비스 개발 시 발생 가능한 불편 사항을 개
선할 수 있는 표준 웹 기술에 대한 구현 방안도 함께 제공하는 것을 목적으로 작성되었
다.
3. 요약
본 안내서는 보안, 인증, 전자결제, 멀티미디어, 그래픽, 전자문서, 파일 처리, 게임, PC
제어 등 웹 호환성 기술과 멀티 운영체제 및 브라우저 정책, NPAPI 대체기술, HTML5
등 크게 5개 부문으로 구성되었다. 웹 호환성 부문의 경우 9개 기술로 분류하여, 각 기
술에 대해 ActiveX, NPAPI 등 비표준 기술을 사용하지 않고 웹 호환성을 확보할 수 있
는 방법 및 기술을 제시하고 있다. 멀티 운영체제 및 브라우저 정책은 브라우저 개발사
의 전환가이드 적용 방법, 운영체제 기반의 응용 프로그램을 제공하는 방법, 브라우저
개발사 권고 확장 기술의 적용 방법과 대안을 제시하고 있다.
NPAPI 대체기술은 브라우저 개발사 권고에 따라 NPAPI와 같은 비표준 기술을 사용하
지 않고 웹 표준 방식으로 상호호환성과 상호운용성을 확보하는 방법 및 기술을 제시하
고 있다.
끝으로 HTML5는 표준 규격과 웹 애플리케이션 규격, 구형 브라우저에 HTML5 지원
방안, 보안 이슈, HTML5 브라우저 수용도, HTML5.1 글로벌 동향 분석에 대해 기술하고
있다.
- 5 -
4. 적용환경
본 안내서에서 제시하는 방법은 대부분 윈도우와 맥 OS 환경에서 시험되었으며, 일부
기술들은 모바일 기기에서도 시험되었다. 웹 서버는 윈도우 IIS와 리눅스 OS 기반의 아
파치 웹 서버를 기준으로 하였으며, 클라이언트는 윈도우 및 맥 OS에서 동작하는 크롬,
파이어폭스, 사파리 및 인터넷 익스플로러(IE) 등에서 시험되었다.
HTML5 표준과 자바스크립트를 이용해서 구현된 기능은 HTML5를 지원하는 최신 브
라우저에서만 동작하므로, 웹 개발자는 HTML5 표준 웹 기술을 이용하여 대체기술을 구
현, 적용 할 경우 최신 브라우저의 버전과 http://html5test.com과 같은 표준 지원 확인
사이트를 통하여 서비스를 제공 하고자 하는 브라우저의 HTML5 기능 지원 여부를 확인
해야 한다. 참고로 2016년 10월 기준으로 PC용 크롬 53, 파이어폭스 48, 사파리 9.1, 인
터넷 익스플로러 11 이상 버전에서 HTML5 표준 규격을 대부분 지원하고 있다.
5. 활용대상
본 안내서는 웹 개발자, NPAPI 개발자, 웹 사이트 운영자, 웹 솔루션 개발자를 대상으
로 하였다. 본 안내서에서 개발자는 PM(Project Manager), 기획자, Front-End, Back-End,
Desktop Application 개발자를 모두 포함하는 개념으로 정의하였다.
6. 문서의 한계
본 안내서에서 제시된 기술은 현장에서 사용되는 다양한 사례 중 일부만을 골라 제시
된 것이다. 따라서 제시된 기술을 이용하여 상용 솔루션과 서비스를 구현할 경우 법제
도, 조직 내부의 서비스 정책, 대상 고객의 이용환경 등을 고려하여 변경, 적용하여야
한다.
II.� 웹� 호환성
- 9 -
II. 웹 호환성
이 부문에서는 웹 호환성 개선을 위해 국내에서 비표준 기반으로 사용되는 9개 주요
기술 분야를 다룬다. 9개 기술 분야 중 전자결제 기술과 연관 있는 인증, 보안 기술은
기존 공인인증서와 새로운 간편 결제 방식 사용에 대한 웹 호환성을 다루고 있다.
보안 분야 중 키보드 보안과 같이 특정 기술이 필요한 솔루션의 경우 웹 표준 기술로
대체할 수 있는 방법이 존재하지 않을 경우, 차선책으로 별도의 응용 프로그램을 제작하
여 배포하거나, 브라우저와 응용 프로그램 간 서버 통신을 통해 서비스를 제공하는 방안
을 대안으로 제시하고 있다. 이때 별도의 응용 프로그램을 구현하는 경우에도 특정 운영
체제나 브라우저 개발 정책에 부합하고 비표준 기술에 종속되지 않도록 구현해야 한다.
운영체제 및 브라우저 개발사는 상호 지원 방식에 따라 고유의 확장 방식을 제공하고
있다. 운영체제와 브라우저를 결합된 형태로 제공하는 MS와 애플은 최근 자사 기술 정
책과 로드맵에 따라 운영체제에 설치하는 응용 프로그램 기술과 웹 기술을 상호 독립적
으로 운영하는 정책을 유지하고 있다. 반면 자사 운영체제 점유율이 미약한 구글과 모
질라 재단의 경우 높은 브라우저 점유율을 기반으로 샌드박스 보안모델을 유지하면서
자체 플러그인 기술로 웹과 운영체제 설치형 응용 프로그램이 유기적으로 연동할 수 있
도록 기술 지원을 하고 있다. 다만 플러그인 기술 중 NPAPI의 경우 보안 및 안전성 문
제로 인해 더 이상 브라우저가 지원하지 않는 점을 고려하여 브라우저별로 지원하는 다
른 플러그인 기술을 확인해야 한다.
크롬, 사파리, 파이어폭스, 오페라 등에서 전자결제 및 연관 기술로 활용되고 있는 NPAPI
플러그인 기술의 경우 브라우저 개발사가 2016년을 시작으로 지속적으로 기술 지원을
중단하였다. 따라서 멀티 브라우저에서 NPAPI를 확장 기술로 활용하고 있는 솔루션과
서비스는 HTML5 웹 표준으로 전환하거나, 브라우저별로 지원하는 다른 플러그인(NaCl,
pNaCl, ams.js, Native Messaging)으로 재개발할 수 있다. 또한 운영체제 설치형 응용 프
로그램과 브라우저 간 서버 통신을 통해 대체할 수도 있다.
웹 사이트에서 사용되고 있는 ActiveX, NPAPI와 같은 비표준 플러그인을 진단하기 위한
방법은 자동화 도구를 활용한 방법과 특정 태그를 검색해서 페이지와 서비스 프로세스별로
점검하는 방법이 있다. 현재 무료로 제공되는 자동화 점검 도구로는 www.koreahtml5.kr에
서 제공하는“웹 표준 진단도구”를 활용할 수 있다.
- 10 -
1. 개요
HTML5 표준 환경에서 결제, 인증을 위해 가장 기본적으로 사용되는 보안을 위한 기술
요소를 도출하고 각 기술 요구사항별 표준 대응 방안을 정리한다. 보안은 본인 확인을 위
한 로그인 보안, 외부 불법적인 접근 또는 해킹 공격을 방지하기 위해 서비스 및 프로그램
사용을 제한 통제하는 개인방화벽, 백신, 키보드 보안, 구간 암호화 등을 포괄한다. 또한 적
격PG(결제대행사) 사업자 요구 보안 수준인 PCI-DSS(Payment Card Industry-Data Security
Standard) 중 웹 서비스와 관련된 부분도 언급하였다.
웹 서비스를 위한 정보보호 보안은 유무선 인터넷과 같은 네트워크를 통하여 전달되는
정보의 위/변조, 유출, 무단침입, 서비스거부 등을 비롯한 각종 불법 행위로 부터 개인의
컴퓨터와 인증, 결제 정보를 안전하게 보호하고, 물리적인 공간에서의 보안 침해사고 방
지를 위해 서버, 이용자 PC(클라이언트)의 양방향 보안을 기본적으로 제공해야 하나 여기
에서는 이용자 환경 보안을 좀 더 집중하여 내용을 구성하였다.
2. 사용 현황
2.1 로그인 보안
로그인 보안을 위한 기술 요소를 도출하고 각 기술 요구사항별 표준 대응 방안을 정
리한다. 기존 로그인 보안 방식은 대부분 공인인증서를 통한 로그인, 아이핀 등 공공기
관에서 인증 심사를 하고 인증 전문업체가 솔루션을 제공하는 방식으로 인증의 안전성
을 보장하여 제공하였으나, 최근 간편 결제가 활성화 되면서 휴대폰 번호, 카드 번호, O
TP등 기존 지식기반(What you know)에서 인증 매체의 소지 편의성이 높은 기기를 활용
한 소지 기반(What you have), 온라인 간편인증 FIDO(Fast IDentity Online)은 지문․홍채․얼굴인식 등 바이오 인식기술과 공개키 암호기술을 융합한 생체인증 본인 확인 기술이
며 활성화되고 있다.
1 보안
- 11 -
가. 인증서 로그인 보안
기존 공인인증서 로그인 시 주민등록번호 등 특정 값에 대하여 공인전자서명을 하고
인증 서버로 전달, 인증 서버에서 공인인증서에 포함된 VID값으로 주민번호를 검증하여
로그인을 허용하였으나, 최근 주민번호 수집금지 정책에 의해 주민번호로 로그인 인증
하는 현행 방식을 더 이상 사용할 수 없게 되었기 때문에 공인인증서의 플러그인 의존
도를 줄일 수 있는 웹 표준 방식의 공통기반 보안 기술 개발이나 보안토큰 기반 스마트
폰 연계 방식(NFC)을 탑재하는 방식의 매체 보호 기술 개발 및 보급이 운용되고 있다.
또한 공인인증서와 사설인증서를 병행 선택할 수 있는 법적 근거가 마련됨으로써 로
그인 보안 기술을 웹 표준 기반으로 개선할 수 있는 방안이 마련되었으며, 간편 결제를
통해 이를 활용한 웹 표준 기반 인증 보안을 상용화 하고 있는 추세이다.
나. 아이핀/마이핀 보안
아이핀은 인터넷상에서 주민번호를 대신하여 아이디와 패스워드를 이용하여 본인확인
을 하는 수단으로 4개 본인확인기관 홈페이지나 네이버, 다음 등 i-PIN이 도입된 웹 사
이트에서 발급신청이 가능하다. 아이핀 발급을 위해서는 본인확인 방식으로 휴대폰, 범
용 공인인증서, 대면확인방식을 이용하여 발급이 가능하다.
마이핀은 행정자치부에서 제공하는 본인확인 서비스로 기존 아이핀과 유사하나 주민
번호를 대체하는 13자리 무작위 번호를 사용하여 본인 확인을 수행하고 있다.
아이핀과 마이핀 모두 안정성을 강화하기 위하여, 아이핀과 마이핀 이용 시 ID/PW외
에 추가인증을 하며 본인확인 방법으로 아이핀과 마이핀 ID/PW 입력 후, 2차 비밀번호
또는 모바일 OTP입력을 하여야 한다.
다. 온라인 간편인증 보안
온라인 간편인증(FIDO) 기술은 지문․홍채․얼굴인식 등 바이오 인식기술과 공개키 암호
기술을 융합해 비밀번호 입력 없이 본인인증 한 번만으로 결제가 가능한 기술로 스마트
폰 등 다양한 모바일 단말기에서 생체인식 기술을 접목하여 비밀번호 입력의 불편함을
제거하고 공인인증서를 스마트폰 USIM 등 하드웨어 플랫폼에 보관시키는 기술로 개발
되었다.
- 12 -
[그림 2-1] 바이오정보와 공인인증서를 연계한 간편인증 기술
[그림 2-2] FIDO(Fast IDentity Online)인증기술 동작과정
2.2 개인방화벽 및 백신
개인방화벽과 백신은 개인이 직접 검증된 제품을 설치하여 사용하면 보안상의 요구를
충족시킬 수 있다. 이용자 본인 책임의 안전한 금융 거래를 중시하고 있는 해외에서는
이용자들에게 백신과 방화벽이 포함된 제품을 쓰도록 권고하고 있다. 그러나 사업자 책
임의 비중이 더 큰 국내에서는 사업자가 개인방화벽과 백신을 제공하지 않아도 적절한
제품이 정상 동작하고 있는지 확인할 필요가 있었으며, 현재는 ActiveX나 NPAPI, EXE
방식으로 확인하고 있다.
- 13 -
2.3 키보드 보안
키보드 보안은 크게 2가지 역할을 한다. 첫 번째는 키보드로 입력되는 정보가 브라우
저에 전달되기 전까지 또는 서버에 이르기까지 보호(키보드 보안 E2E 확장)를 해준다.
두 번째는 키보드가 아닌 다른 방식(SW 방식)으로 입력된 정보가 브라우저에 전달되는
것을 차단하는 것이다. 주로 보호하는 대상은 카드번호, 계좌 비밀번호, 이체 비밀번호,
계정 패스워드, 인증서 비밀번호, 보안카드 값, OTP 값 등과 같이 외부로 노출되면 안
되는 정보들이다.
현재 키보드 보안을 위해서는 다양한 인터페이스로 연결되는 키보드로부터 입력되는
정보를 보호하기 위한 드라이브가 필요하며, 이 드라이브를 메모리에 로딩하고 안전하
게 통신을 하여 브라우저에 입력 값을 전달하기 위해서는 커널 모듈에 소프트웨어를 설
치해야 한다. 지불결제 시 사용자 정보 입력 및 비밀번호 입력에 따른 보안 감시를 위
해 최근에 EXE 방식이 도입되어 사용되고 있다.
화면에서 입력한 정보를 직접 서버로 전달하는 방법이 있으나 서버에서 동기화를 맞
추는 방법이 쉽지가 않아 현재 대부분의 솔루션은 별도 응용 프로그램과 주고 받아서
수행하는 방식으로 구현하고 있다. 이를 위해서 대부분 PC에 로컬서버를 https로 운영
중이며 그에 따른 인증서와 개인키가 노출되고 있어 일종의 악성코드 역할을 할 수 있
는 가능성이 있다. 이는 사용 인증서를 로컬서버 인증서로 사용하고 있어서 발생하는
문제로 해킹에 의해 인증서가 유출될 경우 파밍으로 이용될 수 있으며 인증서 발급기관
에서 이 사실을 알아 인증서를 폐기할 경우 국내 서비스 대부분이 대책 없이 상당기간
동안 서비스가 중단될 수 있는 가능성이 있다.
[그림 2-3] 추출된 인증서로 별도 웹서버 운영(파밍)
- 14 -
2.4 데이터 암호화
데이터 암호화의 경우 이용자 브라우저와 같은 클라이언트나 웹서버 간의 통신, 그리
고 서버와 서버 간의 통신 등 선로구간에 전자금융 정보나 개인정보 같이 민감한 데이
터가 인터넷을 통해 전송되는 과정에서 데이터 노출을 방지하거나 데이터 접근에 대한
경로를 추적하기 위한 방법으로써 데이터 자체를 암호화하여 저장해야 한다. 이래야만
데이터가 유출될 시에도 내부 데이터를 사용하지 못하게 방지할 수 있기 때문이다. 특
히 금융기관 또는 전자금융업자는 이용자와 서버 간의 전자금융거래내역 등 중요정보가
유출되지 않도록 암호화를 통한 비밀성․무결성을 제공하여야 한다.
이를 위해 인터넷과 같은 공중망 환경에서는 송·수신되는 정보에 대한 보호대책이
필요하다. 이러한 보호대책으로 SSL/TLS, VPN 등과 같은 다양한 통신 암호기술이 적용
될 수 있다
통신 데이터 암호화는 OSI 7 Layer중 Transport Layer와 Application Layer를 대상으로
한다. Transport Layer에는 SSL/TLS Protocol이 적용되며 Application Layer에는 자바스크
립트를 이용한 RSA Encryption/Decryption 또는 Symmetric Encryption/Decryption을 적용
할 수 있다. 또한 Transport Layer 암호화와 Application Layer 암호화는 함께 공존 가능
하나 Transport Layer 암호화(SSL/TLS)없이 Application Layer만의 통신 암호화를 구현하
는 것은 매우 위험한 시도이므로 지양해야 한다.
3. 대체 기술
현재까지 보안 기술은 사용자 클라이언트에 보안 기술과 솔루션을 적용했다면 향후 보
안 기술은 이상거래탐지 및 거래 단말 지정, PCI-DSS(Payment Card Industry-Data Security
Standard) 기반의 고객 신용카드 정보를 위한 보안 표준 준수 등의 표준 보안 인증과
FDS와 같은 서버 기반 기술, 고객 손해배상보장 등 비 기술적인 요소가 중요할 수 있
다. 또한 웹 서비스를 위한 보안 서버와 HTTPS 구축 시 주요 취약점(암호 취약점, 프로
토콜 취약점, 제품 취약점)에 대한 공격 패턴을 인지하고 대응해야 한다.
로그인 보안, 개인방화벽, 키보드 보안, 데이터 암호화 등의 보안 대체 기술은 사용자
의 이상 행위 및 외부의 불법적인 접근 또는 해킹 공격을 방지하기 위해 웹 표준 및 브
라우저 확장 기술 기반 대체기술에 대한 안내이다.
- 15 -
3.1 로그인 채널 보호
가. SSL Configuration 정상 구성
안전한 인증서 사용을 위해서는 SSL Configuration을 정밀하게 구성하는 것이 필요하
며 공인 및 사설 인증서는 다수의 브라우저에 의해 신뢰할 수 있는 인증기관으로 등록
된 인증기관으로부터 인증서를 발급받아 사용해야 한다. 또한 WebTrust 인증 등 제3자
의 정기적인 보안 감사를 받는 인증기관의 인증서를 이용하는 것이 바람직하다.
SSL 구성은 가능한 Protocol을 접속 클라이언트의 범위를 고려하여 정하되 특별한 경
우가 아니라면 SSLv2는 사용하지 않도록 구성하고 암호화에 사용되는 암호화키는 최소
한 128bit이상의 보안비도를 보장하는 Cipher Suites 목록을 지정하여 사용한다.
나. Application Level Encryption 구성
웹 표준 환경에서 자바스크립트를 이용하여 Application Level의 Encryption을 구현하
여 사용하는 것을 권장하고 있으며 Application Level Encryption의 가용한 구성은 다음
과 같다.
- 공개키 암호 알고리즘 이용서버에서 공개키와 개인키 페어를 생성한 후 공개
키를 클라이언트로 응답하고 클라이언트에서 데이터를 공개키로 암호화하여
서버로 전송한다. 서버에서 개인키로 복호화하여 로그인 데이터를 확인한다.
- 대칭키 암호 알고리즘 이용서버와 클라이언트 간 동일한 키를 공유한 경우
클라이언트에서 데이터를 대칭키 암호화하여 서버 전송하고 서버에서 동일한
대칭키로 복호화하여 데이터를 확인한다.
다. Application Level Encryption 보안성 보장 조건
- 강력한 보안구성을 SSL/TLS Transport Layer 상에서 운용한다.
- Encryption/Decryption을 수행하는 자바스크립트에 대한 보호 대책을 적용한다.
- 16 -
라. 2채널 관리를 통한 보안성을 보완한다.
- APT, 키보드해킹, 메모리 위변조 등의 공격에 대비하기 위한 이중 교차 확인을
통해 보안 취약점을 방어한다.
- 채널 간 독립적 운영과 보호를 통해 보안사고 발생 시 대응 방안을 수립한다.
3.2 자바스크립트 보호
자바스크립트는 로그인 보안을 구성하는데 있어 실질적인 User Agent를 인지하고 서
버에 인증을 처리하는 매우 중요한 역할을 수행한다. 이때 자바스크립트 보호 방안은
매우 중요하며, 자바스크립트 보호 방안은 독립적으로 사용되거나 다른 보안 방식과 함
께 사용될 수 있다.
가. 자바스크립트 난독화
- 자바스크립트로 중요한 비즈니스 로직 및 주요 정보를 서버에 전달할 경우 U
ser Agent로 자바스크립트가 로드 되면서 해당 코드가 그대로 노출되어 해커
입장에서 함수와 데이터, DB 테이블을 분석하게 되면 서비스 취약점이나 동
적으로 자바스크립트 인젝션 공격을 통해 플러그인 설치 후 악성코드를 유포
시키거나, 별도 쿼리를 만들어 내부 정보를 탈취할 수 있다. 이를 어렵게 하
기 위해서 자바스크립트 난독화 기술을 적용한다.
- Encryption/Decryption을 수행하는 자바스크립트에 대한 보호 대책을 적용한다.
나. 자바스크립트 난독화 과정
- 자바스크립트 Code내 모든 Symbol Name들을 난독화하기 위해 특별한 스트링으로 치환
(예 :“hello”라는 심볼 네임은 다른 스트링으로 치환 “aadsfhdaskfd1asdfkfaskgfs”)
- 자바스크립트 내의 주석(코멘트)을 모두 제거
- 코드 내의 공백, 탭 또는 빈 줄을 모두 제거
- 모든 코드를 한 줄로 연결
- 17 -
다. 자바스크립트 동적 난독화
일반 난독화 과정에서 자바스크립트 Code 내의 Symbol Name을 치환할 때 생성되는
스트링을 세션에 기반한 난수로 생성한 코드로 치환한다. User Agent로 로딩되는 자바
스크립트 코드는 각 세션별로 고유한 자바스크립트 코드를 가지게 된다.
라. 자바스크립트에 대한 무결성 검증
자바스크립트 코드에 대한 동적 난독화를 하였더라도 해커는 User Agent로 로딩 된
자바스크립트 코드를 분석하고 변조할 수 있다. 따라서 서버에서 UA로 보낸 자바스크립
트 코드가 변조 없이 실행되는 것을 보장하는 무결성 검증 방식을 추가로 개발해야 한
다.
마. 자바스크립트 동적 로딩
트랜잭션 종류별 또는 단계별로 사용되는 자바스크립트 코드를 구분하여 필요한 자바
스크립트 코드만을 UA로 로딩하여 사용하는 방식이 전체 비즈니스 로직의 노출을 방지
하고 자바스크립트 코드를 경량화하여 보안성 및 속도 개선에 도움이 된다.
바. 자바스크립트 Sandboxing
자바스크립트 코드가 제3의 사이트에 혼합되어 사용되는 경우 제3자 자바스크립트 코
드 동작에 의해 실제 자신의 자바스크립트 코드 실행에 영향을 미칠 수 있게 된다. 예
를 들어 변수 사용이 중첩되어 변수 값을 탈취, 변조 등의 공격이 가능하며 이에 대한
대책으로서 자바스크립트 코드의 Sandboxing 기법 사용을 권유한다. 대표적인 Sandboxing
기법은 iFrame을 사용하는 것이지만 이 방법 이외에 Google Caja Project 등 다수의 Sandboxing
기법이 있다.
- 18 -
사. 자바스크립트 암호화
- 자바스크립트 코드를 동적 난독화하거나 무결성 검증을 하더라도 코드 자체
에 대한 노출을 원하지 않을 경우 서버에서 로딩되는 중간에 자바스크립트
코드를 암호화할 수 있다. 자바스크립트 코드의 암호화는 Application Layer
에서 Symmetric Encryption Algorithm을 사용할 수 있다. UA에서는 암호화된
코드를 실제 실행하기 전 복호화하여 실행하고 폐기하는 것이 가능하다. 자
바스크립트 코드를 복호화한 내용은 UA의 Sandbox Memory 내에서만 존재하
며, 페이지 전환이나 DOM 개체의 삭제 둥의 행위로 메모리에서 코드 삭제가
가능하다.
- 자바스크립트를 사용하여 암호화를 구현할 경우는 실시간 공격을 배제한다면
어떤 경우든 패스워드나 암호키에 보안성을 의존하게 된다. 결국 가능한 긴
패스워드를 적용하여 사용될 수 있도록 할 필요가 있다. 물론 스크립트 상에
비밀키가 노출되지 않아야 한다.
3.3 보안 서버 및 페이지 암호화
보안 서버란 인터넷상에서 사용자 PC와 웹 서버 사이에 송/수신되는 개인정보를 암호
화하여 전송하는 서버를 의미한다. 보안 서버는 정보유출 방지, 위조사이트 방지, 웹 서
비스 사이트 신뢰도를 보장하기 위해 인터넷에서 송/수신되는 개인정보(로그인 : ID/패스
워드, 회원 가입 : 이름/전화번호, 인터넷 뱅킹 이용 : 계좌 번호/계좌 비밀번호)등을 SSL
방식과 응용 프로그램 방식으로 암호화하는 방법이다.
가. 보안 서버
웹 서비스 구축 시 보안 서버 구축을 통해 HTML 소스코드가 https로 암호화되도록
웹 페이지에 적용하고, 이를 통해 웹 서버와 브라우저 간 개인정보(ID, 패스워드, 주민등
록번호, 전화번호, 이메일 등)를 암호화하여 송수신하는 기능을 제공할 수 있도록 구축
한다. 검증된 보안 서버를 구축하기 위해서는 구축 시 보안 서버보급지원 정보 사이트
(http://opa.or.kr/Business-secureserver_support.do)를 통해 신뢰할 수 있는 솔루션(업체) 및
적용 범위, 적용 방법을 확인 후 자사 서비스에 반영한다. 보안서버 구축은 사용자 컴퓨
터에 별도 보안 프로그램을 설치할 필요가 없는 SSL 인증서를 통한 암호화 전송 방식을
사용하는 것이 바람직하며, 별도 응용 프로그램을 설치하는 방식을 지양해야 한다.
- 19 -
- 또한 서버에서 RSA 키쌍을 생성 시 개인키의 키 사이즈는 2048bit이상이어야
하고 서버에서 생성하는 개인키는 HSM 내에 보관하는 등 적절한 보호조치를
취해야 한다.
(생성된 키쌍을 세션에 저장해두고 세션 종료 시 자동 폐기되도록 조치하는
방안도 고려가능)
- 자바 스크립트로 제공되는 암호라이브러리는 많은 기능을 제공하지는 않는다. 따
라서 여러 라이브러리들 중에서 사용하고자하는 알고리즘들을 선택하여 제공할
필요가 있다. 일반적으로 많이 사용되는 것들은 다음과 같다.
§ WebCryptoAPI(http://www.w3.org/TR/WebCryptoAPI/) HTML5에서 지원하기 때문
에 장기적으로 볼 때 가장 권고하는 방식이며 IE브라우저에서는 11버전에서
부터 지원이 제대로 되고 있으며 Edge브라우저에서 완벽하게 지원이 된다. 지
속적으로 추가 스펙이 만들어 지고 있어 가장 권고하는 방식이다.
§ Stanford JavaScript Crypto Library(http://bitwiseshiftleft.github.io/sjcl/) ECC중심
으로 가볍고 빨라서 널리 사용된다. 그러나 지원 폭이 넓지 않기 때문에 용도와
맞는지 확인 후 사용하기를 권고한다.
§ CryptoJS(http://code.google.com/p/crypto-js/) 제공되는 안전한 알고리즘도 많고
사용하는 방법도 용이하다.
§ Jsbn(http://www-cs-students.stanford.edu/~tjw/jsbn/) 데스크탑과 모바일 브라우저
에서 순수 자바 스크립트로 RSA와 ECC를 지원한다.
§ OpenPGP.js(https://github.com/openpgpjs/openpgpjs) 자바스크립트로 PGP를 지원
하고 싶은 경우 선택할 수 있는 방법이다.
§ Jwcrypto(https://github.com/openpgpjs/openpgpjs) JSON환경에서 사용한다면 고
려해볼 수 있는 라이브러리로 JSON Web Signature, JSON Web Tokens, JSON
Web Certificates로 구현되어있다.
- RSA 암복호화는 암호연산자원을 많이 소모하므로 대규모 데이터의 송수신에는
적합하지 않아, 암복호화 속도를 고려할 경우 RSA 공개키 암호화보다는 빠른
대칭키 암호 알고리즘을 이용하여 애플리케이션 데이터를 송수신하는 것을 권
장한다.
- 20 -
- 대칭키 알고리즘을 이용한 Data Flow에 대한 Sequence Diagram을 그려보면 아
래와 같다.
[그림 2-4] 대칭키 알고리즘을 이용한 데이터 흐름에 대한 시퀀스 다이어그램
- 대칭키 생성은 Random Number 알고리즘을 이용하지만 통상 자바스크립트에
존재하는 Math.random( )은 암호기술에서 사용될 수 있을만한 유의미한 수준
의 함수가 아니다. 만일 브라우저에서 HTML5 WebCrypto getRandomValues( )
함수처럼 True Random Number Generator를 지원한다면 해당 기능으로 대칭키
를 생성하는 것을 권장한다. 브라우저에서 True Random Number 생성을 지원하
지 않을 경우 마우스 이벤트, 디바이스 움직임 이벤트, W3C Web performance
표준인 performance.now( ) 함수를 이용한 Micro Second를 조합하여 Entropy
를 증가시킨 이후 해당 Entropy에서 Random Number를 생성하는 것을 권장
한다.
- 21 -
- SSL/TLS Transport Layer Encryption과 Application Layer Encryption을 함께
사용 가능하지만 SSL/TLS Transport Layer Encryption 없이 Application Layer
Encryption을 단독으로 사용하는 것은 매우 위험한 시도이므로 유의해야 한
다. 또한 HSTS(HTTP Strict Transport Security)를 활성화하는 경우 Max Age
를 가능한 긴 시간(31536000)으로 설정해야 한다. 서버에서 HSTS Header가
활성화된 응답을 User Agent로 보내고 해당 User Agent가 이를 지원한다면
이후 접속되는 모든 Connection은 HTTPS Protocol을 사용하도록 강제로 변경
되므로 서비스 구현 시 유의한다. MS는 윈도우 10의 IE에 추가할 예정이었으
나 최근 윈도우 7과 8.1상의 IE 11에 대하여 우선 지원하고 있으며, 구글 크
롬은 2009년, Firefox는 2010년, Opera는 2012년부터 지원했다.
나. 페이지 암호화
보안 서버 설치 후 웹페이지(전체, 부분)에 암호화를 적용해야 하며, 이때 전체 페이지
암호화의 경우 소스 수정 부분이 단순하지만 서버 부하 및 네트워크 지연 등 이용의 불
편을 초래할 수 있어, 복잡도가 증가하지만 개인정보가 송수신되는 웹 페이지 부분에
암호화를 적용한다.
부분 암호화는 페이지별 암호화 방법과 프레임 암호화 방법으로 제공할 수 있다.
- 페이지별 암호화는 현재 위치하고 있는 페이지에서 다른 페이지로 이동(링크)
할 때 보안을 위해서 https 페이지로 이동하도록 개발한다.
- 프레임 암호화는 <iframe>(HTML5에서는 <frame>, <frameset>은 비추천 태그임)을
활용하여 프레임에 삽입된 웹 페이지를 암호화된 페이지로 적용하여 개발한다.
- 추가적인 웹 페이지 암호화 및 취약점 보안 개선 방안은“웹 서버 및 홈페이
지 취약점 점검 가이드, 교육사이버안전센터”자료를 참고하여 웹 페이지 개
발 보안 취약점을 개선한다.
- 로그인 보안을 회피하기 위해서는 알려진 공격기법에 대한 최신 정보를 파악
하고 대응해야 하며, 심각한 보안 취약성을 초래할 수 있을 경우 검증된 로
그인 보안 상용 솔루션 도입을 통해 안전성을 높이는 방안이나, 검증된 외부
서비스와 로그인 계정을 공유(OAuth)해서 이용자 로그인 정보 관리를 회피하
는 방법을 강구할 수 있다.
- 22 -
3.4 개인방화벽, 키보드보안 및 백신 대체
개인방화벽, 키보드보안, 백신은 공인인증서 저장 위치와 인증서 접근에 따른 보안 문
제를 해결하기 위한 요소로 대부분 설치와 이용 시 플러그인 문제가 발생하고 있다.
개인방화벽은 이미 대부분의 윈도우 운영체제에서는 제공이 되어 무료로 사용하거나
사용자가 직접 설치한 제품들에서 제공을 하고 있기 때문에 대체 가능하다. 따라서 이용
자의 주도적인 선택에 의해서 활성화하거나 별도의 프로그램으로 설치를 안내해야 하
며, 정상동작하고 있는지 점검하도록 안내하는 것이 필요하다. 주의할 것은 무료 백신
중에는 방화벽 기능이 없는 경우가 있기 때문에 서비스 제공 시 이에 대한 안내 부분도
고려하여야 한다.
윈도우 10에서 커널(Kernel) 구조가 변경되었으며, 커널을 접근하는 소프트웨어는 x64
기반의 컴퓨터 시스템을 로딩하기 앞서 Windows Driver Kit(WDK)을 통해 디지털 서명
을 해야 한다. 이에 따라 부트 시작 드라이버는 커널 모드 코드 서명을 위한 디지털 인증
서를 발행하는 상업적 인증기관(CA)으로부터 소프트웨어 간행 인증서(Software Publishing
Certificate; SPC)를 획득해야 한다. 또한 IE 10 이하에서 제공하던 API가 IE 11에서 제거
됨에 따라 아래의 대체기능을 이용하여 서비스하도록 기존 소스를 변경할 필요가 있다.
<표 2-1> 제거 API 및 대체 기능
제거된 API 기능 대체 기능
attachEvent addEventListener
window.execScript eval
window,doScroll window.scrollLeft, window.scrollTop
document.all document.getElementByld
document.fileSize, img.fileSize XMLHttpRequest를 사용
script.onreadystatechange script.onload
script.readyState script.onload
dodument.selection window.getSelection
document.createStyleSheet document.createElement
style.styleSheet style.sheet
window.createPopup div, iframe을 높은 zIndex값과 함께 사용
이진 동작 표준 기반(예, canvas, SVG, CSS3 애니메이션)
레거시 데이터 바이딩 프레임워크의 바인딩 사용(예, WinJS)
- 23 -
또 하나의 문제는 브라우저가 구동되는 시점을 인지하고 개인방화벽과 백신이 금융
거래나 결제가 진행되는 동안 브라우저의 이벤트와 메모리를 계속 감시할 필요가 있다.
이를 위해 운영체제 내 탑재된 애플리케이션과 브라우저 사이의 안전한 정보 교환이 가
능해야 하며 개인방화벽, 백신 개발업체가 애플리케이션과 브라우저가 통신 할 수 있는
방안을 만들어야 한다.
[그림 2-5] Cookie를 이용한 동작 명령 전달
현재 검토되고 있는 방식은 Cookie, Web Socket 등을 사용하는 방식부터 다양한 시도
를 하고 있으나 양방향 통신에 여러 제약이 존재하고 브라우저의 Extension을 사용할
경우 각 브라우저 별로 지원 가능한 플러그인 기술을 확인해서 개발 되어야 하는 단점
이 있다.
Cookie를 사용할 경우 브라우저 외부에서 실행 중인 개인방화벽이나 백신에 명령을
전달하기는 용이하나 역으로 개인방화벽이나 백신에서 그 상태를 브라우저에 전달하는
것은 용이하지 않다. 즉 외부에서 그 값을 바꿔도 브라우저를 재시작하기 전에는 그 값
이 반영되지 않는다. Local Storage를 이용하는 경우도 Cookie와 동일한 방식으로 동작
한다.
- 24 -
Web Socket이나 CORS(Cross-Origin Resource Sharing)를 활용하여 외부 애플리케이션
과 통신을 수행할 수 있다. 그러나 https로 서버와 연결을 맺은 상태에서는 IE의 경우
https로만 통신이 가능하다. Web Socket의 경우에도 동일한 현상이 발생한다. https 통
신을 위해서는 로컬에 인증서와 개인키 설정이 필요한데 이는 localhost에 대하여 브라
우저에서 허용하는 인증서 발급도 불가하지만 사설로 만들어서 운영한다고 하여도 공격
자에게 이용당할 수 있기 때문에 추가적인 보안 조치 방안이 필요하다.
[그림 2-6] CORS를 이용한 외부 애플리케이션과 정보 교환
기존 동작방식에 집착하지 않고 서버를 상호작용에 포함시켜 브라우저 키보드보안 및
백신 서버 브라우저와 같은 흐름으로 정보를 주고받을 수도 있으나 기존 방식을 사용하
고 있지 않을 경우 서버의 동작 방식을 바꾸는 위험이 뒤따른다. 또는 시큐어 브라우저
와 같은 개념의 방식을 통하여 보안제품이 브라우저를 보호 감시하면서 브라우저를 악성
코드의 공격이나 해킹으로부터 보호하는 방법을 사용할 수도 있으나 이 경우에도 시큐어
브라우저가 서버에 정상 동작하고 있음을 알릴 방안이 필요하다.
- 25 -
따라서 개인방화벽, 키보드보안과 백신의 경우 유의할 사항은 브라우저와 운영체제에
상주하고 있는 애플리케이션 사이의 상태 정보 전달을 위한 통신을 위해서는 항상 제품
이 실행되고 있는 상태이어야 하며, 이용자가 금융이나 결제, 공공 업무를 수행하는 시점
에 대해 인지하고 실행하고 있어야 한다. 결국 전자서명에서 처럼 URI Scheme Callback
방식을 통하여 실행시킬 수는 있으나 이용자가 직접 키보드 보안 및 백신 프로그램을
실행해야 한다. 이외에도 Windows에서만 가능하지만 장애인접근성을 해결하기 위해 도입
된 기술인데 이를 응용하여 정보전달 수단인 Microsoft Active Accessibility (MSAA) Control
API를 이용한 회피 방법, Localhost loopback 방식(웹 서버 탑재)을 이용한 모니터링 방
식, 브라우저의 메모리 이벤트 모니터링을 확인하기 위해 다른 프로세스에 침투하는
Dll injection 방식 등을 사용할 수 있으나 해커가 레지스트리를 조작하거나 Hooking 함
수를 교체하는 위험성이 있어 운영체제 개발 정책에 따라 언제든지 차단될 위험성이 있
다.
결국 개인방화벽, 키보드보안 및 백신은 현재 상태 정보를 알기 어려우며 지속적인
상태 점검이 필요하기 때문에 서버 연동까지 고려하지 않는 한 문제 해결이 쉽지 않다.
향후 보안을 위해서는 운영체제 애플리케이션 형태로 상시 실행하는 것이 바람직하다.
추가로 키보드 보안의 대체 기술로 각광 받고 있는 가상 키보드의 경우 RCS를 통한
해킹 가능성이 있으므로 화면저장(캡처) 방지기술을 탑재해서 배포하는 것도 고려의 대
상으로 포함시켜야 할 것이다．
- 26 -
1. 개요
인증 기술은 클라이언트와 서버가 인터넷과 같이 통신으로만 연결된 상태에서 서명을
통해 본인의 행위를 신뢰할 수 있도록 지원하는 기술로 이를 통하여 불법 이용자의 접
근을 막고 거래를 허용할 수 있게 된다.
인증 기술은 크게 세가지로 지식기반, 소지(토큰)기반, 생체기반으로 나눌 수 있으며, 공
인인증서의 경우 지식기반의 대표적인 예이며, 소지기반의 경우 OTP(One Time Password)
토큰이 대표적인 예이다. 최근 사용되고 있는 생체 기반의 경우 생체학적 특징 중 가장
일반적인 지문인식 및 홍채인증이 사용되고 있다.
국내 인증(전자서명)의 경우 대부분 지식기반인 공인인증서를 통한 본인확인을 하고 있
으며 서버 방식을 통한 전자서명과 본인 인증 기술 보급은 미약한 상황이다. 해외의 경우
HTTPS를 통해 서버 인증서에 해당 도메인이나 주소를 포함하여 접속 서버와 인증서를 상
호 인증하는 방식을 대부분 사용하고 있다. 인터넷 상거래나 인터넷 트랜잭션 보호에서
인증 기술은 안전한 키 분배를 위한 수단으로 사용되기도 하고 서버에 접근하는 이용자를
명확하게 식별하기 위한 수단으로 사용하고 있다.
최근 기존 공인인증서를 보완하는 기술로 서버에서 자동으로 지시하는 랜덤 값 문자(이
미지)를 자신의 ID 또는 패스워드와 혼합해 입력한 후 서버로 전달하면 서버는 지시 문자
를 제외한 입력 값을 자동 추출한 후 로그인을 수행하는 방법이나, OTP를 내장한 스마트
카드, 보안 토큰, FIDO(Fast Identity Online) 국제 표준 기술 규격을 준수하는 생체 인증을
통한 이중보완 방법으로 사용하는 2채널 인증 방식을 통하여 본인확인 및 전자서명을 강
화하는 방법 등이 상용화되고 있다.
2 인증
- 27 -
2. 사용 현황
현재 인터넷 환경에서의 인증 부분은 본인 확인보다 결제 등에서 사용되는 전자서명
의 부인방지 부분에 비중을 많이 활용되고 있어 공인인증서 대체기술에서 부인방지 기
능이 반드시 제공될 것을 요구하고 있다. 최근 공인인증서 의무 사용이 폐지됨에 따라
전자상거래 시 신용·체크카드로 전자결제를 하는 경우 공인인증서 대체 사용이 자율화
되었으나, 나머지 전자금융거래(보안 가군, 예: 인터넷뱅킹)에는 공인인증서 또는 공인인
증서 수준의 안전성을 갖춘 인증 방법을 대체할 수 있는 기술 요구되고 있다. 현재 예
외가 되는 경우는 1회, 1일 거래한도를 적정선으로 낮춘 경우만 가능하며, 대부분의 모
바일 간편 결제가 이에 해당한다.
현재까지 공인전자서명을 구현하고 인증서 운영 및 보호를 위해서는 ActiveX, NPAPI
이외에도 별도의 확장 기술(URI Scheme, 로컬 웹 서버, dll injection)을 필요로 한다. 이
는 브라우저 개발사가 국내의 특수한 인증서 운영 환경을 고려한 추가 기능을 제공하지
않기 때문이며. 결국 운영체제 개발사 및 브라우저 개발사의 기술 정책 변경에 의해 별
도의 확장 기술이 퇴출되면 현재 ActiveX 나 NPAPI 퇴출 문제와 같이 또 다른 기술 방
식을 개발해야 하는 악순환이 반복될 수 있다.
결국 은행(정보 변경, 이체 실행), 카드사의 전자상거래에서 거래 사실 확인 및 부인
방지를 위해 사용하고 있는 공인인증서를 대체하거나 일체 설치 파일이나 실행 파일 없
이 웹 표준 방식으로 변경하면서, 2-Factor 인증과 같은 두 단계의 인증 체계를 통해 부
정 사용을 보완하는 방식을 선택하고 현재 사용하고 있는 비표준 확장 기술을 퇴출할
때이다.
최근 브라우저 플러그인을 사용하지 않고 웹 표준 구현기술만을 활용하는 공인인증서
발급 및 이용 기술이 개발되고 있으며, 몇몇 은행에서는 본인 확인을 위한 스마트 OTP
카드 등의 대체 기술을 보급하고 있다.
<표 2-2> 주요 인증방법
인증 방법 설명
공인인증서여러 가지 인증방법 중 하나로서 사전에 발급받은 공인인증서와 비밀번호를
통해 신용카드 결제 인증
구 인증신용카드 번호, 카드 비밀번호 앞 2자리와 생년월일(2014년 8월 이전에는 주민
번호 뒤 7자리 또는 사업자번호)로 카드소유자 확인을 하는 인증방법
- 28 -
2.1 본인 확인
본인 확인은 기본적으로 대면 인증을 통한 최초 인증과 이후 비대면 인증을 통한 사
후 인증으로 구분할 수 있다. 현재 본인 확인 방식은 공인인증서를 통한 방식이 일반적
으로 사용되고 있으며, 지난 10여년 동안 인증서를 운영하는 기술이 특정 운영체제 및
브라우저 의존성이 강한 비표준 기술로 운용되었으며, 로그인, 아이핀 등 공공기관에서
인증 심사를 하고 인증 전문업체가 솔루션을 제공하는 방식으로 인증의 안전성을 보장
하였다.
최근 간편 결제가 활성화 되면서 휴대폰 번호, 카드 번호, OTP 등 기존 지식기반(What
you know)에서 인증 매체의 소지 편의성이 높은 기기를 활용한 ARS 확인과 같은 소지
기반(What you have), 생체 인식 기반(Biometrics)으로 본인확인 수단이나 보안 방법을
보호하기 위한 기술이 활성화되고 있다.
또한 하나 이상의 본인 확인 인증 방식을 결합하여 2단계로 인증을 진행하는 2-Factor
방식을 사용하여 SMS 인증 후 OTP 인증을 추가로 수행하는 방법, 지문인식 후 OTP 인
증을 추가로 수행하는 방법, PKI 토큰을 이용한 비밀번호 입력 후 OTP 인증을 수행하는
방법으로 본인 확인을 강화하는 추세이다.
안심클릭 인증
카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 안심클릭 인증
정보를 생성하고 이용자가 등록된 올바른 인증 정보를 제공할 수 있는지 여부로
본인확인
ISP 인증
카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 ISP 인증 정보
를 생성하고 이용자가 등록된 올바른 ISP 인증 정보에 근거하여 생성한 전자
서명(Digital Signature)을 서버에서 검증하여 본인확인
AA 인증
랜덤한 승인금액을 생성하여 이용자가 승인금액이 얼마였는지 알아낼 수 있는
지 여부로 본인 확인 또는 승인금액을 고정하고 가맹점 명칭에 포함된 랜덤코
드를 이용자가 알아낼 수 있는지 여부로 본인확인
ARS 인증
카드사에서 이용자가 사전에 지정한 전화번호로 전화를 걸어 본인 확인을 하
는 형태로, ARS시스템에 의해 자동으로 이용자에게 전화가 걸리며, ARS 멘트
로 거래 내역 사실이 이용자에게 안내되면 확인 후, 최종적으로 고객이 승인
- 29 -
2.2 공인인증서(전자서명)
공인인증서의 경우 웹브라우저의 확장기능을 배제하고 W3C가 제정한 웹 표준 구현
기술만을 활용하여 브라우저의 로컬저장소(localStorage)에 공인인증서를 저장하고 전자
서명을 받는 방식(Agentless)으로 서비스를 제공할 수 있다. 웹 표준 기반 공인인증서 서
비스는 운영체제, 웹브라우저, 단말기에 상관없이 웹을 통해 공인인증서를 발급받아 이
용하고자 하는 모든 서비스에 적용하고. 공인인증서 이용방식을 웹 표준으로 구현함으
로써 사용자가 별도의 공인인증서 소프트웨어를 설치하지 않아, 이용불편과 접근성이
해소될 것으로 보인다. 특히 데스크탑, 스마트폰, 스마트 TV 등 웹 브라우징이 가능한
모든 환경에서 공인인증서를 이용할 수 있는 장점이 있으나 공인인증서 운용(발급, 저
장, 이용, 갱신, 폐기) 및 보호를 위한 확장 기술 기반의 Agent 미설치로 인해 로컬저장
소를 이용함에 따른 보안성 저하 문제와 웹 표준 구현기술인 자바스크립트를 이용함으
로 발생할 수 있는 웹 취약점 관련한 문제에 대해서는 적절한 보완이 필요하여 현재 이
를 보완하는 방식으로 2-Factor 인증 방식인 OTP 보안 매체를 활용한 추가적인 본인
확인 절차를 수행하는 서비스를 제공하고 있다.
3. 대체 기술
사용자 본인 확인을 위한 대체 기술은 대부분 공인인증서를 통한 로그인 인증과 금융
거래의 무결성 확인 및 거래사실 부인방지를 위한 전자서명 용도로 사용되고 있어“웹
표준 기반의 공인인증서”운용 방식에 대한 기술과 공인인증서를 사용하지 않고 본인확
인 및 부인방지를 하며 무결성을 보장하는“대체 인증 수단”,“인증 관련 기술적 보완
방식”등 세가지 방향으로 구분할 수 있다.
본인 확인 및 전자서명을 위한 웹 표준 기반의 공인인증서 운용 방식에 대한 기술은 보
안 위협에 대처하기 위한 자바스크립트 샌드박스, 웹 콘텐츠 보호(W3C CSP), 자바스크립
트 동적로딩, 자바스크립트 난독화 및 암호화, 자바스크립트 무결성 검사, WebCryptoAPI
등의 보호 수단을 적용해서 개발해야 한다.
공인인증서를 사용하지 않고 본인 확인 및 부인방지를 하는 기술은 이용자가 가지고
있는 것으로 식별하는 OTP, 보안카드 등이 있고 이용자가 알고 있는 것으로 식별하는
패스워드, 사이트 키(Site Key) 등이 있다. 이와 별도로 이용자 신체의 특징이 되는 지문,
홍채, 정맥 등이 있고 이용자 행동의 특징인 입력 리듬, 필체 등이 있다. 그러나 이중에
- 30 -
충분한 안전성을 확보 하면서 인터넷상에서 사용할 수 있는 기술로 받아들여지는 것은
공인인증서, OTP 정도를 일반적으로 사용하고 있다. 이러한 공인인증서를 사용하지 않
는 본인 확인 및 부인방지 기술은 초기 구매 비용이나 개인정보보호 문제로 보급 확산
과 사용에 제약이 있는 상황이다.
인증 관련 기술적 보완 방안은 일반 운영체제나 브라우저에 인증서를 사전 탑재하는
방식과 FIDO(Fast IDentity Online)와 같은 생체인증, 기존 인증방식의 연동 방식, 이상거
래탐지시스템(FDS)을 활용되고 있다.
거래사실 부인방지는 이용자에 대한 신뢰를 바탕으로 이용자가 본질적으로 거래한 사
실이 없다면 이용자의 손해를 보전하는 방향으로 발전해야 하며 거래사실이 있지만 이
용자가 부인하는 경우 정황증거(로그 등)나 제3자를 활용하여 이용자를 설득할 수 있도
록 해야 한다.
마지막으로 인증방식은 거래 리스크나 신용 정보에 따라 각기 다른 방식을 채택하고,
이용자가 선호하는 인증 방식을 선택할 수 있는 다양성을 확보하는 것이 바람직하며,
인증이 필요한 영역별로 분할된 인증 방식을 적용하는 것도 고려해야 한다.
3.1 웹 표준 기반 공인인증서
가. 브라우저에 인증서 탑재
브라우저 로컬저장소에 공인인증서를 저장하고 웹 서비스를 통해 전자서명을 지원하
는 방식으로, 기존의 공인인증서를 하드디스크나 별도의 메모리 장치(USB)에 저장하던
방식에서 사용하던 비표준 플러그인 설치가 없는 장점이 있는 반면, 본인 확인 및 거래
안전성 보강을 위한 OTP와 같은 추가 인증 방식이 필요하다. 이 방식을 사용할 경우 기
본적으로 로컬저장소는 웹 암호 API 적용 등을 고려하여 웹 스토리지를 사용 시 인증서
보호 기술을 적용하는 것을 우선적으로 권고하고 있다.
- 31 -
[그림 2-7] 웹 표준 기반 공인인증서 서비스 모델 제시
웹 표준 기반 공인인증서 서비스를 위해서는 공인인증기관은 공인인증서 발급을 별도
통신채널과 Protocol을 사용하지 않고 브라우저만으로 발급할 수 있도록 시스템을 갖추
고, 전자거래, 전자민원 등 이용기관은 발급‧저장된 공인인증서를 이용하여 전자서명문
을 생성할 수 있도록 웹 페이지 내에 기능을 구현하여야 한다. 또한 공인인증기관 및
보안업체는 안전한 공인인증서 저장을 위해 다양한 저장매체를 도입하고 웹 표준과 연
동하여야 한다.
나. 공인인증서 발급
기존에 브라우저 플러그인을 통해 발급하던 공인인증서를 웹 표준 구현기술 만으로
발급하기 위해서는 공인인증기관의 발급시스템과 Protocol의 변경, 클라이언트인 브라우
저에서의 발급기능 구현이 필요하다. 공인인증기관은 HTTP를 통해 발급할 수 있도록
발급방식을 변경하고, 브라우저에서는 전자서명키 쌍과 인증서 요청양식의 생성, 응답을
처리하여 저장하는 기능 등을 구현하여야 한다. 또한 공인인증기관은 브라우저만으로
공인인증서를 발급하기 위해서는 발급시스템에 대한 변경이 필요하다. 공인인증서의 발
급과 관리는 발급시스템과 클라이언트 간의 요청과 응답을 위한 메시지를 통해 이루어
지며, 이 때 메시지는 특정 Protocol이 아닌 HTTP(또는 HTTPS)를 통해 전송되어야 한다.
- 32 -
기존 공인인증서 발급시스템을 활용하고 웹 표준을 적용할 수 있는 방법은‘HTTP Transfer
for the Certificate Management Protocol’를 준용하는 것이다. [RFC6712] 공인인증서 발
급‧관리와 관련한 모든 요청과 응답은 HTTP를 통해 PKIMessage로 처리 가능하며 기존
발급시스템의 활용 또한 가능하다.
RFC6712를 준용하기 위해서, CMP(Certificate Management Protocol) 메시지는 반드시
HTTP를 사용하여야 하며 HTTP/1.0, HTTP/1.1을 모두 지원해야 한다. 또한 GET이 아닌
POST방식만을 사용하여 메시지를 전송하여야 한다. PKIMessage를 전송하는 동안 HTTP
헤더의 콘텐츠 타입으로 application/pkixcmp로 설정하여야 한다.
DER 인코딩 ITU.X690.1994된 PKI Message RFC4210는 HTTP POST 요청을 본문에 담
아 보내며 HTTP 요청이 성공하면 서버는 HTTP 응답에 CMP 응답메시지를 담아 보낸
다. 이 경우 HTTP 응답코드는 200이어야 하며 요청 성공과 관련한 다른 응답코드(2XX)
는 이 경우 사용해선 안 된다.
더 상세한 표준내용은 [RFC6712], [RFC4210] 등의 표준문서를 참고해야 하며, 관련 표
준 규격 이외에도 기존 발급 프로세스에 대한 변경도 고려해야 한다.
다. WebCryptography API 활용
웹 암호(WebCryptography) API의 경우 현재 표준규격(W3C Proposed Recommendation)
제정이 되었고, 일부 최신 브라우저에는 관련 기능이 탑재되어 있어 사용이 가능하며 htt
p://caniuse.com/#feat=cryptography에서 브라우저 버전별 웹 암호 API 지원 정보를 얻을
수 있다.
- 33 -
<표 2-3> 브라우저별 웹 암호 API
아래와 같이 WebCryptography API를 사용하여 전자서명키 쌍을 생성할 수 있다.
[예시 : 웹 암호 API 사용 전자서명 키쌍 생성 ]
브라우저 명 웹 암호 API 소개 페이지
인터넷 익스플로러(Edge, IE 11) http://msdn.microsoft.com/ko-kr/library/ie/dn265046(v=vs.85).aspx
크롬http://www.chromestatus.com/features/5030265697075200 https://code.google.com/p/chromium/issues/detail?id=245025
파이어폭스https://developer.mozilla.org/ko/docs/Web/API/Window/cryptohttps://bugzilla.mozilla.org/show_bug.cgi?id=865789
사파리(웹킷)http://blog.engelke.com/tag/webcrypto/https://bugs.webkit.org/show_bug.cgi?id=122679http://nightly.webkit.org/
var subtle = window.crypto.subtle;
var publicKey;
var privateKey;
var extractable = false;
var algorithmKeyGen = {
name: "RSASSA-PKCS1-v1_5",
modulusLength: 2048,
publicExponent: new Uint8Array([0x01, 0x00, 0x01]), // Equivalent to 65537
hash: {
name: "SHA-256",
}
};
subtle.generateKey(algorithmKeyGen , extractable, ['sign']).then( function(e) {
publicKey = new crypto.key(e.publicKey);
privateKey = new crypto.key(e.privateKey);
resultCallback ( {
publicKey: publicKey,
privateKey: privateKey
} );
}, function(e) {
resultCallback(new crypto.error(e));
} );
- 34 -
생성된 키쌍을 이용하여 전자서명을 수행하는 것은 다음과 같다.
var subtle = window.crypto.subtle;
var algorithmSign = {
name: "RSASSA-PKCS1-v1_5"
};
plain = crypto.util.stringToArraybuffer(input);
Subtle.sign(algorithmSign, privkey, plain.buffer).then(
function(e) {
resultCallback(crypto.util.arrayBufferToString(e));
}, function(e) {
resultCallback(new cryoto.error(e));
}
);
웹 암호 API이외에도 암호화 통신 알고리즘을 안전하게 사용하기 위해서는 보안 결함이
발견된 SHA(Secure Hash Algorithm)-1 해싱 알고리즘은 더 이상 사용하지 말아야 한다.
2016년 1월 1일 이후 브라우저 개발사(Microsoft, Google, Mozilla)는 SHA-1 서명 인증서에
대한 신뢰중단이 되었으며, 기존 SHA-1로 서명 발급된 모든 SSL, CA 인증서는 신뢰를 보장
할 수 없다. 따라서 2016년 1월 1일 이전에 기존 SHA-1을 SHA-2 알고리즘 기반 인증서로
반드시 재발급 및 갱신해야 한다.
(SHA-2 전환일정 : https://www.ucert.co.kr/ssl/sha2-timeline.html)
웹 암호 API에 관한 보다 상세한 내용은 현재 표준화가 진행 중인 W3C Web Cryptography
API(http://www.w3.org/TR/WebCryptoAPI/)를 참고할 수 있다.
라. 공인인증서 저장
비표준 플러그인 기반의 기존 공인인증서 저장 환경은 주로 하드디스크와 이동식 디스
크 내의 /NPKI/ 디렉토리에 저장되었다. 하지만 웹 표준 환경에서는 별도 플러그인을 사용
하지 못하고 웹 표준 File API의 경우 디렉토리 접근이 자유롭지 않기 때문에 기존 방식으
로 저장하는 것은 어렵다. 웹 표준 방식으로 공인인증서를 발급 받은 후 저장할 수 있는
저장매체는 브라우저 내의 웹 저장소, 보안토큰, 소프트토큰, 스마트인증 등이 있다.
- 35 -
[그림 2-8] 공인인증서 저장매체
- 웹 스토리지(WebStorage)
공개키 HTML5의 웹 스토리지(Web Storage)는 HTML5 표준으로 웹 사이트의 데이
터를 브라우저에 저장할 수 있는 새로운 자료구조로서 기존 쿠키(Cookie)의 단
점을 개선하기 위해 개발되었다. 현재 웹 스토리지는 모든 브라우저에서 지원
가능하며 저장된 데이터는 서버로 전송되지 않는다. 웹 스토리지는 클라이언트
디바이스에 직접 저장되고 네트워크로 전송되지 않기 때문에 네트워크 레벨에
서는 안전할 수 있다. 웹 스토리지는 물리적으로는 파일로 저장되며, 이용자 계정
하위 디렉토리에 저장된다. 웹 페이지가 브라우저에 랜더링 되기 전에 브라우저는
물리적으로 저장되어 있는 데이터를 읽어 메모리에 올려둔다. 브라우저 개발자 도
구 등을 통해 웹 스토리지에 저장된 데이터 접근이 가능하며, 수정 및 삭제가
가능하다.
공인인증서와 개인키를 웹 스토리지에 저장하고자 하는 경우, 세션 스토리지는
데이터가 영구적으로 저장되지 않아 사용이 어렵다. 로컬 스토리지의 경우에도
이용자가 브라우저 메뉴 등을 통해 삭제하거나 브라우저 개발도구 등을 통해
임의 수정이 가능하다. 따라서 웹 스토리지에 공인인증서를 저장하는 경우 이용
자 인증 등 추가적인 보안 수단과 인증서 보호 방안을 강구하여야 한다. 또한
물리적으로는 이용자 계정 하위 디렉토리에 파일로 저장되며 웹 암호 API로 생
성된 Key 객체의 경우 저장되지 않아 웹 암호 API를 이용하는 경우 데이터 변
환 및 위변조 가능성에 대한 주의가 필요하다.
- 36 -
- 인덱싱된 데이터베이스(IndexedDB)
웹 스토리지가 용량이 작고 구조화된 데이터를 다루기엔 부족하기 때문에 브라우저
에서 많은 양의 구조화된 데이터를 영구적으로 저장하여 검색 및 이용할 수 있도록
만든 HTML5 API가 인덱싱된 데이터베이스(IndexedDB)이다.
IndexedDB는 기본적으로 자바스크립트 객체(Object)를 저장하며 기존 RDBMS(관계형
데이터베이스 관리 시스템)와는 다르게 Object Store를 만들고 자바스크립트를 통해
저장한다. SQL과는 개념이 비슷하나 쿼리 대신 Index를 사용하는 것이 차이점이
다. 웹 스토리지와 마찬가지로 동일출처정책에 따라 해당 도메인만 접근 가능
한 저장소이다. 각각의 데이터 항목 크기나 데이터베이스 자체의 크기 제한을
두지 않지만, 브라우저는 저장용량 제한을 둘 수도 있다.
[그림 2-9] IndexedDB에 공인인증서 저장 예
웹 스토리지와 마찬가지로 클라이언트 디바이스에 직접 저장되고 네트워크로는
전송되지 않는다. IndexedDB 또한 브라우저 개발도구에서 저장된 데이터에 대
한 열람 및 삭제가 가능하다. 따라서 안전한 저장을 위해서는 추가적인 암호화,
이용자 인증 등 다양한 보안 및 안전한 인증서 관리 수단을 강구하여야 한다. 웹
암호 API를 이용하는 경우, 키 객체 저장이 가능한 IndexedDB를 저장소로 이용
- 37 -
할 수 있다. IndexedDB에 웹 암호 API를 이용해 생성된 키 객체 등을 저장하는
경우 웹 스토리지와는 달리 별도의 데이터 변환 등이 필요치 않다.
- File API
공인인증서의 발급과 저장에 W3C 웹 표준의 File API를 사용할 수도 있다. 발급받은
공인인증서와 개인키를 [PKCS12]로 변환한 후 mime-type을 application /x-pkcs12로
설정하여 이용자 단말기로 다운로드 할 수 있으며, 이용자는 다운로드 된 [PKCS12]
파일 .p12 또는 .pfx 파일을 브라우저에서 이용할 수 있다.
mime-type 설정을 이용한 다운로드 방식 이외에도 W3C File Writer API를 이용할
수 있으나, 현재 표준화가 진행 중에 있어 일부 브라우저에서만 한정적으로 지
원되고 있다. File Writer API를 이용하는 경우 이용자가 파일 다이얼로그 박스로
파일을 선택하는 것보다 브라우저를 이용하여 비교적 자유롭게 .p12, pfx 파일을
처리할 수 있다. 또한 브라우저의 Drag&Drop 기능과 결합하여 이용자 단말기의
파일시스템에 [PKCS12]로 저장한 인증서를 브라우저에서 편리하게 이용할 수 있다.
Drag&Drop은 대부분의 브라우저에서 지원 가능하며, 이용페이지에서 전자서명이
요구되는 경우 [PKCS12] 파일을 이용자가 Drag&Drop으로 이용페이지에 넣고
비밀번호를 입력함으로써 전자서명 처리가 가능해진다.
File API를 이용하여 파일 형태로 공인인증서와 개인키를 저장하여 이용하는 경우,
인증서 및 키 파일에 대해 사용자가 관리해야 하는 불편함 등이 발생할 수 있
으며, 복사·유출·분실 등에 대한 위험이 여전히 존재한다.
- 보안토큰(HSM)
보안토큰은 하드웨어 장치 내에서 공인인증서를 생성 및 저장하고 전자서명을
수행하는 USB 인터페이스를 갖춘 개인 휴대용 저장매체(대부분 보안 USB나 휴
대폰 USIM 활용)를 말한다. 보안토큰은 하드웨어 칩 기반으로 공인인증서 및 개
인키를 보관하고 전자서명 등 암호 연상기능을 수행함에 따라 전자서명 생성 요청
에 대해 보안토큰은 내부의 개인키를 이용하여 전자서명을 생성하고 결과 값만을
보안토큰 외부로 전달한다. 결과적으로 공인인증서와 관련한 모든 연산을 보안
토큰 칩 내부에서 수행함으로써 개인키에 대한 유출 위험이 최소화 된다.
- 38 -
보안토큰을 이용하기 위해서는 PKCS11 표준 API를 사용하여야 한다. 따라서 하
드웨어 장치에 대한 드라이버 프로그램과 이용을 위한 표준 API의 설치가 필요
하다. 또한 웹 페이지 내 데이터에 대해 전자서명하기 위해서는 브라우저와의
연동이 필요하나 현재 플러그인 없이 브라우저에서 보안토큰 하드웨어 매체에
접근하거나 브라우저에 데이터를 연동하는 것은 불가능하다. 이와 관련한 표준
제정 논의가 진행되고 있으나 현재로서는 별도의 실행 파일 기반의 소프트웨어
설치가 필요하며, 최근 로컬서버로 작동하는 별도 소프트웨어를 설치하는 방법이
이용되고 있다. 본 안내서에서는 로컬서버를 활용하는 방법에 대해 기술한다.
로컬서버 방식은 브라우저가 로컬PC에 설치된 소프트웨어에 접속하여 전자서명을
요청하고 응답을 처리하는 방식이다. 유럽에서 많이 사용되고 있는 e-ID에서도
이와 같은 방식으로 e-ID 카드리더기와 브라우저 간 연동을 처리한다.
PC에 설치되어 브라우저와 연동되는 보안토큰 클라이언트 소프트웨어는 단일 소프
트웨어로 구현될 수 있으며, 다음과 같이 편의상 여러 개의 모듈로 나뉠 수 있다.
[그림 2-10] 보안토큰과 브라우저 간 연동 모델
브라우저는 보안토큰 클라이언트에 HTTP(또는 HTTPS) 접속 후 JSON 타입의 명령
어를 전달함으로써 보안토큰을 이용한 공인인증 서비스를 제공하게 된다. 로컬서버
와 통신하기 위한 포트는 8443포트를 사용하며, XMLHTTPRequest(이하 XHR) 등을
활용한다.
- 39 -
- 소프트 보안토큰(HSM)
공인인증서를 안전하게 저장·이용하는 보안토큰과 같은 물리적 하드웨어 매체가
작동하는 방식을 소프트웨어로 구현한 것이 소프트웨어 방식의 보안토큰 즉, 소프
트토큰이다.
소프트토큰을 브라우저와 연동하기 위해서는 보안토큰과 동일한 연동방식을 이용
할 수 있으며, 별도의 연동방식을 이용할 수 있다. 소프트토큰은 브라우저 이외에도
모바일 소프트 토큰, PC 소프트 토큰 등의 실행파일 기반에서 사용할 수 있다.
- 스마트인증(Smart HSM)
스마트인증은 스마트폰과 같은 모바일 기기의 USIM, eSE 등 보안모듈을 모바일
통신을 통해 PC와 같은 타 기기에 연결하여 전자서명 생성키 등 비밀정보를 안
전하게 저장 및 보관하고 키 생성 및 전자서명 생성 등을 처리하는 하드웨어와
소프트웨어를 총칭하는 것이다.
기존 스마트인증 서비스는 보안토큰 인터페이스와 동일하게 만들고 브라우저
플러그인을 통해 서비스가 되었으나, 플러그인 없이 동작하기 위해서는 별도의
연동방법이 필요하다. HTML5 WebRTC를 활용한 방법, 외부의 서버를 통한 방법
등 다양한 연동방법이 가능하다.
[그림 2-11] 스마트인증 이용 절차 예시
target.contentWindow.postMessage(JSON-Message, https://127.0.0.1:8443);
- 40 -
마. 공인인증서 이용
브라우저를 통해 발급된 인증서를 이용하기 위해서는 각 저장매체에 저장된 인증서
목록을 조회하고 해당 인증서를 이용하여 전자서명문을 생성하는 기능의 구현이 필요하
다. 하지만 브라우저 샌드박스 보안정책, 동일출처정책으로 인해 브라우저 내의 웹 스토리
지에 저장된 인증서를 이용하는 경우 제약이 발생한다. 이에 본 안내서는 웹 스토리지나 인
덱스DB에 공인인증서를 발급‧저장한 경우 동일출처(Same-Origin)와 교차출처(Cross-Origin)
환경에서 공인인증서를 이용하는 방법을 기술한다.
- 동일출처(Same-Origin)정책 환경에서 공인인증서 사용
동일출처정책은 한 개의 URI 출처(Origin)에서 문서나 스크립트가 다른 URI 출처 자원과
상호작용을 하지 못하도록 제한하는 보안정책이다. 두 웹 페이지의 Protocol, 호스트, 포
트가 동일하면 동일출처(Same-Origin)이며, 하나만 달라져도 다른 출처로 처리된다.
공인인증서 저장매체로 웹 스토리지를 이용하는 경우는 동일출처정책 영향을 받게
되며, 이로 인해 공인인증서를 발급한 웹 사이트(이하 발급사이트)와 공인인증서를
이용하는 웹 사이트(이하 이용사이트)가 상이한 경우 발급된 공인인증서를 이용
하지 못하는 제약사항이 발생한다.
따라서 동일출처 환경으로만 공인인증서 발급과 이용을 제한하거나, 동일출처 환
경에서 발급된 공인인증서를 타 웹 사이트에서 이용할 수 있는 기능을 제공할 수
있다. 이 경우 웹 스토리지에 발급된 인증서를 PKCS12 형식의 파일로 내보내고 타
웹 사이트에서 해당 파일을 불러와 사용하는 등 다양한 방안이 이용될 수 있다.
공인인증서의 발급과 저장이 PKCS12로 이루어지고, 이용사이트에서 Drag&Drop방식으
로 공인인증서가 이용되는 경우, 동일출처 및 교차출처 여부와 관계없이 이용이 가능
하나 공인인증서의 저장 및 이용 관리에 대해 사업자 및 사용자의 주의가 필요하다.
[그림 2-12] Same-Origin 환경에서의 공인인증서 이용
- 41 -
- 교차출처(Cross -Origin) 환경에서 공인인증서 사용
인증서 발급사이트와 이용사이트가 다른 Cross-Origin 환경 하의 이용사이트에서
발급사이트의 웹 스토리지에 발급된 공인인증서를 이용하기 위해서 HTML5 Web
Messaging 표준이 활용될 수 있다. 발급사이트와 이용사이트 간에 postMessage
통신을 통해 발급사이트에서 생성된 전자서명문을 이용사이트에 전송함으로써 공인인
증서를 이용할 수 있다. 이 경우 전송되는 메시지는 암호화하여 JavaScript injection
취약점에 대비해야 한다.
[그림 2-13] 공인인증서 상호연동
Web Messaging은 기존 HTML에 없던 메시지 통신방식으로 HTML5에서 새로 추가
되었다. 이는 일반적인 Windows API에서 사용하던 메시지 이벤트를 이용하는 방식과
거의 동일한 형태이다. Web Messaging을 이용하는 일반적인 방식은 다음과 같다.
a. postMessage( )를 이용하여 메시지를 목표의 메시지큐에 넣는다.
b. dispatch를 통하여 메시지큐에서 메시지를 추출하여 목표에 전달한다.
c. onmessage 이벤트 핸들러에서 메시지를 받아서 처리한다.
- 42 -
[그림 2-14] Web Messaging 메시지 통신 기능
Web Messaging은 cross-document messaging과 channel-messaging 두 가지 방식이
있으며, postMessage 메소드의 정의는 다음과 같다.
- 웹 표준 기반 공인인증 서비스의 보호
웹 표준으로 구현되는 공인인증서 발급 및 이용 기능은 웹 취약점에 대한 보호, 자바
스크립트 소스에 대한 보호, 통신 구간에 대한 보호, 저장소에 대한 보호 기능을 필
요로 한다. 또한 공인인증서를 브라우저 내에 저장하는 경우 피싱, 파밍 등에 대한
대비가 필요하다. 이와 같은 보안위협에 대처하기 위해서 자바스크립트 샌드박스, 웹
콘텐츠 보호(W3C CSP), 자바스크립트 동적 로딩, 자바스크립트 난독화 및 암호화, 자
바스크립트 무결성 검사, 저장소의 해킹 여부 판별, 유출 여부 판별 확인 등의 보호
및 검증 수단을 강구해야 한다.
windows.postMessage(message, targetOrigin, [ports]);
message : 송신 메시지
targetOrigin : 목적지 도메인, 메시지 수신 도메인 지정, 특정 도메인이 아닌 경우 ‘*’ 지정
ports: 메시지 포트(생략 가능)
- 43 -
<표 2-4> 해킹 및 금융사기 주요 기법
3.2 대체 인증 수단
가. 대체 인증 기술
금융위원회는 전자금융감독규정 제37조 개정을 통해 “금융회사 또는 전자 금융업자
는 전자금융거래의 종류·성격·위험수준 등을 고려하여 안전한 인증방법을 사용하여야
한다”로 변경했다. 이는 공인인증서 또는 이와 동등한 수준의 안정성을 보장할 경우
다양한 인증, 보안 기술을 활용할 수 있는 기반을 마련한 계기가 되었으며, 현재 대체인
증 기술로 생체인증, OTP인증, 신분증 인증, 간접 인증, 대면 인증 등 다양한 대안을 조
기법 설명
키로거 사용자의 키보드 입력정보를 몰래 수집하고 외부로 전송하는 프로그램
트로이목마
사용자가 인지하지 못한 상태에서 파일, 입력정보 및 네트워크 전송 정보를
수집하거나 임의의 명령어를 실행하는 등의 악성행위를 목적으로 개발된
프로그램
메모리해킹실행 중인 프로그램의 메모리 영역에 접근하여 중요정보를 추출하거나
변조하는 기법
MITM네트워크 구간이나 프로그램 내부 데이터 전송 구간에서 전송되는 정보를
수집 변조하는 기법
후킹프로세스 등을 대상으로 내부에 삽입되어 데이터의 흐름을 변경하거나
데이터 자체를 변조하는 기법
스미싱SMS나 피싱이 결합된 용어로 피싱 SMS를 전송하여 사용자가 특정 사이트에
접속하거나 악성 앱을 설치하도록 유도하는 기법
보이스피싱전화를 통해 기관을 사칭하거나 음성과 개인정보를 이용하여 금융정보를
수집하고 현금을 인출하는 형태의 금융사기
피싱이메일 등을 통해 정상적인 사이트로 위조된 변조 사이트에 접속을 유도하여
개인정보 및 금융 정보를 수집하는 기법
파밍DNS 설정변경 등을 통해 정상적인 사이트로의 접근을 위조된 사이트로
접속시켜 개인정보 및 금융 정보를 수집하는 기법
- 44 -
합하여 사용하고 있으나, 충분한 안전성을 확보 하면서 인터넷상에서 사용할 수 있는
기술로 받아들여지는 것은 인증서, OTP정도이고 나머지는 보조적인 수단으로 사용되고
있다. 현재 대체인증수단의 경우 인터넷, 모바일의 본인 및 결재 인증 용도로 사용하는 데
있어 비용적으로나 개인정보보호 문제로 일부 사용에 제약 및 보완이 필요한 상황이다.
<표 2-5> 대체 인증 방식
인증 방식 세부 인증 기술 설명
생체 인증
지문인식 인증 등록된 이용자의 지문일치 여부로 인증
화자 인증음성인식과 구분되며 말하는 사람이 예전 등록된
화자와 일치하는지 여부 확인
서명 인증 이용자의 서명 특성에 기반하여 인증
기타 홍체 인식, 심박 특성, 음성 특성 인증 등
키입력 패턴 인증 동작 제스처 인증 사용자 패턴을 사전에 등록 인증에 활용
특징기반 추론인증 질문에 대한 답을 유도하는 QA 활용
신분증 인증여권 주민증, 면허증 등 신분증을 업로드하여 인증,
얼굴 인증과 결합 사용 가능
AML KYC체크리스트에 의한 인증, 다양한 체크 Factor로 거래
상대방의 신뢰성, 진위여부를 인증
간접인증
정보 소유자가 해당 정보를 확인해낼 수 있는지 여부
로 인증, 이메일 인증, 문자 인증, ARS 인증, CallerID
인증 등의 비금융 정보 기반 인증과 신용카드 금액
인증, 계좌 1원이체후 소유주 확인증 금융정보 기반
인증으로 구분 가능
평판이력 인증의 보조수단으로 사용. SNS 계정 평판, 검색 평판 조회
간접 대면 인증
우편 수신 여부로 인증, 다른 신분증의 특성정보를
이용한 인증
(신분증을 갖고 있는 사람만이 제시 가능한 정보 요구)
카드 인증3D Secure, CVC, ARS등 신용카드 정보에 기반한
인증
OTP 토큰 인증일회용 비밀번호를 발생기를 이용한 인증, 최근 신용
카드 일체형으로 카드 인증과 병행해서 2-factor 인증
- 45 -
나. FIDO(Fast IDentity Online) 생체 인증
최근 애플, 삼성을 시작으로 바이오메트릭(biometric) 즉 생체 정보를 활용한 솔루션이 스
마트폰 결제 인증에도 사용되기 시작하고 있으며, 생체 인증 기술 표준화의 중심에 FIDO
얼라이언스(Alliance)가 있다. FIDO 얼라이언스는 온라인 환경에서 생체인식기술을 활용한
인증방식에 대한 개방형 기술표준을 정하기 위해 2012년 두 가지 표준으로 구성되었으
며, 현재 아이디와 패스워드 방식 대신에 상대적으로 탈취하기 어려운 개인의 고유한 생
체 정보 즉 음성, 지문 및 얼굴 인식 등을 인증 과정에 사용하는 비(非) 비밀번호 인증
표준인 UAF(Universal Authentication Framework) 방식과 기존 아이디, 패스워드 인증 방
식과 함께 추가의 보안 정보를 보관하는 USB 동글 및 스마트카드와 같은 별도의 인증
장치를 사용하는 이중 인증인 U2F(Universal 2nd Factor) 방식으로 구성되어 있다.
[그림 2-15] FIDO 인증 시나리오
아이디와 패스워드 기반의 인증 방식은 파밍, 메모리 해킹과 같은 기법으로 손쉽게
탈취할 수 있기 때문에 생체 정보를 이용한 인증 기술의 활성화 및 표준화가 필요하며
그 중심에 FIDO와 같은 생체 인증 기술이 있다. 현재 일반적으로 가장 많이 활용되고
있는 아이디, 암호와 같은 지식기반(Something you know) 방식에서, 인증서 및 USB를
활용하는 인증방식인 소유기반(Something you have) 및 생체 정보를 이용하는 생체기반
(Something you are) 방식의 기술 적용 시 국제인증기술 표준 규격에 대해 이해하고 적
용하는 것이 바람직하다.
- 46 -
3.3 인증 관련 기술적 보완 방식
가. 일반 운영체제나 브라우저에서 인증서를 사전 탑재하는 방식
국내의 반 인증서 사용 움직임과 달리 전 세계적으로는 안전한 방식으로 인증서를 사
용하여 인터넷 거래를 가능하게 하려는 움직임이 활발하게 일어나고 있으며 Intel의 하
즈웰 이상 버전에서는 IPT(Identity Protection Technology)기술의 일부로 인증서 저장 방
식이 들어가 있어 별도의 보안토큰 배포 없이도 인증서를 안전하게 사용할 수 있다.
[그림 2-16] TrustZone Hardware Architecture – (http://www.arm.com)
스마트폰의 경우 ARM의 TrustZone 기술을 사용하여 인증서를 안전하게 저장하고 사
용할 수 있는 기술들이 점차 보급되고 있는 상황이다. 그러나 이러한 시스템에 포함된
장치를 통해 공인인증서를 사용하는 데에는 여전히 제약이 따른다. 이는 공인인증서에
서 사용하는 식별번호로 인한 문제로 IPT나 TrustZone에 포함된 기술들은 현재 전 세계
적으로 널리 통용되는 범용 기술까지만 지원하고 있어 식별번호의 추가가 불가능하다.
결국 해당 식별번호 규격을 지원하는 방식으로 변경되기 전까지는 저렴하고 안전한 이런
장치들을 이용하여 HTTPS에 포함된 클라이언트 인증서를 활용한 이용자 인증기능 사용
이 불가하다.
- 47 -
1. 개요
온라인 결제수단의 등장과 스마트폰 확산으로 온라인과 모바일 환경에서 전자상거래
가 일반화 되었다. 또 대부분 안전한 전자상거래를 위해 카드사가 인증하는 다양한 신
용카드 기반의 결제 서비스가 사용되고 있다.
이러한 신용카드 기반의 결제 서비스 기술은 정부의 안전성과 무결성 준수 규정에 따
라 이용자 확인, 서버인증, 통신채널 보호, 통신 데이터 암호화, 거래내역의 위변조 방지,
거래부인방지 기능 등을 지원해야 한다.
2014년 9월부터 금융위원회는“전자상거래 결제 간편화 및 Active-X 해결 방안”및
후속 조치를 통해 안전성과 무결성을 지원하는 전자결제 수단의 경우 전자상거래에서
카드결제 시 공인인증서 의무 사용을 폐지하였다. 이에 따라 카드사나 전자금융업자(PG)
들이 공인인증서 외에 대체 인증방식과 직접 카드정보를 수집, 저장하여 영업에 활용할
수 있는 환경이 마련되었다.
현재는 신용카드 기반의 ISP(Internet Secure Payment), 일반결제 서비스와 스마트폰
간편결제, 휴대폰 소액결제, 전자화폐 등을 활용한 전자결제 서비스가 일반적으로 제공
되고 있으나, 최근 페이팔, 알리페이, 텐페이와 같이 본인에 대한 사전 인증절차를 사후
확인절차로 전환하여 편의성을 제고하는 방식의 One-Click 간편결제와 같은 다양한 전
자결제방법이 확산되고 있다.
특히 모바일카드 방식의 결제는 스마트폰 사용 보편화, 앱(App)방식 카드발급 확대 등
으로 꾸준히 증가하고 있으며, 다양한 모바일 결제 인증 기술들이 적용되고 있다.
3 전자결제
- 48 -
2. 사용 현황
2014년 9월 규제완화 이후 각 업체들은 시장을 선도하기 위해 경쟁적으로 다양한 방
법과 기술을 도입하며 결제 프로세스를 간소화하는 간편 결제가 활성화되면서 다수의
소비자들이 스마트폰을 활용한 간편결제를 이용하면서 시장이 급속도로 성장하고 있다.
현재는 신용카드 기반의 ISP(Internet Secure Payment), 일반결제 서비스와 스마트폰
간편결제, 휴대폰 소액결제, 전자화폐 등을 활용한 전자결제 서비스가 일반적으로 제공
되고 있으나, 최근 페이팔, 알리페이, 텐페이와 같이 본인에 대한 사전 인증절차를 사후
확인절차로 전환하여 편의성을 제고하는 방식의 One-Click 간편결제와 같은 다양한 전
자결제방법이 확산되고 있다.
참고자료 전자상거래 결제 간편화 방안
금융위원회와 금융감독원은 14.7.28 ｢전자상거래 결제 간편화 방안｣을 통해 아래와 같은 내용의 결
제 간편화 방안에 대한 조치를 추진하고 있다.
1. 공인인증서 의무 사용 폐지전자상거래에서 카드결제시 공인인증서 의무사용 폐지
(5.20, 금융위원회)
- 현재 공개키(PKI) 기반 기술을 공인전자서명 방식으로 사용되고 있지만, 전자서명 요건을 충족하
는 다양한 인증 기술을 공인전자서명기술로 인정
- 웹 표준 기반의 공인인증서 기술 개발 및 보급
2. 카드정보 저장 허용과 정보보호
- 기술력･보안성･재무적 능력 등 정보보호 능력(시스템)을 충분히 갖춘 PG사에 대해서 카드정보
저장 허용
- 적격 PG사는 전자상거래 과정에서 카드 회원의 동의 후 수집‧저장
3. 간편 결제 방식 도입 확대
- 대체인증수단 제공 카드사에 인센티브(IT실태평가) 부여
- 페이팔, 알리페이와 경쟁할 수 있는 국내 간편 결제 서비스에 대한 인센티브 부여
- 금융보안원 금융보안적합성 시험(http://www.fsec.or.kr/business/finance_suitability.jsp)
시험 기준 확인 필요
- 49 -
<표 2-6> 국내 간편 결제 현황
간편결제 명칭 설명 웹호환성 여부
카드사 앱카드
간편결제
모바일 앱에 이용 카드를 등록해두고 온라인과 오프라인에서 사용.
(롯데, 신한, 삼성, 현대 등)모바일 App 기반
페이올 웹표준 기반이며 카드사 서버에 카드정보를 등록해두고 사용. (BC카드) 웹표준 UI
SSG Pay유통사인 신세계에서 도입한 간편결제. 모바일 앱을 이용하여 카드를
등록해두거나 충전하여 사용, 충전방식 중 신용카드 충전이 별도로 있음모바일 App 기반
엘로페이ARS로 비밀번호 등록하여 사용하는 계좌 기반 직불결제 서비스.
주요 사용처로 인터파크가 있음
간편결제 가입 시
ActiveX와
공인인증서 사용
페이나우PG사인 LGU+에서 제공하는 간편결제.
카드, 계좌이체 및 휴대폰결제를 지원모바일 App 기반
페이핀
정보 소유자가 해당 정보를 확인해낼 수 있는지 여부로 인증, 이메일
인증, 문자 인증, ARS 인증, CallerID 인증 등의 비금융 정보 기반 인
증과 신용카드 금액인증, 계좌 1원 이체 후 소유주 확인 등의 금융정
보 기반 인증으로 구분 가능
모바일 App 기반
시럽페이SK플래닛 주도로 11번가 쇼핑몰에서 사용.
신용카드를 서버에 등록해두고 사용하는 방식웹표준
스마일페이지마켓과 옥션에서 사용가능한 결제수단.
카드정보를 서버에 등록해두고 사용하는 방식웹표준
티몬페이티켓몬스터 앱을 이용하여 카드정보를 등록해두고 사용.
티켓몬스터 사이트에서 사용모바일 App 기반
페이코 NHN엔터테인먼트에서 제공하는 간편결제 서비스 모바일 App 기반
모카페이 카드정보를 앱을 통해 등록해두고 바코드를 통해 오프라인 결제에 사용 모바일 App 기반
네이버페이네이버에서 제공하는 간편결제.
카드 및 계좌정보 등 결제정보 등록후 사용, 온라인 송금의 경우 앱 이용
웹과 모바일
App기반
카카오페이 다음카카오에서 제공하는 간편결제. 카드정보를 앱을 통해 등록 후 사용 모바일 App 기반
엘페이 롯데 유통망과 롯데멤버스를 통한 포인트 중심의 간편 결제 서비스 모바일 App 기반
H월렛 현대백화점 유통망을 통한 포인트 중심 중심의 간편 결제 서비스 모바일 App 기반
삼성페이마그네틱 결제 방식(MST)과 근거리 무선 네트워크(NFC) 방식을 모두
지원하여 추가 인프라 투자 없이 기존 인프라 사용 가능모바일 App 기반
페이게이트
금액인증페이게이트에서 제공하는 간편결제. 카드정보 등록없이 바로 결제 웹표준
- 50 -
<표 2-7> 해외 간편 결제 현황
2.1 은행계좌 기반 결제 수단
가. 실시간 계좌이체
LG유플러스는 은행 제휴를 통해서 실시간 계좌이체 서비스(ActiveX 기반)를 제공 중에
있고, 이니시스는 뱅크타운 계좌이체 부문을 인수하여 실시간 계좌이체 서비스(ActiveX
기반)를 제공하고 있다.
나. 가상계좌 결제
은행계좌에서 파생된 가상의 계좌번호를 벌크로 생성해두었다가 실제 거래 시 해당
거래와 1:1로 매핑 되는 가상계좌번호를 조회하여 고객이 가상의 계좌로 입금 시 은행
의 통지에 의해 입금대기 상태의 거래를 입금완료로 종결한다.
간편결제 명칭 설명 웹 호환성 여부
안드로이드페이구글에서 안드로이드 스마트폰내에서의 결제를 지원하기
위한 플랫폼
안드로이드
OS 기반
구글월렛 구글에서 웹상에서의 결제를 지원하기 위한 플랫폼 웹표준
아마존페이아마존내에서만 사용하던 원클릭 페이를 포함한 결제플
랫폼을 일반 상점에게까지 확대한 결제환경웹표준
애플페이지문인식 터치ID로 인증하며 애플에서 제공하는 앱내 결제
환경 Tokenization 사용iOS 기반
위쳇페이 중국 텐센트 위쳇 앱 내에서의 결제환경 모바일 App 기반
페이팔 페이팔 서버에 카드정보를 등록한 후 사용 웹표준
알리페이 알리페이 서버에 결제정보 등록 후 사용일부 플러그인
기술 사용
- 51 -
다. 간편 송금
간편 송금 앱을 설치하고 가입/본인 인증 후, 은행계좌를 연결시키면 1) 송금자가 수
취인의 연락처와 금액을 입력하고 송금하면, 2) 수취인이‘받을 계좌를 지정하는 웹페이
지’링크가 담긴 문자 메시지를 받고, 3) 수취인이 웹페이지를 통해 입금 받을 계좌를
지정하면 보낸 금액이 즉시 입금되는 방식으로 1회/1일 이용한도에 제약이 있다.
2.2 신용카드 기반 결제 수단
LG신용카드 기반 결제는 간편결제 방식으로 확산되고 있으며, 아래와 같이 전자결제
승인을 위한 다양한 인증 방식을 활용하고 있다.
<표 2-8> 주요 인증방법
인증 방법 설명
공인인증서여러 가지 인증방법중 하나로서 사전에 발급받은 공인인증서와 비밀번호를 통해
신용카드 결제 인증
구 인증신용카드번호, 카드 비밀번호 앞2자리와 생년월일(2014년 8월 이전에는 주민번호
뒤 7자리 또는 사업자번호)로 카드소유자 확인을 하는 인증방법
안심클릭 인증
카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 안심클릭 인증
정보를 생성하고 이용자가 등록된 올바른 인증정보를 제공할 수 있는지 여부로
본인확인
ISP 인증
카드 발행사와 카드 소유자간에 상호 알고 있는 정보를 토대로 ISP 인증정보를
생성하고 이용자가 등록된 올바른 ISP 인증정보에 근거하여 생성한 전자서명
(Digital Signature)을 서버에서 검증하여 본인확인
AA 인증
랜덤한 승인금액을 생성하여 이용자가 승인금액이 얼마였는지 알아낼 수 있는지
여부로 본인확인 또는 승인금액을 고정하고 가맹점 명칭에 포함된 랜덤코드를
이용자가 알아낼 수 있는지 여부로 본인확인
ARS 인증
카드사에서 이용자가 사전에 지정한 전화번호로 전화를 걸어 본인확인을 하는
형태로, ARS시스템에 의해 자동으로 이용자에게 전화가 걸리며, ARS 멘트로 거래
내역 사실이 이용자에게 안내되면 확인 후, 최종적으로 고객이 승인
- 52 -
가. 결제서비스 제공 주체별 분류
<표 2-9> 결제서비스 제공 주체별 분류
[그림 2-17] mPay 결제 프로세스
결제서비스 제공주체 설명
카드사제공 인증신용카드사에서 주도하여 제공하는 인증방법
ISP, 안심클릭, 모바일 ISP, 모바일 안심클릭, 앱카드, 스마일페이, ARS인증
PG사 제공 인증 AA인증, 케이페이, 페이나우, 셀프페이, 엠페이, 페이핀
- 53 -
나. 플랫폼 기반 분류
<표 2-10> 플랫폼 기반 분류
[그림 2-18] 페이핀 결제 프로세스
플랫폼 설명
PC ActiveX ISP, 안심클릭
모바일 앱 카드사 앱카드, 모바일 ISP, 페이나우, 엠페이, 페이핀
모바일웹 Only 모바일 안심클릭
전화(ARS) ARS인증 결제
웹 표준 AA인증(휴대폰 문자 필요)
- 54 -
2.3 통신사 모바일 앱(메신저) 기반 결제 수단
가. 통신사 소액결제
통신사의 통신요금 청구 시 결제대금을 함께 청구하여 대금을 수납하며, 결제방식은
전화번호 및 이와 매핑 된 주민번호(또는 개인 식별번호)를 입력하면 본인 휴대폰으로
인증코드가 SMS로 전송됨, 이를 이용자가 해당 SMS 코드를 인증정보로 입력하여 결제
완료하는 방식이다.
나. ARS 인증 기반 결제
통신사 요금청구 시 결제대금을 함께 청구하여 대금을 수납하며, 결제방식은 전화번
호 및 이와 매핑 된 주민번호 (또는 개인 식별번호)를 입력하면 본인 전화로 ARS 콜이
인바운드로 걸려오거나 이용자가 ARS번호로 아웃바운드 콜을 하게 되면 인증번호를 확
인하고 결제 페이지에 입력하여 결제를 완료하는 방식이다.
다. 모바일 앱(메신저) 기반 결제
모바일 메신저를 통한 결제 방법으로 신용카드 정보 등록과 인증 절차를 거친 후 신용
카드 정보를 카드사 서버와 PG에 나눠 보관하여 안전성을 강화하고 있다. 온라인 결제
시에는 모바일 메신저 실행 후 가맹점 상품을 선택하고 사전 등록한 비밀번호와 OTP 기
반의 결제 인증번호(2회)를 결제 페이지에 입력하여 결제 완료하는 방식이다.
- 55 -
2.4 해외 결제 수단
해외는 비 실시간의 계좌기반 결제수단이 광범위하게 사용되고 있으며, 최근 계좌기반
결제수단의 경우 투채널 인증 방식을 통해 안전성과 무결성, 본인 인증을 강화하고 있다.
가. 해외 신용카드 결제 방식
<표 2-11> 해외 신용카드
나. 페이팔
최초 카드 정보 등록 시 본인확인을 위해 1.95달러 정상 거래 승인을 카드사에 요청하
고, 정상 카드의 경우 인증코드 4자리를 사전에 등록한 휴대폰이나 메일로 전송한다. 카
드 소유 고객이 전달 받은 4자리 인증코드를 온라인에서 입력하면 본인확인이 완료된다.
(1.95달러는 24시간이내에 환불) 카드 정보 등록 이후에는 페이팔 로그인 정보만으로 온
라인 결제가 이루어지며, 최근에는 카드 결제 대행 이외에도 이메일을 통한 온라인 송금
서비스도 제공하고 있다.
결제 방식 설명
카드번호+유효기간 결제 신용카드의 유효성만을 확인하여 결제
CVV/CVC 인증 결제CVV/CVC Code는 고객이 실제로 카드를 소지하고 있는지 여부를
확인하는 목적이며 본인인지 여부를 확인하지는 못함
AVS 인증 결제
카드 등록자의 주소와 결제 시 입력한 주소가 동일한지 여부로 인증
북미지역에서만 유효한 인증방식이며 고객의 입력 실수 등에 의한
인증 오류 발생빈도가 높음
3D Secure 인증
국내 안심클릭의 원본이며 Visa 3D Secure, MasterCard SecureCode,
JCB J/Secure 등 카드 브랜드별로 다양한 용어로 통칭됨. 카드 발행사
에서 3D Secure 인증을 지원하는 ACS서버를 운영해야 하지만 국제적
으로 모든 카드발행사가 해당 인증방식을 지원하지는 않음
AA 인증거래금액을 인증코드로 이용하거나 가맹점 명칭에 인증코드를 추가하여
승인을 내고 고객이 해당 정보를 알아낼 수 있는지 여부로 인증
- 56 -
[그림 2-19] Paypal 프로세스
다. 알리페이
은행 계좌기반 결제서비스로 고객은 최초 계좌 등록 시 계좌 소유주 확인을 위해서
알리페이에서 등록된 고객계좌로 소액을 2회 이체한다. 고객은 이체된 금액이 얼마인지
를 자체적으로 알아내서 해당 금액을 인증코드로 입력하여 본인이 정당한 계좌 소유주
임을 증명하는 방식이다.
알리페이는 이러한 본인확인 절차 후 온라인(모바일), 오프라인 신용카드 연동 결제,
계좌 충전 지불, 물품 수령 지불 등의 결제 방식을 활용하여 제3자 결제 대행 서비스를
제공하고 있다.
- 57 -
라. 애플페이
고객의 신용카드와 체크카드를 iTunes등 애플 서비스 이용과정에서 등록할 수 있으며,
신용카드(American Express, MasterCard, Visa)를 직접 사진으로 찍어서(OCR) 등록할 수
있다.
애플페이는 NFC와 터치ID(지문인식) 조합을 통해 본인확인 및 부인방지 기능을 제공하
며, 애플은 결제 안전성을 보장하기 위해 신용카드 정보는 전용 보안칩(Secure Element)
에 암호화해서 저장하고, 결제 시 일회용 보안 토큰을 생성하고 결제 상점은 해당 토큰
을 NFC로 전달 받아 네트워크를 통해 제휴 금융기관에서 결제 카드 유효성을 검증한다.
이때 금융기관은 애플사에 보안 토큰의 유효성 검증을 요청하고 승인 응답 코드만 상점
에 전달한다. 아이폰 분실 시에는“나의 아이폰찾기”를 통해 해당 단말에 대한 지불 기
능을 중지할 수 있다.
3. 대체기술
전자결제 시 결제창, 전자서명을 통한 결제 인증, 보안 영역 등에서 ActiveX 등 비표
준 기술을 사용한다. 본 안내서에서는 결제창과 카드 결제에서만 사용하는 전자서명, 인
증, 보안에 대한 단계별, 정책적, 기술적 대응 방안을 명시한다.
3.1 결제 단계별 개선 방안
기본적으로 결제단계에서 플러그인을 사전에 설치해두는 접근방식을 지양하고, 고객
이 선택할 인증방식에 대비하여 미리 플러그인을 설치하는 방식보다는 해당 플러그인이
필요한 단계에서만 전자결제 기능을 활성화하여 사용하는 형태로 제공한다.
실시간 전자결제 활성화에 대응하기 위해서는 Single Page 내에서 결제단계를 구현하
고 서버와의 통신은 XMLHTTPRequest 또는 DOMRequest 등의 통신방식을 사용할 수
있다. 현재 플러그인에 의존하여 처리하는 전자결제 방식 및 이에 대한 개선방안은 아
래와 같다.
- 58 -
<표 2-12> 결제단계별 플러그인 사용요소 및 개선방안
결제단계 단계별 플러그인 사용요소 개선방안
PG사 결제화면
카드사 선택이나 이벤트 표시
등 결제화면 자체를 ActiveX
등의 플러그인으로 구현
HTML5나 자바스크립트 프레임워크 등을
이용하여 UI를 구현
카드사 ISP 인증ISP 결제 UI 전체가 플러그인
으로 구현
BC카드 PayAll 등 웹 표준 방식의 ISP
인증으로 전환
카드사 안심클릭
인증
통신채널 암호화를 위한
플러그인 사용
웹 표준 방식의 E2E 통신채널 암호화
방식으로 전환
안심클릭 입력정보의 보호를
위해 키보드 보안 프로그램 설치
주요 인증정보에 대하여 직접 입력하지
않도록 구현 및의 입력정보 보호방식 적용
공인인증서 사용을 위한
플러그인을 설치
웹 표준 방식의 공인인증서 사용 또는 ARS인증,
OTP 등 대체수단 인증 방식을 사용
카드사 mISP
인증
ISP Mobile App을 사용하여
결제
BC카드 PayAll 등 웹 표준 방식의 ISP
인증으로 전환
가상계좌 조회
무통장 가상계좌 입출금 거래
일의 경우 ActiveX 등의 플러
그인을 이용하여 가상계좌 번
호 조회
가상계좌 번호를 XMLHTTPRequest 또는
DOMRequest 등 Ajax 통신을 통하여 조회
계좌정보에 대한 무결성 검증을 위하여 자바
스크립트에서 Hash 검증 및 자바스크립트에
대한 보호조치 적용
실시간 계좌이체ActiveX 등의 플러그인 이용하여
실시간 계좌이체 구현
은행의 인터넷 뱅킹의 웹 표준화 수준과 연관
이 있으며 실시간 계좌이체를 위한 ActiveX
실행이 불가한 환경을 고려하여 플러그인의
사전 설치가 아닌 선택 시 실시간 활성화 방
식으로 구현.
이용자가 다른 결제방식을 선택할 수 있도록
옵션을 제시
휴대폰 결제
주민번호 등 개인정보의 일부
또는 전부가 휴대폰 결제를 위해
사용되며 이의 보호를 위해
플러그인 사용
결제과정에서 민감한 개인정보를 사용하지
않도록 본인확인 방식을 개선
- 59 -
3.2 결제창 대체 방안
각 결제서비스 제공 업체별로 고유한 결제창을 구현하여 제공하는 결제창은 일체의
플러그인을 사용하지 않고 구현한다. 특히 결제창을 팝업(Popup)으로 구현할 경우 Auto
Popup을 지양하고 가능한 User Popup으로 한다.
- Auto Popup은 브라우저의 팝업 차단 매커니즘에 의해 블록되는 경우가 많고
이를 해결하기 위해서 ActiveX 등의 플러그인이 필요하다.
- User Popup은 이용자가 명시적으로 팝업을 띄우는 행위를 하는 경우로 브라
우저의 팝업 차단 설정에 영향을 받지 않으며 동시에 팝업 차단 문제해결을
위한 플러그인도 필요하지 않다.
- 또한 모바일 환경 등을 감안할 때 결제창의 팝업 이용 없이 화면 전환형태로
구현하거나 <Div> Tag나 <iframe>등을 이용하여 Mesh-up하여 구현하는 방식도
검토 가능하다.
3.3 전자결제 인증 대체방안
웹과 스마트폰 앱을 연동하는 결제 방식 등 최근 등장하고 있는 표준 기반의 다양한 인
증 방식 도입에 대한 검토가 필요하다. 카드결제의 경우 EMV(Europay, Mastercard, Visa)
기반의 IC카드 표준 규격을 준수하고 추가적으로 전자결제 인증정보를 웹을 통해서 전
달하는 경우에는 거래연동 OTP 등 노출되더라도 관계없는 2-Factor 인증정보를 사용하
거나 별도 보호방안을 적용할 수 있다. 또한 전자결제 인증정보를 웹 이외의 다른 채널
을 통해서 전송하는 방식도 고려할 수 있다.
3.4 전자결제 보안 대체방안
전자결제 보안은 인증이나 암호화 등 특정 요소에 집중함으로 인해 다른 요소 (물리보
안, 네트워크 보안 등)에 취약점이 발생하지 않도록 주의한다. 전체적인 보안성의 유지를
위하여 PCI-DSS(Payment Card Industry-Data Security Standard) 인증 등“정기적”으로
“제3의 전문가”를 통해 종합적인 보안성을 검증 받는 체계를 도입하는 것이 바람직하
다. 또한 내부통제를 위해 보안 관리 조직은 물론, 금융사기 방지를 위해 실시간 모니터링
시스템(FDS)을 운영하거나 다양한 보안 S/W, H/W를 사용자의 선택에 따라 설치 및 사용
가능하다. 일반적인 전자결제 보안 사항은 본 안내서의 [1. 보안]을 참조하여 구현한다.
- 60 -
참고자료 전자결제 구현 시 주요 점검 항목
1. 이용자 인증은 웹 표준 환경에서는 아래와 같은 다양한 인증을 하나 또는 여러 개를 조합하여 이용
자 인증 시 이용 가능하다.
- 이용자 기억(Knowledge)에 근거한 인증 방식으로 기존 패스워드나 PIN(숫자로 구현된 개인식별번
호)이 주로 사용되었으나 최근 이미지 패턴에 근거한 인증방식이 소개되고 있다.
- 소지(Possession) 기반 인증 방식으로 OTP 토큰이나 소프트 토큰, 스마트폰 푸쉬 등을 통해 인증코
드를 전송하거나 확인하고 이용자가 입력하도록 하여 이용자를 인증하는 방식이다.
- 생체(Biometrics) 인증 방식으로 지문, 홍채, 음성, 얼굴, DNA 등을 통해 고유한 특징을 추출하고
기존 채취 데이터와 비교 확인하고 매칭하여 이용자의 신원을 인증하는 방식이다.
2. 서버 인증거래상대인 서버의 인증은 사기거래 방지 등을 위해서는 매우 중요한 요소로 기본적으로
SSL을 활성화하여 신뢰할 수 있는 정보처리 시스템임을 이용자가 인증할 수 있도록 하며 EV(Extended
Validation) SSL 인증서를 활성화하여 정보처리 시스템의 명확한 신원을 이용자에게 제공하여 인증하는
것이 중요하다.
3. 통신 채널 암호화는 기본적으로 SSL을 활용하되 구현 시 올바른 설정이 필요하다.
4. 거래내역 무결성 보장 Hash 알고리즘을 이용하여 거래내역의 무결성을 상호 검증할 수 있도록 해야
하며, 특히 CSRF(Cross-site request forgery)등에 대응하기 위해 Form Data나 Parameter에 대한 무
결성 검증 매커니즘의 추가가 필요하다. Hash 알고리즘은 가능한 SHA2 이상의 알고리즘을 사용하며
SHA1이나 MD5 알고리즘 사용을 지양한다.
5. 웹 표준 환경에서의 부인방지는 KS 국가표준인 KS X ISO/IEC 13888-1, 13888-2, 13888-3 을 고려하
여 구현 할 수 있으며 현재 KS표준에 추가 준비 중인 ISO/IEC 10181-4 표준도 참고할 수 있다. 현재
부인방지의 구현 방식은 공인인증서에서 사용되는 PKI (Public Key Infrastructure) 기술을 이용하여
구현하는 방식을 사용하고 있으며, KS 표준(13888-2)에서는 신뢰할 수 있는 제3자 (TTP, Trusted
Third Party)를 이용한 부인방지 구현에 대한 방안도 제시하고 있다. 신뢰할 수 있는 제3자를 이용한
부인방지 모델 구현 시에는 브라우저에 복잡한 암호기술을 탑재하고 구현할 필요성이 줄어들어 웹
표준 환경에 대응 가능한 모델이 될 수 있지만, 제3자의 신뢰성을 어떻게 확보할 것인지에 대한 비
기술적인 과제가 남아있으며, 현행 법제도 측면에서는 공인인증기관이 부인방지 구현을 위한 신뢰할
수 있는 제3자 역할을 하는 것도 가능하다.
- 61 -
1. 개요
비디오/오디오와 같은 멀티미디어 사용은 HTML5 표준이 나오기 전에는 ActiveX와 같
은 플러그인 기술을 사용할 수밖에 없는 대표적인 분야였다. 그러나 HTML5에서는 멀티
미디어를 위한 비디오/오디오 재생을 위한 요소와 API, 자막을 위한 요소, 카메라/마이크
제어 API, 오디오에 에코와 같은 음향효과를 주는데 사용할 수 있는 웹오디오(Web Audio),
멀티미디어 데이터의 스트리밍 및 데이터 제어를 위한 미디어 소스 확장(Media Source
Extentions), 멀티미디어 데이터 DRM(Digital Rights Management)를 위한 EME(Encyrpted
Media Extensions)와 같은 다양한 기능이 추가되어 Flash Player나 ActiveX를 사용하지
않고도 멀티미디어를 사용할 수 있게 되었다.
다만 브라우저에 따라 지원하는 기능과 화면 UI가 다르기 때문에 개발자가 HTML5에
서 제공하는 기능을 사용할 때는 사용자의 브라우저 버전과 멀티미디어 태그 지원 여부
를 확인해야 한다.
현재 HTML5 표준 기술을 활용한 오픈소스를 통해 개발자가 쉽게 적용할 수 있도록
만든 자바스크립트 라이브러리 등을 소개한다.
2. 사용현황
현재 멀티미디어와 관련하여 비표준 플러그인과 ActiveX를 사용하는 부분을 정리하면
크게 다음과 같다.
• 비디오 재생기 : 자막
• 오디오 재생기 : 음향 효과
• 인터넷 강좌 : 다양한 강좌
• 인터넷 방송 : 방송사나 통신사 등에 의해서 제공되는 방송 및 VOD 서비스
• 실시간 인터넷 중계 : 아프리카 TV와 같은 중계 서비스
• 컨퍼런싱 : 동영상 회의 시스템
• DRM이 지원되는 멀티미디어 재생
4 멀티미디어
- 62 -
3. 대체기술
별도 플러그인 설치 및 ActiveX 사용을 대체하기 위해서 사용 가능한 HTML5 표준
기술로는 다음과 같은 것들이 있다.
• 멀티미디어 요소: <video> 요소, <audio> 요소
• WebRTC(Web Real Time Communication), Media Streaming, APIMedia Capture API
• 웹오디오(Web Audio)
• MSE(Media Source Extensions)
• EME(Encrypted Media Extensions)
3.1 HTML5 Video 요소
비디오를 포함하려면 HTML5 Video 요소를 선언하고 재생할 비디오의 소스를 요소의
속성이나 <source> 요소를 사용하여 지정해야 한다. 비디오 재생 화면에 제어기를 표시
하거나 자동 재생이 되도록 속성 값을 지정해야 해야 한다.
(참고: w3schools.com의 HTML5 Video, http://www.w3schools.com/html/html5_video.asp)
[예시 : <video> 요소 사용]
<표 2-13> <video> 요소 속성
<video controls src="재생할 비디오 파일 이름" width="폭" height="높이" >
이름 설명
src 비디오 콘텐츠의 위치를 지정
controls 미디어 제어기를 표시
loop 비디오 반복 재생 횟수
autoplay 파일이 로드 되자마자 자동으로 재생
- 63 -
<표 2-14> <video> 요소의 재생 관련 속성, 자바스크립트 API
HTML 표준에서는 비디오를 위한 코덱을 지정하고 있지 않고, 브라우저 개발자가 이를
선택할 수 있도록 되어 있어, 브라우저마다 지원하는 비디오 코덱이 다르다는 문제가 있다.
width 화면에서 비디오 콘텐츠가 표시될 영역의 폭을 설정
height 화면에서 비디오 콘텐츠가 표시될 영역의 높이를 설정
videoWidth 비디오 콘텐츠의 폭 (읽기 전용)
videoHeight 비디오 콘텐츠의 높이 (읽기 전용)
poster 동영상 데이터가 로딩되고 있을 때 보여줄 이미지를 지정하는 속성
preload
브라우저가 미리 비디오 콘텐츠를 로딩할지 지정
* auto(기본값)
* metadata : 비디오의 메타데이터만 다운로드
* none : 재생을 시작하기 전까지 비디오를 다운로드 하지 않음
종류 이름 설명
메서드play( ) 재생 시작
pause( ) 재생 일시정지
속성
currentTime 현재 재생 위치
duration 전체 길이
ended 마지막까지 재생했는지 여부
paused 일시 멈춤 여부
이벤트canplay 재생이 가능할 때 발생
timeupdate 재생중 주기적으로 발생
- 64 -
이러한 문제를 해결하기 위해서 HTML5 Video 요소에서는 <source> 요소를 사용하여
여러 비디오 코덱을 지정할 수 있는 기능을 제공하고 있다.
[예시 : <source> 요소 사용]
또한 HTML5 Video 요소에서는 자막 지원을 위한 <track> 요소를 지원하고 있다.
자세한 사용법은 HTML5Rocks 웹페이지의“Getting Started With the Track Element”
(http://www.html5rocks.com/en/tutorials/track/basics/)에서 살펴볼 수 있다.
[예시 : <track> 요소 사용]
HTML5 Video 요소는 브라우저마다 지원하는 코덱과 실시간 전송 기술, DRM등의 다
양한 문제가 있으며, 이를 정리하면 아래 표와 같다.
<표 2-15> 브라우저 제조사별 지원 코덱, DRM
제조사 코덱 실시간전송기술 DRM
Microsoft∙ VC-1/WMA
∙ WMA/ISMV∙ Smooth Streaming
PlayReady
EME
Apple∙ H.264/AAC
∙ M4V∙ HTTP LiveStreaming
FairPlay
EME
∙ H.264/AAC
∙ WebM
∙ Ogg
∙ MEPG-DASH
∙ HTTP LiveStreamingEME
Firefox∙ Ogg
∙ WebM
∙ MEPG-DASH
∙ HTTP LiveStreamingEME
<video><source src="movie.mp4" type="video/mp4"></source><source src="movie.ogv" type="video/ogg"></source><source src="movie.mpeg" type="video/mpeg"></source></video>
<video src=“foo.ogv"><track kind="subtitles" label="Korean subtitles" src="subtitles_ko.vtt" srclang="ko" default></track><track kind="subtitles" label="English subtitles" src="subtitles_en.vtt" srclang="en"> </track></video>
- 65 -
브라우저에서 지원하는 HTML5 Video 요소는 브라우저마다 지원 여부와 제어기 모양,
세부작동방식이 다른 문제점이 있어서, 비디오 재생을 위한 자바스크립트 라이브러리를
많이 이용한다. 대표적인 오픈소스 비디오 재생기로는 video.js(www.videojs.com)가 있으
며 다양한 브라우저와 변경 가능한 UI를 제공하고 있다.
[그림 2-20] video.js의 비디오 재생기
그 외 다양한 HTML5 비디오 재생기들이 있으며, HTML5 Video Player 비교 사이트
(http://praegnanz.de/html5video)를 통해 브라우저에 따른 지원 기능을 확인할 수 있다.
3.2 HTML5 Audio 요소
오디오 콘텐츠를 포함하려면 HTML5 Audio 요소를 선언하고 재생할 오디오의 소스를
요소의 속성이나 <source> 요소를 사용하여 지정하고 오디오 콘텐츠 재생을 제어하기
위한 제어기를 표시하거나 자동 재생이 되도록 속성 값을 지정해야 해야 한다.
(참고: w3schools.com Audio, http://www.w3schools.com/html/html5_audio.asp)
[예시 : <audio> 요소 사용]
<audio controls src="재생할 오디오 파일 이름">
- 66 -
HTML5 Audio 요소는 오디오와 재생 제어를 위한 다양한 속성과 자바스크립트 API를
제공하고 있다.
<표 2-16> <audio> 요소 속성
HTML5 Audio 요소는 HTML5 Video 요소와 함께 미디어 요소를 이루고 있으며, 미디
어 요소에 정의된 많은 속성과 API를 같이 가지고 있다.
오디오도 비디오와 비슷하게 브라우저마다 지원여부와 UI, 세부기능이 다른 문제점이
있으며, 비디오처럼 자바스크립트 재생기를 통해 이를 해결하고 있다. audio.js (http://kol
ber.github.io/audiojs/)는 대표적인 오픈소스 오디오 재생기이다.
[그림 2-21] audio.js 재생기 화면
“Top 10 Best HTML5 Audio Players”기사 (http://www.scratchinginfo.net/top-10-best-
html5-audio-players/)에서 여러 오디오 재생기를 살펴볼 수 있다.
이름 설명
src 오디오 콘텐츠의 위치를 지정
controls 미디어 제어기를 표시
loop 오디오 반복 재생 횟수
autoplay 파일이 로드 되자마자 자동으로 재생
preload
브라우저가 미리 비디오 콘텐츠를 로딩할지 지정
* auto(기본값)
* metadata : 비디오의 메타데이터만 다운로드
* none : 재생을 시작하기 전까지 비디오를 다운로드 하지 않음
- 67 -
앞의 비디오 재생기 표에서 볼 수 있는 것처럼 비디오 재생기 중 일부는 오디오 재생
기 기능을 동시에 지원하는 것도 있으며, 대표적인 오픈소스 기반 멀티미디어 재생기로
는 MediaElement.js(http://mediaelementjs.com/)와 jPlayer(http://jplayer.org/)가 있다.
3.3 WebRTC
WebRTC(Web Real-TIme Communations) 기술은 웹 환경에서 화상 통신, 전화 통신과
같은 통신을 위해서 정의된 기술이다. 현재 ActiveX를 이용하고 있는 컨퍼런싱 시스템
이나 아프리카 TV와 같은 개인 인터넷 방송 등에도 이용될 수 있는 기술이다. 현재 표
준 제정 작업은 W3C의 WebRTC 워킹그룹(http://www.w3.org/2011/04/webrtc/)에서 하고
있으며, WebRTC(http://www.webrtc.org)에서도 정보를 얻을 수 있다. 세부적으로는 카메라와
마이크 같은 장치로부터 입력을 받을 수 있는 미디어 캡처 기능과 피어통신(peerconnection),
데이터 채널 관리와 같은 통신 기능으로 구성되어 있다.
HTML5 Rocks의“Getting Started with WebRTC”에서 간단한 사용법을 확인 할 수 있다.
(http://www.html5rocks.com/ko/tutorials/webrtc/basics/)
WebRTC를 지원하는 브라우저로는 Chrome과 Firefox, Edge, Opera가 있으며 (http://isw
ebrtcreadyyet.com), 낮은 버전의 인터넷 익스플로러와 사파리에서는 지원하고 있지 않으
나, webrtc4all(https://code.google.com/p/webrtc4all)와 같은 오픈소스를 사용하거나 PlayRTC
(http://www.playrtc.com)와 같은 상용 소프트웨어를 통해 WebRTC를 지원하지 않는 브라
우저에서도 사용할 수 있다.
[그림 2-22] WebRTC 브라우저 지원 현황
- 68 -
3.4 웹오디오
웹오디오(Web Audio)는 웹 애플리케이션에서 오디오를 생성, 처리하는데 사용하는 자
바스크립트 API이다. 이를 사용하면 여러 오디오를 믹싱하거나 에코와 같은 필터 효과
를 줄 수 있다. <audio> 요소는 오디오 재생을 위한 기능을 제공하지만, 웹오디오에서
지원하는 고급 기능을 사용할 수 없다.
HTML5Rocks의“Getting Started with Web Audio API”에서 사용법을 확인할 수 있다.
(http://www.html5rocks.com/en/tutorials/webaudio/intro) 웹오디오를 지원하는 브라우저에
는 Chrome, Firefox, Safari가 있다.
3.5 MSE
MSE(Media Source Extensions)은 HTML5 Video에서 멀티미디어 데이터 프리패칭(prefetching),
버퍼링(buffering) 등과 같은 스트림을 제어하는데 사용하는 자바스크립트 API이다. 이를
사용하면 브라우저에서 기본으로 제공하는 스트리밍 방식이 아닌 제공 서비스의 특성에
따른 스트리밍을 할 수 있어 서비스 내에서 안정적인 스트리밍을 할 수 있게 한다.
Chrome, IE 11(Windows 8), Safari 8, Firefox 42, Opera 9 에서 지원하며, dash.js(https:
//github.com/Dash-Industry-Forum/dash.js)에서 MSE를 지원하는 DASH 자바스크립트 라이
브러리를 사용할 수 있다.
3.6 EME
EME(Encrypted Media Extensions)는 HTML5 Video와 Audio 요소를 확장하여 플러그인
을 사용하지 않고도 DRM(디지털 권한 관리) 보호된 콘텐츠를 사용할 수 있는 기능이다.
HTML5 Rocks의“EME WTF?”(http://www.html5rocks.com/ko/tutorials/eme/basics/)에서 간
단한 예를 확인 할 수 있다.
EME와 같은 멀티미디어 콘텐츠 DRM 기술은 참여, 공유, 개방을 기반으로 하는 웹
철학을 훼손하는 주장도 있으나 미디어 업계와 같은 멀티미디어 산업 측면에서는 매우
중요한 발전 기술로 생각되고 있다. 모질라의 경우“Mozilla의 사명과 W3C EME 스펙의
조화”(http://hacks.mozilla.or.kr/2014/05/reconciling-mozillas-mission-and-w3c-eme/)의 글을 통
해 이런 측면과 브라우저의 지원계획을 살펴볼 수 있을 것이다.
- 69 -
EME는 인터넷 강좌, OTT(Over The Top) 유료 비디오 서비스와 같은 멀티미디어 콘
텐츠의 보호가 필요한 서비스를 위해서 사용될 수 있다.
3.7 멀디미디어 적용사례
가. 적용사례
멀티미디어 요소는 단순한 웹문서 내에서의 멀티미디어 파일의 재생을 넘어 동영상
사이트나 음성 채팅, 영상 통화, VOD와 같은 응용에도 적용되고 있다. 대표적인 사례를
보면 아래와 같다.
- 유튜브
대표적인 동영상 사이트인 유튜브(YouTube, http://youtube.com)는 플래시 기반의 동영상
재생기를 HTML5 기반의 동영상 재생기로 모두 변경 하였다.
[그림 2-23] YouTube
- 70 -
- 구글 행아웃
구글 행아웃(https://plus.google.com/hangouts)은 구글에서 서비스하는 동영상 컨퍼런스
서비스이다. 구글 행아웃은 초기에는 플러그인 기술을 사용하여 서비스되었으나, 다
음 기사의 내용처럼 앞으로 WebRTC을 사용할 것이라고 하며 현재도 최신 버전의
구글 크롬을 사용하면 플러그인 없이 사용할 수 있다.
“Google Hangouts Plugin No Longer Needed in Chrome”
(http://www.omgchrome.com/google-hangouts-chrome-plugin-free-2/)
“웹 소통을 확 바꿀‘구글 + 수다방’”
(http://www.bloter.net/archives/66616)
- WaveSurfer..js
wavesurfer.js(https://wavesurfer-js.org/)는 웹오디오 API와 캔버스를 사용하여 오디오
시각화(Audio Visualization)을 보여주고, 이퀄라이저 기능을 자바스크립트 라이브러리로
제공한다.
[그림 2-24] 이퀄라이저 시각화
wavesurfer.js 라이브러리는 github를 오픈소스 형태로 제공하고 있어 다양한 응용이
가능하며 깃허브(https://github.com/katspaugh/wavesurfer.js)에서 관련코드를 살펴볼 수
있며 wavesurfer.js의 웹 오디오를 지원하는 브라우저로는 파이어 폭스, 크롬, 사파리,
오페라가 있다.
- 71 -
3.8 멀티미디어 적용 시 고려사항
멀티미디어 기능을 사용할 때 웹 문서 내에서 어떻게 멀티미디어 콘텐츠를 표현할 것
인지와 멀티미디어 콘텐츠를 단일화면 안에서 표현할 것인지 외부링크 또는 별도의 화
면에서 표현할 것인지와 같은 콘텐츠의 표시 방식을 고려해야 한다.
브라우저에서의 멀티미디어 요소 지원여부, 지원 코덱 등과 같은 브라우저 기능을 고
려하여 지원하는 브라우저와 그렇지 않은 브라우저에 대해서 표현하는 방법을 구분할
필요가 있다. 최신 브라우저에서는 멀티미디어 요소를 지원하고 있으나, 아직 지원되지
않는 브라우저를 사용하는 경우도 많기 때문이다. 이런 경우 멀티미디어 관련 라이브러
리에서는 ActiveX나 플래시와 같은 플러그인 기술을 사용하여 최신 브라우저처럼 작동
하게 할 수 있다. 그러나 멀티미디어 관련 라이브러리가 모든 웹 사이트의 요구를 만족
하는 것은 아니기 때문에 웹 사이트에 적용할 때 사용할 기능이 있는지 미리 확인해야
한다.
또한 상대적으로 WebRTC와 웹오디오, MSE, EME 관련 부분은 최신 브라우저에서도
지원을 시작하는 단계이기 때문에 단기적으로는 모든 브라우저에서 사용할 수 없으므로
응용에 따라 제한된 조건에서 사용여부를 결정해야 한다.
- 72 -
1. 개요
초기 웹 환경의 그래픽은 브라우저 성능 문제로 정적인 이미지 처리라는 환경적 한계
가 존재하였다. 이로 인해 실시간으로 변경되는 이미지가 필요한 경우는 이미지를 서버
에서 생성하여 사용하였다. 특히 해상도에 독립적인 벡터 이미지나 애니메이션이 필요
한 경우는 플래시와 같은 별도의 플러그인을 통해 처리하는 방법이 선호되었다. 그러나
서버 기반의 이미지 생성은 정적인 이미지를 처리하는 한계에서는 벗어나지 못하며 플
러그인 방식의 경우 이를 허용하지 않는 특정 모바일 플랫폼에서 지원되지 않는 문제가
발생하였다.
HTML5에는 벡터 그래픽을 처리할 수 있는 SVG(Scalable Vector Graphics, 이하 SVG),
동적인 2D/3D 그래픽 Drawing 기능을 제공하는 Canvas, 애니메이션을 지원하기 위한 CSS3
Animation/Transition이 제공되어 브라우저에서 별도의 플러그인이 없이도 능동적으로 그
래픽 관련 기능을 구현할 수 있게 되었다. 다만 각각의 기능이 추구하는 목적과 방법이
다르므로 정확한 목적에 따라 사용하여야 한다.
본 안내서에서는 각 HTML5 그래픽 기능이 가지는 특징과 선택 기준을 설명하고, 개
발에 활용할 수 있는 몇 가지 오픈소스 자바스크립트 라이브러리를 소개한다. 또 이용
자 경험의 향상을 위해 필수적으로 요구되는 렌더링 성능 최적화에 대한 기초 개념에
대해 설명한다.
2. 사용현황
그래픽에 관련된 가장 대표적인 ActiveX 사례는 역시 어도비의 플래시 플레이어를 예
로 들 수 있다. 플래시 플레이어는 기존 HTML에서의 그래픽 기능과 애니메이션 구현상
의 한계를 해결하는 대안으로 오랜 기간 동안 활용되어 왔다. 플래시 플레이어는 이미
지 등의 그래픽뿐만 아니라 멀티미디어 기능을 복합적으로 제공하였으며 도구 기반의
애니메이션 저작 기능의 지원 등으로 많은 사랑을 받아왔다. 대표적인 사용 사례는 다
음과 같다.
5 그래픽
- 73 -
- 그래픽 객체를 통해 동적으로 구성되는 이미지(애니메이션의 출력)
- 벡터 그래픽의 표현을 통한 이용자의 실행 환경에 최적화된 화면 출력
이러한 그래픽 관련 플러그인들은 최근의 웹 환경에서 다른 플러그인 시스템과 마찬
가지로 다음과 같은 한계성을 지니고 있다.
- 브라우저와 별도로 플러그인의 설치 필요
- 표준 웹 규격에 포함되지 않으므로 콘텐츠 저작 환경의 종속성 발생
- 브라우저 플러그인의 구조 상 보안이 취약해질 수 있는 가능성 존재
- 주요 모바일 브라우저는 별도의 플러그인 사용이 불가능하여 모바일 웹에서
대체 방안이 필요하다.
3. 대체기술
그래픽 기능의 표현을 위한 대체기술은 다음과 같이 분류할 수 있다.
<표 2-17> ActiveX의 그래픽 기능을 대체할 수 있는 웹 기술
카테고리 기술 설명 적용 대상
2D Graphics Canvas 2D 일반적인 2D 그래픽 기능 <canvas>
3D Graphics WebGL OpenGL/ES 기반의 3D 그래픽 <canvas>
Vector Graphics
SVG 벡터 기반의 그래픽 기능 <svg>
Animation SVG Animaiton SVG 대상 애니메이션 기능 <svg>
Animation CSS3 Animation 키프레임 기반의 애니메이션 DOM 요소
Transition CSS3 Transition CSS 속성 설정을 통한 전환 효과 DOM 요소
Animation requestAnimationFrame( )자바스크립트 기반 애니메이션을
위한 프로그래밍 모델 제공자바스크립트
- 74 -
3.1 Canvas를 이용한 2D/3D 그래픽 기능의 구현
<canvas>는 HTML5에서 새로 추가된 대표적인 그래픽 요소이다. 기본적으로 <canvas>
는 다음과 같이 일반적인 DOM 요소와 마찬가지로 웹 페이지 내에서 배치 가능한 요소
이며, 개발자는 Canvas가 제공하는 자바스크립트 API들을 통해 그래픽 기능을 처리할
수 있다.
[예시 : Canvas 2D]
위의 예제는 웹 문서 내에 <canvas>를 선언하고 자바스크립트 2D API를 통해 다음과
같은 간단한 사각형을 출력한다.
[그림 2-25] Canvas 2D 샘플 코드 실행 결과
<canvas id="my_canvas" width="300" height="300">HTML5 Canvas를 지원하지 않는 브라우저입니다.
</canvas><script type="text/javascript">
var canvas = document.getElementById("my_canvas");var context = canvas.getContext("2d");context.fillStyle = "#000000";context.fillRect(0, 0, 300, 300);
</script>
- 75 -
더불어 앞에서 설명했던 바와 같이 HTML5의 <canvas> 요소는 OpenGL/ES를 지원하
는 자바스크립트 기반의 API 세트인 WebGL을 지원한다. 위의 예제와 동일한 화면을
WebGL을 통해 표현하면 다음과 같다.
[예시 : Canvas 3D(WebGL) 코드]
다만, WebGL의 경우 현재 모바일 브라우저는 지원하지 않는 경우가 많으므로 사용
시에 대상 이용자 환경에 대한 주의가 필요하다. Canvas에 대한 더 자세한 내용은 다음
링크 목록에서 표준 규격, MDN의 관련 문서 그리고 브라우저의 지원 현황을 참조한다.
- Canvas 표준 규격
http://www.w3.org/TR/html5/embedded-content-0.html#the-canvas-element
- Canvas 지원 현황
http://caniuse.com/#search=canvas
- WebGL 지원 현황
http://caniuse.com/#search=webgl
- MDN의 Canvas 참조 문서
https://developer.mozilla.org/ko/docs/Web/HTML/Canvas
<canvas id="my_canvas" width="300" height="300">HTML5 Canvas를 지원하지 않는 브라우저입니다.
</canvas><script type="text/javascript">
// get canvas elementvar canvas = document.getElementById("my_canvas");// get "WebGL" graphics contextvar context = canvas.getContext("webgl");if (context) {context.clearColor(0.0, 0.0, 0.0, 1.0);context.enable(context.DEPTH_TEST);context.depthFunc(context.LEQUAL);context.clear(context.COLOR_BUFFER_BIT | context.DEPTH_BUFFER_BIT);}
</script>
- 76 -
3.2 SVG를 이용한 벡터 그래픽 기능의 구현
<svg>는 HTML5 이전부터 논의되던 그래픽 요소이며 대부분의 브라우저에서 지원하고
있는 그래픽 규격이다. XML 기반으로 그래픽 요소를 표현할 수 있고 벡터 기반이므로
확대/축소와 같은 출력 공간의 해상도 변화에도 픽셀의 도드라짐 현상 없이 미려한 그
래픽 출력이 가능하며 이러한 특징으로 인해 그래프의 출력 등에 유용하다.
[예시 : SVG 코드]
위 예제는 다음과 같은 벡터 기반의 이미지 결과를 표시하며 확대의 경우에도 픽셀이
도드라지는 계단현상(Jaggies)이 없음을 확인할 수 있다.
[그림 2-26] SVG 예제 코드의 실행 결과(좌)와 결과물의 부분 확대(우)
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg"width="300" height="300">
<rect width="100%" height="100%" fill="blue" /><circle cx="150" cy="150" r="100" fill="lightblue" /><text x="150" y="150" font-size="50" text-anchor="middle" fill="white">SVG</text></svg>
- 77 -
SVG의 규격은 매우 방대하므로 자세한 내용은 다음 링크들의 관련 문서를 참고한다.
- SVG 표준 규격
http://www.w3.org/TR/SVG/
- SVG 플래시 폴리필 라이브러리
http://code.google.com/p/svgweb/
- MDN의 SVG 관련 문서
http://developer.mozilla.org/ko/docs/Web/SVG
3.3 구현 기술 관점에서의 Canvas와 SVG 선택 기준
앞에서 설명한 바를 토대로 <canvas>와 <svg>의 선택 기준에 대해 살펴보도록 하자.
이 두 가지 기술 모두 그래픽을 표현하기 위한 각자의 규격을 포함하고 있지만 기본적
으로 표현하고자 하는 대상과 접근 방식이 완전히 다르다.
<canvas>의 경우 자바스크립트를 기반으로 동작하는 그래픽 요소이므로 이미지 필터,
애니메이션 등 동적인 처리가 필요한 게임 등의 웹 애플리케이션에 적합하다. <svg> 역
시 애니메이션에 관련된 규격이 있으나, 복잡한 객체와 애니메이션이 포함될 경우 사실
상 수작업으로 코드를 작성하는 것이 매우 어려우므로 그래프 등 확대와 축소가 주로
사용되는 그래픽 요구사항이 있을 경우에 적합하다. 가장 기본적인 차이점과 적합한 대
상은 다음과 같다.
<표 2-18> Canvas와 SVG의 비교
항목 <Canvas> <SVG>
출력 방식 비트맵 이미지 벡터
비트맵 이미지 편집 가능 불가
성능 의존성 자바스크립트의 복잡도 하위 요소에 의존 (개수 등)
대상 게임, 이미지 편집 등 그래프, 다이어그램 등
- 78 -
3.4 애니메이션 및 전환 효과
HTML5는 다양한 형식의 애니메이션 관련 기능을 가지고 있다. HTML5 애니메이션 기
능은 기본적으로 각각의 대상이 명확하게 지정되어 있으므로 선택의 기준이 그리 복잡
하지 않다.
<표 2-19> 주요 애니메이션 및 전환 기능의 비교
최근 이러한 다양한 애니메이션을 자바스크립트 레벨에서 통합할 수 있는 방법을 제
공하는 것을 목표로 Web Animations라는 새로운 W3C 표준 규격이 논의되고 있으나 아
직 규격이 확정되지 않았다. 각각의 상세 규격은 매우 방대하므로 각 애니메이션 관련
규격이 가진 특성을 이해하고 필요한 기능을 선택하는데 필요한 내용을 소개한다.
가. CSS3 Animation 및 Transition
CSS3에 추가된 Animation과 Transition은 HTML5에서 적용할 수 있는 가장 보편적인 애
니메이션 구현 방법이다. 이는 CSS 스타일을 통해 애니메이션을 수행할 수 있으며 CSS의
특성 상 시각적인 모든 DOM 요소에 적용이 가능하다. 좀 더 설명하자면 CSS3 Animation은
키프레임 기반의 애니메이션 기능을 제공하며 CSS3 Transition은 각 DOM 요소의 스타일
이 변경되었을 때 속성 값의 전환을 다양한 형태로 시각화할 수 있다. 자세한 규격 및
문서는 다음 링크를 참조한다.
규격 표현 대상 고려 사항
CSS Animation DOM 요소 키프레임 기반 애니메이션에 유리
CSS Transition DOM 요소 스타일 속성 값 변경에 대한 애니메이션에 유리
SVG Animation <svg> 없음
requestAnimationFrame( ) JavaScript,<canvas>미지원 브라우저에 대한 처리 필요
(e.g. setTimeout( ) 등)
- 79 -
- CSS3 Animation 관련
• 표준 규격 : http://www.w3.org/TR/css3-animations/
• MDN 참고 문서 : https://developer.mozilla.org/en-US/docs/Web/CSS/animation
- CSS3 Transition 관련
• 표준 규격 : http://www.w3.org/TR/css3-transitions/
• MDN 참고 문서 : https://developer.mozilla.org/en-US/docs/Web/CSS/transition
CSS3 Animation과 Transition이 가지는 성능 상의 특징은 대부분의 내용이 동일하다.
다만, Transition의 경우 전환 효과가 적용될 요소들과 속성을 브라우저가 지속적으로 모
니터링해야 하므로 속성이 많은 경우 일부 성능 저하 요인이 될 수 있다. 따라서 가급
적 필요한 효과에 한정해서 지정하는 것을 주의하여 개발하여야 한다.
나. SVG Animation
SVG는 하위 규격에 많은 애니메이션 기능을 포함하고 있으나 SVG에 한정적인 애니
메이션 방법으로 SVG 이외의 규격에는 적용할 수 없다. SVG 애니메이션에 대한 항목은
다음 링크를 참고한다.
- 표준 규격 : http://www.w3.org/TR/SVG/animate.html
- MDN 참조문서 : https://developer.mozilla.org/en-US/docs/Web/SVG/Element/animate
다. requestAnimationFrame( )
<canvas>와 같이 자바스크립트 기반의 그래픽 기능을 이용한 애니메이션 기능은 구현
방법에 다른 별다른 제약 사항은 존재하지 않는다. 그러나 자바스크립트의 특성상 메인
스레드를 사용하므로 과도한 애니메이션 연산이 웹 페이지의 렌더링이나 UI 동작 등을
지연시킬 수 있다.
setTimeout( )이나 setInterval( )과 같은 타이머를 통해 애니메이션을 출력하는 경우
브라우저에서 각 프레임을 렌더링하기 위한 시점을 결정하기 어렵기 때문에 성능에 영
향을 줄 가능성이 다른 방식에 비해 크다고 할 수 있다.
- 80 -
requestAnimationFrame( )은 이러한 문제를 해결하기 위해 렌더링을 위한 적절한 시점
에 자바스크립트 콜백 함수를 호출한다. 이 콜백 함수 내에서 구현된 그래픽 기능은 브
라우저의 렌더링 스케줄상에 큰 영향을 주지 않고 안정적으로 동작이 가능하다. 간략한
예제는 다음과 같다.
[예시 : requestAnimationFrame() 코드]
보다 자세한 사항은 다음 링크에 있는 표준 규격과 MDN의 관련 문서를 참고한다.
- 표준 규격 : http://www.w3.org/TR/animation-timing/#requestAnimationFrame
- 참조 문서 : https://msdn.microsoft.com/ko-kr/library/hh920765(v=vs.85).aspx
<canvas id="my_canvas" width="300" height="300">
HTML5 Canvas를 지원하지 않는 브라우저입니다.
</canvas>
<script type="text/javascript">
var canvas = document.getElementById("my_canvas");
// get "2D" graphics context
var context = canvas.getContext("2d");
window.requestAnimationFrame =
window.requestAnimationFrame ||
window.mozRequestAnimationFrame ||
window.webkitRequestAnimationFrame ||
window.msRequestAnimationFrame;
// set default fill color
context.fillStyle = "#000000";
var box_length = 0;
function render(timestamp) {
// drawing filled rectangle
context.fillRect(0, 0, box_length, box_length);
// grow up
box_length ++;
requestAnimationFrame(render);
}
requestAnimationFrame(render);
</script>
- 81 -
3.5 그래픽 적용사례
가. 적용사례
그래픽 기능은 가장 빈번하게 사용되는 기술이므로 일반적인 사례를 살펴보는 것은
큰 의미가 없을 것이다. 여기서는 그래픽 요소 기술 중 <canvas>와 <svg>기술에 대한
사례를 살펴보도록 한다.
- Canvas의 적용사례
Canvas의 가장 좋은 사례 중의 하나는 역시 게임이다. 익히 알고 있는‘앵그리버드'
역시 HTML5 버전이 제공되며 Canvas를 사용하고 있다.
[그림 2-27] Canvas 활용 게임(앵그리버드)
Canvas의 경우 앞에서 말한 바와 같이 다양한 이미지 처리 및 개발자가 직접 그래픽
출력을 위한 모듈을 구성할 수 있으므로 개발의 자유도가 높다. 특히 2D/3D 환경을
아우르는 기술을 통해 보다 효율적인 게임 렌더링 모듈을 구성할 수 있다.
- 82 -
- SVG의 적용사례
SVG는 앞에서 말한 바와 같이 확대/축소가 빈번한 환경에서 특히 유리하며 가장 대
표적인 경우가 바로 다이어그램과 차트이다. 예를 들어 데이터 시각화에서 가장 많이
사용되는 D3.js의 사례에서 보면 이러한 SVG를 이용한 시각화 사례를 쉽게 찾아볼
수 있다.
[그림 2-28] SVG를 이용한 D3.js 차트
SVG의 경우 벡터 기반의 입력을 기반으로 하고 있으므로 해상도에 대한 의존성에서
자유롭다. 특히 애니메이션 기능과 결합하면 복잡한 코드 구성없이도 미려한 이미지
를 생성할 수 있으므로 차트 등에 특히 적합하다. 단, XML 기반의 구조로 인해 개발
시 SVG의 복잡도를 해결할 방법을 고려해야 한다.
- 83 -
나. 상용 라이브러리
- Canvas 및 SVG 라이브러리
<표 2-20> Canvas 및 SVG 라이브러리
라이브러리 주소 설명
Kinetic.js
(오픈소스)http://kineticjs.com/
Ÿ Canvas 기반
Ÿ 객체 모델 지원
Ÿ 애니메이션 및 컨트롤 지원
Ÿ 다양한 입출력 관련 기능 제공
Fabric.js
(오픈소스)http://fabricjs.com/
Ÿ Canvas 기반
Ÿ 객체 모델 지원
Ÿ SVG 입출력 제공
Three.js
(오픈소스)http://threejs.org/
Ÿ Canvas, WebGL 기반
Ÿ 자바스크립트 3D 엔진
Ÿ 가장 범용으로 사용되는 순수 자바스크립트
3D 엔진
Babilon.js
(오픈소스)http://www.babylonjs.com/
Ÿ Canvas, WebGL 기반
Ÿ 자바스크립트 3D 엔진
D3.js
(오픈소스)http://d3js.org/
Ÿ 데이터 라이브러리 시각화 라이브러리
Ÿ 데이터 드리븐 모델
Ÿ 많은 차트 라이브러리들의 기반 소스로 활용
processing.js
(오픈소스)http://processingjs.org/
Ÿ Canvas 기반
Ÿ Processing 문법 지원
paper.js
(오픈소스)http://paperjs.org/
Ÿ Canvas 기반
Ÿ DOM 모델 지원
Ÿ 마우스 및 키보드 인터랙션 지원
Ÿ 벡터 모델 지원
Raphael
(오픈소스)
https://dmitrybaranovskiy.git
hub.io/raphael/
Ÿ SVG 라이브러리
Ÿ 자바스크립트 기반의 SVG 컨트롤 제공
Ÿ IE6 지원
Snap.svg
(오픈소스)http://snapsvg.io/
Ÿ SVG 라이브러리
Ÿ Raphaël과 동일 개발자
Ÿ 더 폭넓은 기능 지원
Ÿ IE 구버전 지원 안함
- 84 -
- 차트 라이브러리
<표 2-21> 주요 차트 라이브러리
라이브러리 주소 설명
Nwagon
(오픈소스)http://nuli.navercorp.com/sharing/nwagon
Ÿ 네이버 차트 오픈소스 라이브러리
Ÿ SVG 기반 IE6 지원
Ÿ 한글 문서 및 커뮤니티
AMCharts
(유료)http://www.amcharts.com/
Ÿ Canvas 기반
Ÿ 깔끔하고 광범위한 기능 지원
Chart.js
(오픈소스)http://www.chartjs.org/
Ÿ Canvas 기반
Ÿ 깔끔한 디자인
Ÿ 충실한 문서
DC.js
(오픈소스)http://dc-js.github.io/dc.js/
Ÿ D3.js 기반
Ÿ 반응형 그래프 인터랙션
dygraphs
(오픈소스)http://dygraphs.com/
Ÿ Canvas 기반
Ÿ 대량 데이터에 대한 핸들링 지원
NVD3
(오픈소스)http://nvd3.org/
Ÿ D3.js 기반
Ÿ 깔끔한 디자인
Highchart
(상용 유료)http://www.highcharts.com/
Ÿ SVG 기반
Ÿ 개인/비상업적 용도 무료
Ÿ 다양한 차트 지원
Ÿ IE6 지원
ExtJS 5 https://www.sencha.com/products/extjs/
Ÿ UI 컴포넌트, UI 위젯 100종 제공
Ÿ 트리메뉴지원 20종의 트리메뉴 지원
Ÿ 엑셀과 유사한 기능제공, 대용량
데이타 전송가능,
Ÿ 2D/3D 용 그래프, 차트 26종 이상
지원
Flotr2
(오픈소스)http://humblesoftware.com/flotr2/
Ÿ Canvas 기반
Ÿ 커스터마이징 손쉬움
Ÿ 타 라이브러리에 대한 의존성없음
- 85 -
3.6 그래픽 적용시 고려사항
그래픽 기술의 선택은 지금까지 설명한 내용을 기반으로 결정할 수 있을 것이며 이를
제외하면 가장 큰 고려 사항은 역시 성능이라고 할 수 있다. 순수 소프트웨어 기반의
렌더링 환경에서는 그래픽 관련 성능을 극적으로 개선할 수 있는 방법은 많지 않지만
다행스럽게도 최근 모바일을 포함한 거의 모든 디바이스는 하드웨어 가속을 제공하고
있으며 브라우저 역시 더 나은 이용자 경험을 위해 하드웨어 가속 기반의 그래픽 렌더
링 기능을 제공하고 있다.
특히 플래시 등 이전의 UI 컴포넌트나 그래픽 기능을 제공하는 플러그인들에서 HTML5
기반의 그래픽 기능으로 전환할 때 성능으로 인한 이슈로 인해 전환이 우려된다면 빠른
성능을 위해 렌더링 성능의 위험 인자를 제거하는 과정이 필요하다.
가. 렌더링 성능 저하의 주요 요인
(레이아웃의 재계산과 Repaint의 발생)
일반적인 경우는 웹 페이지의 마크업 요소들을 브라우저가 해석하여 화면에 처리하는
과정을 간단하게 보자면 다음과 같다.
a. 웹 문서 내의 마크업들은 파싱을 통해 DOM 노드들로 해석되며 DOM 노드로
구성된 트리 형태로 메모리에 적재된다.
b. 브라우저 내의 렌더링 엔진은 DOM 노드들을 개별적인 이미지로 만들어 낸다.
c. DOM 트리의 구조 및 스타일에 따라 화면에 이미지를 합성한다. 대다수의 렌
더링 성능 병목은 노드들을 이미지로 만드는 과정과 이들을 화면에 배치하여
그려내는 단계에서 많이 일어난다. 특히 렌더링에 필요한 웹페이지의 일부 이
미지를 다시 그리는(Repaint) 동작을 발생시킨다.
- Reflow
Layout, Layouting 혹은 Relayout이라고 부르기도 하는 Reflow는 렌더 트리의
일부 혹은 전체가 다시 계산될 필요가 있어 DOM 노드의 넓이가 재계산되는 경
우를 의미한다. Reflow에서 특정 노드의 레이아웃 연산이 상위 혹은 형제 노드
들에 대한 영향을 줄 수 있고 특히 변경 사항이 폭이나 높이, 위치에 관련된
경우는 레이아웃의 연쇄 발생이 일어날 수 있다.
- 86 -
[그림 2-29] 레이아웃 발생의 예
- Repaint
DOM 노드의 (left, width 등의) 기하 정보 변경이나 레이어 이미지에 직접적으
로 영향을 주는 스타일의 속성 변경과 같은 경우는 화면의 일부가 갱신되어야
한다. 이러한 스크린 상의 일부 혹은 전체 갱신을 Repaint 혹은 Redraw라고 한
다. 만약 레이아웃과 Repaint를 비롯한 각종 성능 인자들을 추적하고 싶다면 각
브라우저의 개발자도구에서 확인할 수 있다.
[그림 2-30] Layouting으로 인한 Repaint 발생의 예
- 87 -
나. 렌더링 성능 최적화 접근 방법
브라우저에서의 렌더링과 연관되는 문제점은 레이아웃의 위치나 크기 정보 등 레이아
웃 연산과 렌더링을 위한 비트맵 출력 오버헤드이며 하드웨어 가속에 있어서는 생성된
비트맵의 GPU 업로드 오버헤드가 포함된다.
DOM 노드 내의 콘텐츠나 스타일의 변경 등은 렌더링 성능 저하의 가장 큰 원인이 된다.
다만, 이는 웹 개발자가 렌더링 패스를 선택할 수 없는 철저한 브라우저의 영역이므로
유일한 최적화 방법은 프로그래밍 된 렌더링 프로세스에서 처리되는 데이터를 예상해서
병목 구간을 피하도록 구현한다.
- 불필요한 렌더링 요소 회피를 통한 최적화의 예
모던 브라우저들이 구현하고 있는 하드웨어 가속 렌더링은 대다수의 그래픽 연산을
GPU(Graphics Processing Unit)를 이용하여 처리 성능을 높이는 방법이다. 웹 규
격들은 대다수가 표현되어야 할 형태는 지정하고 있지만 이를 하드웨어 가속에
어떻게 적용할 지에 대한 정보는 명시적으로 가지고 있지 않기 때문에 브라우
저들은 빠른 출력을 위해 많은 부분들을 고민하고 처리해왔으나 이는 일반화할
수 있는 경우들에 한정하여 최적화되어 있다.
예를 들어 투명도(Opacity)의 경우 겹쳐진 다른 이미지와 픽셀 단위의 혼합(Blending)
해야 하므로 다른 레이어의 이미지와 함께 한 장의 이미지로 나타내는 것은 일반
적으로도 매우 불합리하다. 같은 이유로 매번 표시되는 이미지가 변경되는 <video>
element는 별도의 레이어로 분리해두는 것이 보다 효과적이다.
이를 이용하는 가장 손쉬운 방법은 자주 변경될 것으로 생각되는 DOM 노드를 하드
웨어 가속 처리가 되는 단일한 단위로 변경하는 것이다. 예를 들어 CSS 속성을 자주
본 개발자라면 translateZ(0); 속성을 확인한 경우가 있을 것이다. translateZ(0);는 해
당 노드의 Z축 값으로 0을 주는 무의미한 코드로 보일 수 있지만, 해당 노드를
강제로 레이어를 변경하는 일종의 핵(Hack) 트릭으로 이용된다. 다만 이러한 트
릭은 추가적인 메모리를 소모하므로 한정된 메모리를 넘어설 때 새로운 오버헤
드를 발생할 수 있다.
- 88 -
1. 개요
전자문서의 경우 빠른 웹 에디터 리포팅툴과 그리드 컴포넌트, 위변조 복제 방지를
위한 DRM, 워터마킹과 같은 전자문서 보호에 비표준 기술을 사용했다.
웹 에디터는 브라우저 내에서 풍부한 텍스트를 입력할 수 있도록 하는 웹 구성 요소
이다. 대체적으로 HTML 기반 웹 에디터는 운영자나 이용자가 손쉽게 시스템에서 콘텐
츠를 만들 수 있는 콘텐츠 관리 시스템이나 게시판 등에서 사용된다.
리포팅 관련 기술은 리포트를 만들어 주는 서버 기술과 생성된 리포트를 보여주는 클
라이언트 기술이 핵심이다. 이때 생성된 리포트를 보기 위해서는 일반적으로 전용 뷰어
의 설치가 필요하다. 리포트가 만약 PDF라면 전용뷰어 설치 없이 일반 브라우저에서 볼
수 있다. 최근에는 PDF 또한 자바스크립트에서 바로 랜더링해서 보여 줄 수 있다. 여기
서는 HTML5를 활용해서 PDF뷰어를 구현하기 위한 기초적인 HTML5 관련 API와 PDF를
랜더링 해주는 기술들을 살펴본다.
그리드 컴포넌트는 웹 상에서 엑셀과 유사한 테이블 뷰 및 연산 기능을 수행하는 기
능을 담당한다. CS(Client-Server), RIA(Rich Internet Application) 환경에서 처리되던 많
은 업무 영역들이 HTML5 기반 표준 웹 환경으로 전환되고 있다. 이를 위해서는 복잡한
형태의 표 기반 레이아웃이나 엑셀 import를 통해 데이터를 처리할 수 있는 기술이 필
요하고 데이터의 경우도 XML 형식과 배열 형식, JSON 형식을 파일이나 String 형태로
지원해야 한다.
전자문서 위변조 방지의 경우 출력물의 위변조 방지 및 디지털 콘텐츠의 무단 사용을
막아, 제공자의 권리와 이익을 보호하는 기술로 민원 문서 발급, 내부 전자 문서의 유출
방지를 위한 DRM 기술 등을 전자문서 보호 및 출력을 위해 지원해야 한다. 최근 PC 및
모바일 환경에서 전자 문서를 확인할 수 있는 페이퍼리스 방식의 전자문서 솔루션도 빠
르게 보급되고 있으나 대부분 앱 방식으로 배포하고 있다.
6 전자문서
- 89 -
2. 사용현황
브라우저 기반으로 웹 콘텐츠 관리 및 화면 관리의 경우 빠른 실행 속도를 위해 웹
에디터, 리포팅 툴과 그리드 및 차트 컴포넌트가 NPAPI나 ActiveX 기반 플러그인을 사
용했으며, 전자문서의 위변조, 복제 방지를 위한 DRM과 워터마킹, 화면캡쳐방지, 원본진
본 확인을 위한 전자서명 및 시점 인증 확인, 전자문서 출력 등을 위해 비표준 기술을
클라이언트에 배포, 처리했다.
최근 웹 콘텐츠 관리의 경우 플러그인을 통해 추가 프로그램을 설치 없이 웹 표준
Canvas와 SVG 기반 오픈소스를 활용하는 방식으로 전환하고 있으며, 전자문서의 경우
클라우드 서버를 통한 서버 처리 후 문서 뷰어 형태로 제공하는 방식이나 EXE 실행파일
방식으로 전환하고 있다.
현재 전자문서의 비표준 기술을 가장 많이 활용하고 있는 분야는 복잡한 수식 연산과
다양한 화면 구성, 실시간 문서 변환이 필요한 공공, 금융, 협회, 학교, 병원 등으로 최
근 웹 표준 전환을 위한 다양한 솔루션 적용을 시도하고 있다.
2.1 웹 에디터
현재 웹 에디터에 WYSIWYG이나 풍부한 기능을 제공하는 오픈소스 기반의 다양한 솔
루션이 개발되고 있으며 국내의 경우 네이버, 다음 등의 포털에서 상용 수준의 오픈소스
웹 에디터를 배포, 지원하고 있다.
웹 취약점이 있는 웹 에디터 버전을 사용하는 경우 파일 업로드 시 보안 취약점에 노
출될 수 있으므로 오픈소스 기반의 웹 에디터를 사용할 경우 공개된 보안 취약점을 보
완한 최신 버전을 사용해야 한다.
<표 2-22> 웹 에디터 종류
제품명 제품 설명 개발사
SmartEditor Basic
SmartEditor는 자바스크립트로 구현된 웹 기반의
WYSIWYG 편집기이다. 글꼴, 글자 크기, 줄 간격 등을
자유롭게 설정할 수 있으며, 단어 찾기/바꾸기와 같은
편리한 기능을 제공한다.
네이버
- 90 -
2.2 리포팅 툴
리포팅 관련 비표준 기술은 주로 리포팅 솔루션사에서 배포한 전용 뷰어를 사용할 때
사용된다. 주요 기능으로는 문서 뷰어, 문서 위조방지, 프린터 출력 기능을 제공하고 있
으며, HTML5 기술 기반으로 리포팅 툴을 제공할 때 문서 뷰어와 문서 위조방지는 대체
가능하지만 프린터 출력 기능은 EXE 설치와 같은 기술을 사용해야 한다. 주요 리포팅
솔루션사의 배포업체는 아래와 같다. 최근 클립소프트는 클라우드 서버 기반의 문서 스
트리밍 방식의 HTML5 웹 리포팅 툴을 개발하였다.
<표 2-23> 주요 리포팅 솔루션
DaumEditor
Daum Editor는 OpenAPI, Microformat, RDF 등을
지원하여 시맨틱 콘텐츠 생산을 돕고 웹 데이터의 상호
연결성을 높였다.
다음
DEXT5 Editor
(상용)
웹 접근성 및 웹 표준을 준수하는 HTML5.0 기반의 웹
편집기로 별도의 설치가 필요 없는 Non-ActiveX 방식으로
5대 브라우저를 완벽 호환하며, XSS와 같은 보안 문제와
모바일까지 지원한다. (http://www.dext5.com)
라온위즈기술
namo CrossEditor 브라우저 상 다양한 텍스트를 입력할 수 있는 웹 구성요소 지원 나모인터렉티브
S3 웹저작도구브라우저 상 텍스트 및 멀티미디어 자료 삽입 지원,
IE9 이상 버전에서 지원Fdesk
CKEditor
GPL, LGPL, MPL 등의 오픈소스 라이선스를 따르고 있다.
높은 접근성을 갖추고 있다. 4.0 버전에서는 스킨 및 플러그인
기능을 추가 할 수 있다.
CKSource
제품명 (리포팅 툴) 배포사
오즈 리포트 (OZ ActiveX Viewer) 포시에스
크로닉스 리포트 (Crownix Report Viewer) 엠투소프트
CLIP Report 4.0 클립소프트
유비리포트 (UbiViewer) 유비디시전
Reportexpress enterprise ㈜캡소프트
Stream Docs 이파피루스
AI-Report 솔비텍
- 91 -
2.3 그리드 컴포넌트
그리드 컴포넌트는 사용 목적, 크로스 브라우저와 멀티 플랫폼 지원 유무에 따라 상
용 유료 솔루션(IBSheet, MiPlatform, XPlatform, Flex)과 오픈소스를 활용하여 개발한다.
국내외 업체는 대부분은 플래시 기반 제품으로 업무 기반에 최적화된 그리드 컴포넌
트를 제공하고 있으며, 기업 및 공공 웹 사이트 지원을 위한 개발 편의성과 생산성을
높일 수 있는 API 방식의 서버 연동 기술을 제공하고 있다. 또한 엑셀 등록 및 화면 UI
수준을 제공하고 있다.
그리드 특성 상 데이터는 XML 형식과 배열 형식, JSON 형식, CSV(comma-separated value
s) 와 TSV(tab-separated values)형식을 지원하는 방식으로, 데이터 형식을 변환하는 기능
을 제공하고 있다.
크롬 45버전 이상에서 기본 NPAPI 기반 Flash Player가 구동하지 않는 문제가 있어,
최근 서버 + HTML5 기반의 그리드 컴포넌트가 빠르게 전환 보급되고 있다.
<표 2-24> 주요 플러그인 기반 그리드 컴포넌트
제품명 기반 기술 개발사
IBSheet 7 ActiveX, 웹표준 아이비리더스
MiPlatform RIA 투비소프트
RealGRID+WEB 플래시, 웹표준 (주)우리테크인터내셔날
Flex Flex Abobe
GirdFX 플래시 Software FX
WiseGirdFX 플래시 유니포스트
Extjs5 웹표준 미래웹기술연구소
SBGrid 2.0 웹표준 소프트보울
Sencha Touch Grid 웹표준 미래웹기술연구소
웹스퀘어5 Grid 웹표준 인스웨이브시스템즈
rMate Grid(플래시버전) 플래시 리아모어소프트
- 92 -
2.4 문서 보호 및 출력
전자문서 보호 및 출력 솔루션은 다양한 웹 사용자 환경에서 전자 문서의 원본 검증
과 위변조 방지 및 위변조 추적을 위한 기능을 제공하기 위해 제공하며 대부분 상용 유
료 솔루션(마크애니, 파수닷컴), 서버 기반 Enterprise Content Management 솔루션(사이
버다임, 파수닷컴, 오라클, IBM)과 같이 문서 보호와 유통을 결합한 일체형 솔루션, 오픈
오피스, pdf.js와 같은 문서 뷰어 및 문서 편집 기능을 지원하는 오픈소스를 활용하여 개
발한다.
대부분의 문서보호 및 출력 기능은 운영체제 내 프린터 드라이버 및 전자문서의 빠른
실행을 위해 비표준 기술을 활용했으나, 최근 클라우드 기반의 Paperless 솔루션들이 등
장하면서 서버 기반의 문서 보호 및 출력 기술을 대체하고 있다.
<표 2-25> 전자문서 보호 솔루션 제품들
3. 대체기술
전자문서 대체기술의 경우 두가지 대응 방안으로 구분하여 대체기술 적용이 필요하며
웹 콘텐츠 관리 및 화면 관리의 경우 빠른 실행 속도를 위해 웹 에디터, 리포팅 툴과
그리드 및 차트 컴포넌트의 경우 Pure Web기반 솔루션의 서버 연동을 통해 대부분 해
결이 가능하나 전자문서 보호 및 위변조 방지의 경우 운영체제 내 커널과 프린터 드라
이버 등의 동작을 감시해야 하는 기능을 포함하고 있어 현재로써는 EXE 실행파일 방식
으로 대응하거나, 클라우드 프린터가 지원될 경우 모든 문서를 스트리밍 방식으로 위변
조 및 개인정보보호를 서버에서 처리하고 클라우드 프린터를 통해 출력하는 방식을 제
공할 수 있다.
제품명 기반 기술 개발사
ePage SAFER for NoAX EXE, 웹표준 마크애니(위변조 방지)
Fasoo ePrint ActiveX 파수닷컴(출력물 개인정보보호)
Perfact Paperless Solution ActiveX 레드비씨(온라인 전자문서 관리)
Office Hard 웹표준 지란지교시큐리티
리자드 클라우드 웹표준 이노티움
- 93 -
3.1 웹 에디터
현재 웹 에디터에 WYSIWYG이나 풍부한 기능을 제공하는 오픈소스 기반의 다양한
솔루션이 개발되고 있으며 국내의 경우 네이버, 다음 등의 포털에서 오픈소스 웹 에디
터를 배포, 지원하고 있다. 웹 에디터의 경우 지속적인 전환 홍보 및 기술적 난이도가
낮아 오픈소스나 상용 솔루션을 이용해 대체가 가능하다.
<표 2-26> 국내외 오픈 에디터의 특징
3.2 리포팅 툴
리포팅 기술은 증권차트, 통계 그래프, 문서 레이아웃 등 리포트 템플릿을 만드는 리
포트 디자이너와 데이터베이스의 값을 읽어와 지정된 템플릿에 리포트 형태로 렌더링
해주는 리포팅 엔진 기술 그리고 렌더링 된 화면을 보는 리포팅 뷰어로 구성된다. 과거
에는 웹에서 리포팅하기 위해서는 리포팅 뷰어의 경우 별도의 ActiveX로 구현된 전용
뷰어를 설치해야 볼 수 있었지만 최근 HTML5의 그래픽처리 지원이 강화됨에 따라 전용
뷰어 없이 HTML5로 렌더링해서 바로 볼 수 있다. 또한 리포트를 PDF로 변환하는 것까
지 가능해져서 PDF를 보기 위한 플러그인 없이도 이용이 가능하다. 최근에는 랜더링 속
도를 가속하기 위해 전용 리포트 서버(클라우드) 기반으로 최종 리포트 결과물을 생성하
고 클라이언트 뷰어에 스트리밍으로 화면을 보여주는 방식도 쓰이고 있다.
구분 국산 외산
BrandSmartEdit
or Basic
Naver
Smart
Editor
Daum
EditorFCKeditor TinyMCE markItUp
License LGPLNHN
Corp.
Daum
Corp.
GPL, LGPL,
MPL, CDLLGPL MIT/GPL
Demo Yes None None Yes Yes Yes
Cross
Browser
IE/FF/
CR/SF/OP
IE/FF/
CR/OP
IE/FF/
CR/SF/OP
IE/FF
CR/SF/OP
IE/FF
CR/SF/OP
IE/FF
CR/SF/OP
- 94 -
가. PDF 처리 적용
브라우저에서 PDF를 보여주기 위한 방법으로는 일반적으로 어도비리더와 같은 별도
의 플러그인을 설치해서 보여주었지만 크롬, 파이어폭스 브라우저는 PDF 뷰어를 내장하
고 있다. 최근에는 브라우저 성능향상으로 HTML5 및 자바스크립트만으로 화면을 바로 PDF
로 렌더링 해주는 오픈소스 자바스크립트 라이브러리들이 있다.
- jsPDF : jsPDF는 MIT라이센스로 공개되어 있으며 대부분의 브라우저에서 지원한다.
§ 공식사이트 : http://parall.ax/products/jspdf
§ 오픈소스코드 : https://github.com/MrRio/jsPDF
§ 각종 활용 예제 : http://mrrio.github.io/jsPDF
- Mozilla pdf.js : 모질라에서 자바스크립트 오픈소스로 진행하고 있으며, 파이어폭
스, 크롬, 오페라 브라우저를 지원한다. 다른 종류의 브라우저를 지원하려면 여기
서 제공하는 별도의 스크립트 라이브러리를 이용할 수도 있다.
§ 공식사이트 : https://mozillalabs.com/en-US/pdfjs
§ 오픈소스코드 : http://mozilla.github.io/pdf.js
- pdfkit: MIT라이센스로 공개되어 있으며, Node와 브라우저에서 PDF생성을 지원한다.
pdfkit은 CoffeeScript로 작성되어 있으며 npm패키지 매니저를 이용해 설치가능하다.
§ 공식사이트 : http://pdfkit.org
§ 오픈소스코드 : https://github.com/devongovett/pdfkit
3.3 그리드 컴포넌트
Pure Web 기반으로는 jqGrid, ExtJS(Sencha), 리아모어소프트의 rMate, 인스웨이브 웹
스케어를 활용하여 그리드를 표현하는 방법이 대중적으로 사용되고 있으며, 상용 그리
드 컴포넌트로는 Adobe Flex나 투비소프트의 마이플랫폼과 같은 RIA기반 UI 솔루션이
대중적으로 사용되고 있다. 그리드 컴포넌트도 지속적인 전환 홍보 및 기술적 난이도가
낮아 오픈소스나 상용 솔루션을 이용해 대체가 가능하다.
- 95 -
<표 2-27> 웹 표준 그리드 컴포넌트
3.4 문서 보호 및 출력
전자문서의 경우 빠른 리포팅과 그리드 처리, 위변조, 복제 방지를 위한 DRM과 워터
마킹, 화면캡쳐방지, 원본과 진본 확인을 위한 전자서명 및 시점 인증 확인, 전자문서
출력 등을 위해 비표준 기술을 클라이언트에 배포, 처리했던 방식에서 클라우드 기반
서버 시스템을 통해 관련 기능을 제공하고, 화면 캡쳐와 같은 키보드 인식 및 이벤트
인식의 경우 실행파일과 Custom URI Scheme 연동이나 Native Messaging을 통해 기 설
치된 실행 파일과 연동을 통해 서비스를 제공할 수 있다.
전자문서 출력의 경우 클라우드 프린터를 활용하여 서비스를 제공할 수 있으나, 프린
터가 클라우드 프린터 지원 여부 확인이 필요하며, 인쇄 영역을 지정할 경우 CSS로 인쇄
영역을 지정할 수 있다.
제품명 기반 기술 개발사 지원 브라우저
WebSquare HTML5, 자바스크립트 INSWAVE
IE, Firefox,
Chrome, Safari,
Opera
rMate Grid(HTML5) HTML5, 자바스크립트 리아모어소프트
JUI HTML5, 자바스크립트 제니퍼소프트
jqGrid HTML5, 자바스크립트 JQuery Foundation
Ext.JS 자바스크립트 Sencha Inc
- 96 -
1. 개요
웹에서 파일 업로드/다운로드는 HTML5 File API를 통해 별도 플러그인 없이도 개발
가능하다. 하지만 파일 접근 및 파일명, 파일 디렉토리 이동과 같은 기능을 고려하거나
대용량 파일 전송 시 속도 개선을 위해 웹이 아닌 UDP와 같은 별도의 Protocol 사용을
위해 ActiveX로 제작된 네트워크 가속이나 특정 디렉토리에 파일을 다운로드하기 위한
별도 컴포넌트를 개발하는 경우가 있다.
최신 HTML5 스펙에 추가된 File API와 개선된 XMLHttpRequest를 활용할 경우 자바
스크립트만으로 파일업로드/다운로드하는 코드 예제뿐만 아니라 File API를 이용해 이용
자 File 정보를 보여주고 Drag&Drop으로 처리가 가능하다. 또한 XMLHttpRequest를 활
용해서 파일전송 과정을 이벤트로 모니터링하고 중단될 경우 재 연결과 같은 기능을 구
현할 수 있다. 참고로 여기서 사용하는 HTML5 File API의 경우 하위 브라우저 버전에서
는 동작하지 않는다. (IE10이상, 크롬 43이상, 파이어폭스 38버전 이상에서 동작한다)
2. 사용현황
파일 전송 관련한 비표준 플러그인의 주요 사용처는 아래 표와 같다. 메일과 같이 기
본 기능에 사용하는 경우도 있지만 웹 하드 서비스와 같이 업로드/다운로드 속도를 가
속하기 위해 사용하는 경우가 대부분이다. 파일 처리를 위한 비표준 플러그인 배포의
경우 각 서비스 업체에서 만들어 배포하는 경우도 있고, 전문 솔루션사에서 개발하여
일괄적으로 배포하는 경우가 대부분이다.
<표 2-28> 파일전송 ActiveX 사용현황
7 파일처리
사용 케이스 주요 사용처
웹하드 서비스에서 파일 업로드/다운로드 대부분 웹하드 업체
메일 서비스에서 파일 첨부 Daum, Naver, Nate 등
SW 자료실 다운로드 관리 네이버, 심파일, 쉐어웨어코리아, 보물섬 등
- 97 -
3. 대체 기술
파일 전송을 위한 ActiveX 대체기술로는 HTML5, 플래시, Java, 브라우저 플러그인 등이
있다. 여기에서는 추가 설치 없이 대부분 최신 브라우저에서 지원 가능한 기술로 HTML5
및 관련 API를 활용해서 설명한다. 여기서는 HTML5 및 File API를 바로 사용했지만, 실제
구현할 때에는 브라우저 버전에 따라 해당 API를 지원하지 않는 브라우저에 대해서는 일반
Form을 이용해 업로드 하도록 구현해야 한다.
<표 2-29> XMLHttpReqeust readyState 값
3.1 HTML5 File API 사용
HTML5는 바이너리 데이터와 사용자 로컬 파일 시스템과 상호작용을 위한 정말 강력
한 API를 지원한다. File API로 동기/비동기로 파일을 읽고, Blob을 생성하며, 임의의 위치
에 파일을 작성하고, 파일의 디렉토리를 재귀호출하고, 데스크탑에서 브라우저로 드래그
앤 드롭을 실행하고, XMLHttpRequest2를 사용해서 바이너리 파일을 업로드 할 수 있다.
HTML5 파일 접근과 관련한 주요 내용은 HTML5Rocks의 파일 접근 제어에 대한 참고
자료(http://www.html5rocks.com/ko/features/file_access)를 확인하면 빠르게 웹 표준 방식
으로 안전하게 파일을 관리 할 수 있다.
사용 케이스 관련 API
다중 파일 선택 <input> 태그 multiple 속성
이용자 파일 정보 접근 File API
Drag&Drop drop 이벤트 핸들러
파일 업로드 상태 모니터링 XMLHttpRequest 이벤트 핸들러
파일 다운로드 상태 모니터링 XMLHttpRequest 이벤트 핸들러
- 98 -
3.2 File API library사용
파일 업로드 방식은 동기방식과 비동식방식으로 나눌 수 있으며, 대체로 동기방식은
멀티파일 업로드처리를 하는데 이 경우 화면이 리플레쉬되고 특정 페이지로 이동하는
문제가 있어, 단일페이지 웹 애플리케이션에서는 비동기 파일 업로드가 필요하다. 하지
만 AngularJS 만으론 이러한 요구사항을 처리하기엔 부족함이 많다. 최근 이러한 문제를
오픈소스인 angular-file-upload를 이용하여 비동기 파일업로드를 처리할 수 있다. angular
-file-upload는 낮은 브라우저 버전에서도 사용이 가능하며, shim과 함께 사용할 경우 IE8, I
E9 버전에서도 사용이 가능하다.
<표 2-30> 웹 표준 File API 컴포넌트
제품명 기반 기술 개발사 지원 브라우저
넥사크로(nexacro) File API, 자바스크립트 넥사크로
IE, Firefox,
Chrome, Safari,
Opera
RESUMABLE.js 상동 오픈소스
Angular 상동 Google
jQuery-File-Upload 상동 JQuery Foundation
uploadify 상동 Reactiveapps(Donate)
dropzonejs File API, Drag&Drop dropzonejs(Donate)
Plupload File API, Drag&Drop Ephox(GPLv2)
RAPID5대용량(2G)
Drag&Drop라온위즈
- 99 -
1. 개요
최근 웹에서 파일 게임 런처는 웹 페이지 상에서 로컬 PC에 있는 게임 애플리케이션을
실행시켜 주고, 사용자가 게임을 즐기는 데에 필요한 필수적인 기능들을 관리할 수 있
도록 해 주는 웹에서 실행되는 애플리케이션이다.
보안상의 문제로 웹 브라우저에서는 직접적으로 사용자의 PC 파일 시스템에 접근하
거나 사용자의 PC에 설치되어 있는 애플리케이션을 실행할 수 없는데, 이와 같은 문제
를 해결하기 위해 인터넷 익스플로러에서는 ActiveX, 크롬 등의 브라우저에서는 NPAPI
와 같은 별도 플러그인을 통해 구현 된다.
2. 사용현황
게임 런처의 주요 기능은 사용자 PC내의 게임 애플리케이션을 웹브라우저 상에서 실
행하도록 하고 이를 통해 버전 확인 및 패치 작업을 진행하도록 하는 것이다. 웹 브라
우저에서 PC내에 설치되어 있는 애플리케이션을 곧바로 실행하는 것은 보안상의 문제
로 불가능하며, 이에 따라 사용자 PC내 파일 시스템 접근권한을 획득하고 효율적인 게
임 애플리케이션 실행환경을 확보하기 위해 ActiveX나 NPAPI가 사용되고 있다. 사용자
의 PC내에 설치되어 있는 게임 애플리케이션을 호출하기 위한 URL 프로토콜 핸들러를
미리 브라우저에 등록하고 이를 통해 해당 애플리케이션을 실행하는 방법도 가능하지
만, 사용자가 직접 브라우저에 게임 애플리케이션 실행을 위한 핸들러를 등록해야 하는
과정과 실제 구현 시 일정시간 지연이 발생하는 불편함을 초래할 수 있고, 일관된 서비스
제공이 어려운 부분이 있어 현재 사용되지 않고 있다.
8 게임
- 100 -
게임 런처가 브라우저에서 호출되면 통상 게임 런처는 아래의 기능을 실행하여 사용
자가 원활하게 게임을 진행할 수 있도록 한다.
- 웹브라우저에서 게임 애플리케이션 실행
- 게임 파일의 다운로드
- 게임 패치 확인 및 업그레이드
- 각종 보안 모듈의 설치 및 업그레이드
위의 기능을 브라우저에서 직접 실행하도록 하기 위해 게임 개발사와 퍼블리셔는 IE
환경에서 ActiveX를, 구글 크롬이나 파이어폭스 등의 환경에서는 NPAPI를 이용한 별도의
플러그인을 제작하여 배포 했다. 그러나 최근 구글이 더 이상 NPAPI를 지원하지 않도록
정책을 바꿈에 따라 크롬에서는 게임런처를 활용하기가 대단히 어렵게 변화되었다.
3. 대체기술
게임런처의 가장 핵심적인 역할은 브라우저 내에서 이용자의 PC에 설치되어 있는 게
임 애플리케이션 실행 파일을 호출하여 게임내의 버전 체크 및 패치 작업을 진행하는
것이다. 이와 같은 게임 실행 방식은 보안상의 이유로 인하여 별도의 ActiveX나 플러그
인 없이 구현 자체가 불가능한 것으로, 본 안내서는 게임런처 기능을 반드시 활용하고
자 하는 서비스 제공자가 호환성과 이용자 경험을 극대화 할 수 있도록 하기 위한 일련
의 방안들을 제공하고자 한다.
3.1 실행파일 방식
게임런처의 가장 기본적인 기능은 로컬 PC내의 게임 애플리케이션의 실행이다. 따라
서 게임런처를 통해 진행하는 게임 실행 기능은 가능한 최소화 하는 것이 게임런처의
실행 시 발생되는 오류를 최소화하는 가장 좋은 방법이다. 통상 게임런처 내에 게임 실
행을 위한 애플리케이션 기능뿐만 아니라, 다운로드 모듈, 보안 모듈 등의 여러 가지 기
능을 다수 탑재하는 것보다는 가능한 기능을 분할하여 제공하는 것이 효과적이다. 기본
적인 실행 파일 다운로드 기능의 경우는 HTML5 File API 요소를 활용하도록 하고 게임
런처와 브라우저와 통신은 URL Protocol Handler나 로컬 웹서버 내장을 통한 브라우저
연동 방식을 이용하는 실행파일(EXE) 설치 방식이 가장 현실적이다.
- 101 -
3.2 웹 코어 내장 방식
게임런처의 브라우저 종속 문제를 해결하는 방안으로 WebView 오픈소스 코어를 게임
런처에 내장해서 개발하는 방식으로 chromium-webview core를 게임런처에 포함해서 실
행파일 방식으로 구현하고 내장 웹뷰를 통해 브라우저와 동일한 기능(게임사 웹서버 접
근)을 수행하는 방법이다. 이를 위해서는 오픈소스 버전 변화에 대한 지속적인 대응 등
개발 리소스가 지속적으로 투입되는 단점이 있지만, 브라우저 플러그인을 사용하지 않
고 개발하며 배포하기 때문에 향후 브라우저의 개발사 정책 변경에 유연하게 대응 할
수 있는 장점이 있다.
3.3 브라우저별 플러그인으로 변환
C/C++로 개발된 게임을 asm.js를 사용하여 웹에서 실행 가능하도록 할 수 있다. asm.js
는 충분히 상용화 가능한 수준의 퍼포먼스를 제공한다. 다만 asm.js는 WebAssembly로
전환해서 현재 개발 중인 기술로 상용 서비스에 적용 시 안전성과 향후 변화 관리가 추
가될 가능성이 있다.
- 102 -
1. 개요
웹 서비스 상에서 ActiveX, NPAPI 같은 플러그인을 사용하지 않고 시스템의 화면 정
보의 일부 내용을 확인 방법으로 현재 가장 많이 활용하는 기술은 navigator 객체의 유
저 에이전트를 확인하는 방법이며, 최근엔 CSS 미디어쿼리를 활용하여 시스템의 해상도
와 같은 화면 정보를 함께 확인 하는 방법을 가장 일반적으로 사용한다.
장치관리(카메라, 음성 저장, 외장 디바이스 인식, 프린터 드라이브 설정 및 출력)의
경우도 기존에는 일반적으로 ActiveX나 NPAPI 기반 플러그인을 사용했으나 최근 OS 장
치 관리는 기본 보안 정책인 샌드박스(sandbox) 보안 모델을 위반하는 사례가 급증하고,
다수의 심각한 문제(드라이버 변조를 통한 OS 시스템 파괴, 메모리 해킹, 원격 장치 모
니터링)를 야기할 가능성을 내포하고 있어, 브라우저 개발사들은 관련 기술 지원을 중단
하거나, 보안모델을 위반하지 않는 안전한 방식으로 대체기술(NaCI, pNaCI)을 제공하고
있다.
그럼에도 불구하고 현재 브라우저 개발사는 보안 정책상 완벽한 장치관리 기능은 제
공하지 않고 있다. 다만 일부 브라우저의 경우 화상회의와 같은 킬러서비스를 제공하기
위해 WebRTC와 같은 표준 규격을 활용하여 카메라, 음성 저장 기능을 제공하거나, W3C
Device API 및 System Application API, Geolocation API, DeviceOrientation Event, Media
Capture and Streams, Web Bluetooth, Web NFC를 통해 블루투스 기기 접근 및 USB 하
드웨어, 카메라 접근을 위한 API를 제공하고 있다. 이러한 기능들은 기본적으로 이용자의
H/W 접근 인지 및 사용동의 후 기능 사용이 가능하다.
PC 원격제어, VNC(Virtual Network Computing) 프로그램은 대부분 ActiveX와 NPAPI,
Java 기반 플러그인 기술을 사용하여 구축되고 있으며, 플러그인은 시스템 자원 제어와
시스템 식별 확인(라이센스), 빠른 제어 실행속도와 안정적인 세션관리, 원격 프로그램
호출 이벤트를 전달을 지원하기 위해 사용하고 있으며, 윈도우 PC 원격제어의 경우 별도의
Protocol(원격 데스크탑 Protocol) 지원하기 위해 Remote Desktop ActiveX control interfaces
플러그인 기술이나 Terminal Services Session Broker를 활용하고 있다.
9 시스템정보 확인 및 PC제어
- 103 -
2. 사용현황
시스템 정보 확인 및 장치 관리의 주요한 기능은 아래와 같이 이용자 단말 내의 H/W
및 드라이버 정보 확인 등과 같이 시스템 자원에 대한 정보 획득과 시스템과 이용자를
식별하기 위한 맥 어드레스(고유값) 정보를 서버에 전송하기 위해 ActiveX나 NPAPI와
같은 확장 기술을 사용하였으나, 브라우저는 기본 보안 정책(Sandbox)상 시스템 접근에
한계가 있으므로, 시스템 자원을 확인하거나 인증하는 방법 이외에 ID/Password 방식과
같은 이용자 지식 기반으로 처리해야 한다.
- H/W 시스템 사양 및 드라이버 사양 확인
- 맥 어드레스를 통한 이용자 인증
- 기 설치된 S/W 유무 확인
- 브라우저 버전 확인
- 시스템 및 브라우저 지원 해상도 확인
PC 원격제어의 경우 현재 대부분 고객 콜센터의 원격 PC접근을 통한 상담과 원격 서
버의 관리 및 파일 전송 등에 활용되고 있으며, 최근에는 스마트폰, 태블릿 등을 통한
PC 원격 제어 등에도 활용되고 있다. 현재 PC원격제어의 경우 다양한 기술 활용을 위
해 HOST PC나 서버에는 별도 응용 프로그램을 설치해야하며 이를 위해 대부분 OS 개
발사들이 기본적인 RDP (Remote Desktop Protocol) 규격이나 VNC 지원을 위한 RFB(Re
mote Frame Buffer) 라이브러리를 지원하고 있다.
PC 원격제어 프로그램들은 HOST와 Viewer 사이에 중계서버가 있는 유형과 HOST와 Viewer가
직접 접근하는 두가지 방식으로 개발하고 있으며, RemoteCall, TihinVNC, Chrome Remote
Desktop 등은 중계서버를 통해 전달 받은 스크린 이미지를 HTML5 Canvas를 활용하여
Viewer 기능을 수행하는 방식이 확대되고 있다. 이때 대부분 clientless remote desktop
gateway를 통해 VNC나 RDP 프로토콜을 구현한다. 최근엔 WebRTC의 RTCDataChannel을
이용한 원격 데스크탑 애플리케이션을 개발하는 방안도 일부 개발사에서 시도되고 있다.
- 104 -
<표 2-31> PC 원격제어 솔루션
3. 대체기술
3.1 navigator 객체를 통한 시스템 정보 확인
navigator 객체는 브라우저의 종류와 버전 등 브라우저 전반에 대한 정보를 제공하는 객
체이다. navigator라는 객체 이름은 Netscape Navigator 브라우저에서 온 것이며, IE의 경우
벤더 중립적인 표현으로 clientInformation을 지원하기도 한다. 실제로 IE에서 navigator ===
clientInformation을 실행하면 true를 반환한다. navigator에는 대표적으로 다음과 같은 프
로퍼티가 있다.
제품명 사업자 주요 기능 지원 운영체제 유·무료
RemoteCall 알서포트브라우저를 통해 고객의 단말 접근, 원격 장애 진단 처리
윈도우, 맥OS, 리눅스, Android
유료
TeamViewer TeamViewer원격지원, 서버관리, 파일전송, VPN, 원격인쇄, 오피스 실행
윈도우, 맥OS, 리눅스, iOS,
Android, WP8무료
Real VNC RealVNC Inc원격지원, 시스템 인증, 파일 관리, 채팅,128bit AES 암호화
윈도우, 맥OS 리눅스, HP-UX 솔라리스, AIX
유료
MS Remote Desktop
마이크로소프트
다 채널 화상 통화, 음성통화 및 문자메시지 전송(모바일에
최적화)윈도우 무료 무료
FreeRDP freerdp.com원격지원, 비디오, 오디오
스트리밍, 파일관리, 다채널관리
윈도우, 맥OS, 리눅스, BSD, iOS,
Android,
무료GPL2.0
Guacamole GLYPTODONclientless remote desktop
gatewayVPN, RDP 지원
브라우저 기반 MIT
- 105 -
[예시 : navigator 객체를 통한 시스템 정보 확인]
- navigator.appName : 브라우저의 간단한 이름
- navigator.appVersion : 버전 또는 버전과 관련된 정보. 브라우저 내부적으로
사용되는 버전에 대한 숫자이므로 이용자에게 표시되는 버전 숫자와 항상 일
치하지는 않다.
- navigator.userAgent : 브라우저가 User-Agent HTTP 헤더에 넣어 전송하는 문
자열로 appName과 appVersion의 모든 정보를 포함하며 더 자세한 정보를 추
가로 담고 있다. 이 정보에 대해서는 표준화된 서식이 존재하지 않기 때문에
각 브라우저 특성에 따라 파싱해야 한다.
- navigator.appCodeName : 브라우저의 코드 네임. Netscape에서는 "Mozilla"라는
코드 네임을 사용한다. 호환성을 위해 IE도 역시 같은 코드 네임을 사용한다.
- navigator.platform: 브라우저가 실행되는 하드웨어 플랫폼으로 자바스크립트 1.2
버전부터 지원한다.
- navigator.connection.type : 이용자의 네트워크 연결 상태를 확인한다. (모바일
에서 지원한다.)
navigator 객체의 프로퍼티가 알려주는 정보는 완전히 신뢰할 수 있는 것이 아니다.
예를 들어, Firefox 1.0에서 appName은 "Netscape"로, appVersion은 "5.0"으로 시작한다.
모질라 코드에 기반을 두지 않은 사파리 브라우저에서도 똑같은 값이 반환된다.
<script>
var uaString = window.navigator.userAgent;
if(console && console.log)
console.log(uaString);
else
alert(uaString);
</script>
- 106 -
3.2 각 브라우저별 User Agent 정보
가. Internet Explorer
- Mozilla/5.0 : Mozilla 5.0과“호환 가능”하다.
- MSIE 10.0 : Internet Explorer 10.0이다.
- Trident/5.0 : Trident 레이아웃 엔진 5.0 버전으로 구현됐다.
* 최신 Edge 브라우저의 경우 웹코어 엔진이 변경되어 User Agent 정보가 다수 변경
되었으며 변경 정보는 https://msdn.microsoft.com/en-us/library/hh869301(v=vs.85).aspx
에서 확인할 수 있다.
<표 2-32> 이용자 에이전트 문자열 토큰 설명
<표 2-33> 윈도우 IE Trident 토큰
Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 10.0; Trident/5.0;
IPMS/A640400A-14D460801A1-000000426571; TCO_20110131100426; SLCC2; .NET
CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0;
InfoPath.2; Tablet PC 2.0)
Token Description
Windows NT 10 Edge
Mozilla/5.0 Internet Explorer 11
Windows NT 6.3 Internet Explorer 10
Trident/7.0 Internet Explorer 9
rv:11.0 Internet Explorer 8
Token Description
AppleWebKit/537.36 Edge
Trident/7.0 Internet Explorer 11
Trident/6.0 Internet Explorer 10
Trident/5.0 Internet Explorer 9
Trident/4.0 Internet Explorer 8
- 107 -
나. Chrome
- Mozilla/5.0 : Mozilla 5.0과 호환 가능하다.
- AppleWebKit/version (KHTML, like Gecko) : “Gecko 같은” 브라우저 레이아웃
엔진인 KHTML을 사용한다. Webkit는 KHTML을 기반으로 한 엔진이다.
- Chrome/version : Chrome이며 해당 버전이다.
- Safari/version : Safari의 해당 버전과 비슷하다.
다. Firefox
- Mozilla/5.0 : 모질라 5.0 기반이다.
- platform : 플랫폼 정보
- rv : Gecko 레이아웃 엔진의 배포 버전
- Gecko/yyyymmdd : Gecko의 개발용 배포일로 yyyymmdd 형태이다.
실제 배포일은 아니며, 추후 삭제될 수 있다.
- Firefox/appversion : Firefox의 버전이다.
라. Safari
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.7 (KHTML, like
Gecko) Chrome/7.0.517.44 Safari/534.7
Mozilla/5.0 (Windows; U; Windows NT 6.1; ko; rv:1.9.2.8) Gecko/20100722
Firefox/3.6.8 IPMS/A640400A-14D460801A1-000000426571
Mozilla/5.0 (Windows; U; Windows NT 6.1; ko-KR) AppleWebKit/533.18.1 (KHTML, like
Gecko) Version/5.0.2 Safari/533.18.5
- 108 -
3.3 설치형 앱으로 개발
장치 관리의 경우 브라우저의 기본 보안 정책상 문제가 발생할 소지가 있으며, 개발
사 정책에 따라 플러그인 지원 여부도 유동적이여서 모바일과 같이 PC에서도 OS별로 설
치형 애플리케이션을 개발하여 앱스토어를 통해 배포하는 방식으로 OS 개발사의 Native
API(MFC, Win32, WinFX)와 웹 API(MS WinJS)를 통해 하이브리드 방식으로 개발하여 앱
스토어 검수 통과 후 배포할 수 있다.
이 경우 모바일과 유사하게 오류 발생 후 문제점을 수정하고 배포하는데 있어 실시간
대응이 어렵고, 검수에 따른 추가 시간이 소요된다는 단점이 있다.
3.4 Viewer를 HTML5로 구현
PC원격제어의 경우 시스템 자원 접근과 RDP(RFB) Protocol 지원을 위해 HOST에는 반
드시 응용 프로그램을 설치해야 하며, Viewer(Client)는 중계서버(Proxy)를 거쳐 브라우저
를 통하여 어느 곳에서나 접근하고 제어할 수 있는 방식으로 제공할 수 있다.
HOST 클라이언트와 VNC Server는 RFB(Remote Frame Buffer) Protocol을 지원하는 오픈
소스(TigerVNC, TurboVNC) 등을 활용하여 구축하고, 물리적으로 VNC 서버내에 웹 Protocol
변환을 위한 프록시 서버를 구축하여 브라우저에서 socket.io를 이용하여 WebSocket 기반
으로 타임아웃 설정 시간까지 세션을 지속적으로 유지할 수 있도록 개발한다. 이때 VNC
Server에서 전달받은 스크린 버퍼 프레임을 Canvas에 지속적으로 Draw해서 브라우저에
서 PC화면을 보여주는 방식으로 구현한다.
4. 시스템 정보 확인 시 유의 사항
웹 서비스 개발사에서 시스템 정보에 접근하거나 장치 제어가 필요할 경우 확인할 경
우 반드시 플러그인을 설치해야 하는 문제가 발생한다. 현재 대부분의 운영체제나 브라
우저 개발사는 보안 문제로 더 이상 브라우저의 장치 접근이나 장치 제어를 허용하지
않는 방향으로 정책을 변경하고 있어, 웹 서비스 개발사도 이점을 유의해서 반드시 필
요한 시스템 정보의 경우 고객 동의 후 직접 입력하도록 서비스 정책을 변경할 필요가
있다. 또한 장치 및 시스템에 반드시 접근하거나 제어해야 하는 서비스의 경우 설치파
일 형태의 애플리케이션으로 배포, 관리하는 방식을 우선 고려해야 한다.
Ⅲ.� 멀티�운영체제�및�
브라우저�정책
- 111 -
III. 멀티 운영체제 및 브라우저 정책
1. 멀티 운영체제 지원 정책
운영체제 및 브라우저 개발사는 자사의 전략적 이해관계에 따라 기술 지원 방식을 제
공하고 있다. 운영체제와 브라우저가 결합된 방식으로 제공되고 있는 MS와 애플은 최근
자사 기술 정책과 로드맵에 따라 설치형 응용 프로그램 기술과 웹 기술을 상호 독립적
으로 운영하는 정책을 유지하고 있다. 자사 운영체제 점유율이 낮거나 일부 플랫폼만 제
공하고 있는 구글과 모질라 재단의 경우 높은 브라우저 점유율을 기반으로 윈도우와 맥
운영체제에 설치형 웹 애플리케이션을 구동하거나 브라우저 내에서 3D 게임과 멀티미디
어 지원을 위한 다양한 확장 기술을 지원하고 있으며, 기존 윈도우와 맥 운영체제 설치
응용 프로그램과 브라우저 간 연동을 위한 브라우저 개발사의 확장 기술은 보안 취약점
및 이용자 서비스 선택권을 제약하는 한계로 인해 최근에는 브라우저 개발사의 정책에
따라 안전성이 보장된 웹 표준 기술로 개발하는 방향으로 전환하고 있다.
[그림 3-1] 운영체제 및 브라우저 정책 우선순위
- 112 -
대부분의 웹 서비스(솔루션) 개발사는 시스템 개발사 정책, 시스템 사용자 정책, 브라
우저 사용자 정책을 인지하고, 가이드에 따라 개발 방법과 운영 방법을 관리해야 한다.
Windows, Mac OS X, Linux등 운영체제에 적용할 수 있는 간단한 확장 기술은 현재까
지 Custom URI Scheme(Protocol Handler 레지스터 등록)을 통한 브라우저와 운영체제 설
치 응용 프로그램 간 파라미터 연동 방식이 대표적인 기술이다. (URI Scheme은 IETF RFC
4395 규격 참고) 최근엔 Custom URI Scheme을 통해 브라우저와 운영체제 설치 응용 프
로그램 호출 후 직접 메시지를 교환하지 않고 HTTPS(SSL)을 통한 중계(서비스) 서버 연
동을 통해 메시지를 암호화하고 인증서를 이용해서 메시지를 교환하는 방식을 사용함으
로써 보안 취약점 문제를 일부 해결하고 있다.
<표 3-1> 운영체제 연동 기술 현황
지원 OS브라우저와 응용 프로그램간
통신 방법개발 지원 사이트
공통 IETF RFC 4395 표준 URI 정의
http://www.ietf.org/assignments/uri-schemes/uri-sc
hemes.xml
http://en.wikipedia.org/wiki/URI_scheme
WindowsRegistering an Application
to a URI Scheme
http://msdn.microsoft.com/library/aa767914(VS.85).
aspx#prot_sec
Mac OSXLaunch Services
Programming Guide
https://developer.apple.com/library/mac/documenta
tion/Carbon/Conceptual/LaunchServicesConcepts/L
SCIntro/LSCIntro.html#
AndroidURL Scheme
(Intent Scheme)
http://developer.android.com/training/basics/intents
/filters.html
iOS Custom URL Scheme 연동
https://developer.apple.com/library/ios/documentati
on/iPhone/Conceptual/iPhoneOSProgrammingGuid
e/Inter-AppCommunication/Inter-AppCommunicati
on.html#//apple_ref/doc/uid/TP40007072-CH6-SW2
- 113 -
2. 브라우저 서비스 개발 정책
브라우저 개발사들은 자사 기술 전략에 따라 다양한 확장 기술을 제공하였으나 보안
취약점과 피싱과 같은 문제가 지속적으로 발생하여 최근에는 Sandbox 보안 모델을 준수
하는 브라우저별 확장 기술이나 HTML5 기반의 웹 표준 기술을 권고하고 있다.
<표 3-2> 브라우저 개발자 지원 정책 현황
<표 3-3> 브라우저별 확장 기능 지원 사이트
브라우저 개발 지원 사이트
Microsoft Edge for Windows 10 Developer Guide
https://msdn.microsoft.com/en-us/library/dn997183(v=vs.85).aspx
Chrome Program Policies https://developer.chrome.com/webstore/program_policies
Mozilla AMO Policies
Mozilla Add-on SDK
https://developer.mozilla.org/en-US/Add-ons/AMO/Policyhttps://developer.mozilla.org/en-US/Add-ons/SDK
Safari for Developers https://developer.apple.com/safari/
브라우저 확장 기능 개발 지원 사이트
Microsoft Internet Explorer Extension
https://msdn.microsoft.com/en-us/library/hh772404(v=vs.85).aspx
Chrome Extension https://developer.chrome.com/extensions
Mozilla Add-on SDK https://developer.mozilla.org/en-US/Add-ons/SDK
Safari Extensionhttps://developer.apple.com/library/safari/documentation/Tools/Conceptual/SafariExtensionGuide/Introduction/Introduction.html
Opera Extension https://dev.opera.com/extensions/
- 114 -
2.1 MS Internet Explorer 정책
마이크로소프트는 Windows10부터 표준 웹 기반으로 웹 사이트를 개발할 것을 권장하
고 있으며, 기존 IE에서 사용하는 비표준 기술과 IE 고유 기술을 사용하지 말 것을 권고
하고 있다. 비표준 여부에 대해서는 Edge 개발자 지원사이트의 웹페이지 정적 분석도구
(https://developer.microsoft.com/en-us/microsoft-edge/tools/staticscan/)를 활용하여 문제를
발견할 수 있다.
<표 3-4> IE 고유 기술 및 Edge 대응 기술
마이크로소프트는 2016년 1월12일 이후부터 운영체제 버전에 따라 IE 브라우저 지원
정책 정하여 브라우저 버전에 따라 순차적으로 보안, 비보안 업데이트, 무료/유료 기술
지원, 온라인 기술 콘텐츠 업데이트를 중단 하였다.
기존기술 대응 표준 기술
ActiveXHTML5 기반 기술
*PDF 뷰어/플래쉬는 지원, IE11 Enterprise Mode
Browser Helper Object(BHO) HTML/JavaScript 기반 확장기술(예정)
Document Modes 단일의 문서 모드만 지원
Vector Markup Language(VML) Scalable Vector Graphic(SVG)
VBScript JavaScript
attachEvent/removeEventaddEventListener
removeEventListener
currentStyle getComputedStyle
Conditional Comments Feature detection 활용
IE8 Layout quirks 표준 기반 레이아웃으로 변경
DirextX Filters & Transitions CSS3, SVG
- 115 -
[그림 3-2] 2016년 이후 IE 지원계획
Windows7, 8, 8.1의 IE8, 9, 10의 경우 2016.01.12일 이후 무상 기술 및 보안 업데이트
지원이 중단되었다. Widows7, 10에서 IE11이 IE의 마지막 버전으로 2019년까지 무상 기술
및 보안 업데이트를 지원할 예정이다.
Windows7, 10에서 IE만의 고유 기능(ActiveX, BHOs, 툴바)을 활용해야 할 경우 엔터프
라이즈(기업용) 모드를 통한 하위 호환성 제공하나, 사용자가 도구 메뉴에서 엔터프라이즈
모드를 켜고 사용해야하는 단점이 있어, 장기적이고 근본적인 해결방안은 최신 웹 표준을
준수하는 Edge 브라우저 사용을 권장하고 있다.
윈도우 10 부터는 모든 커널 모드 디바이스 드라이버를 개발하는 애플리케이션이나
서비스의 경우 EV(Extended Validation) 인증서로 서명 필요하며, 백신, 키보드보안, 웹
방화벽, 시스템 드라이브와 커널에 접근하는 경우 EV 인증서 발급 후 드라이버 패키지
서명을 한 후 마이크로소프트의 승인이 완료되어야 배포가 가능하다. 이에 따라 마이크
로소프트의 사전 검증 및 승인 기간을 고려해서 배포 및 관리 계획을 세워야 한다.
Ⅳ.� 멀티�환경�지원�방안�
- 119 -
IV. 멀티 환경 지원 방안
1. 멀티 브라우저 지원 방안
1.1 HTML5
HTML5는 웹 서비스나 크롬 앱, WinJS 기반 웹 애플리케이션을 만들기 위한 HTML 표
준 규격으로 2014.10월 표준이 완료됐다.
HTML5는 기존 비표준 ActiveX, NPAPI 플러그인 기술을 활용한 별도의 플러그인 프로
그램(FlashPlayer, Java)의 설치 없이 브라우저만으로 멀티미디어, 게임, 오피스, 그래픽,
그리드, 차트 등을 구현할 수 있는 기술로 아래 그림과 같이 마크업 이외에도 다양한 스
크립트, API 기술 요소를 포함하고 있다.
[그림 4-1] 웹 애플리케이션 개발을 위한 연관 표준 기술
HTML5 표준만으로 웹 애플리케이션을 개발하는데 한계가 있으며 자바스크립트 기반
의 API나 전문적인 분야의 기능을 제공하는 라이브러리를 활용하여 개발해야 한다.
- 120 -
<표 4-1> HTML5 주요 기능
※ HTML5 표준에 대한 상세 내용은 방송통신표준“HTML5 웹 애플리케이션 개발 지침”, TTA 웹 표준 참조
주요기능 설명관련 W3C
표준명
웹 폼(Web From)
이용자의 입력정보를 받기 위해 사용되는 입력형태에 대한 정의에 사용되는 마크업, 애트리뷰트와 이벤트
HTML5
Canvas웹에서 즉시모드(immediate mode)로 2차원 그래픽을 그리기 위한 API와 <canvas>내 각종 객체를 회전, 변환하고 이미지 생성 등 각종 효과를 주는 기능에 대한 API
Canvas 2D APIHTML Canvas 2D Context
SVG(Scalable Vector Graphic)
XML 기반의 2차원 벡터 그래픽을 표현하기 위한 언어 HTML5
Video/Audio<video>는 비디오 또는 영화를 보여주기 위해 사용되는 미디어 element이며, <audio>는 사운드나 오디오 스트림을 표현하기 위한 미디어 element
HTML5
Geolocation 디바이스의 지리적 위치 정보를 제공하는 API 표준Geolocation
API
오프라인 웹 애플리케이션(Offline Web Application)
인터넷 연결이 지원되지 않는 경우에도 웹 애플리케이션이 정상적으로 수행될 수 있도록 지원하는 기능으로 애플리케이션에 대한 캐시와 데이터에 대한 캐시로 구성
HTML5
로컬저장소(Local Storage)
기존의 쿠키의 기능을 개선하기 위한 목적으로 개발된 기능으로 웹 클라이언트에서 키와 값이 쌍으로 구성된 데이터를 영구적으로 저장하는 기능
Web StorageIndexed
Database API
Service Work
페이지나 사용자 인터랙션이 필요하지 않은 기능들을 위한 기회를 제공하고, 웹 페이지와는 별개로 자바스크립트 내에서 register 등록하고, 브라우저에 의해 백그라운드에서 실행되는 스크립트
Service Worker
File API 클라이언트에 있는 파일 선택 및 데이터 추출 File API
Web RTC 비디오채팅 기능과 P2P 데이터공유 지원 Web RTC
웹 소켓(Web Socket)
웹 애플리케이션이 서버 측의 프로세스와 직접적인 양방향 통신을 위한 API
Web Socket API
웹 워커(Web Worker)
웹 애플리케이션을 위한 쓰레드(Thread) 기능에 대한 APIWeb
Workers
3D 그래픽 라이브러리(WebGL)
WebGL은 웹 기반의 그래픽 라이브러리로 자바스크립트 프로그래밍 언어를 통해서 사용할 수 있으며 호환성이 있는 브라우저에서 인터랙티브 한 3D 그래픽을 사용할 수 있는 API
WebGL
- 121 -
가. HTML5 웹 애플리케이션 API 구현 방법
HTML5 웹 애플리케이션은 개발자가 제공하는 다양한 구현 방법에 따라 웹 문서의 컨
텍스트를 실행한다.
- 스크립트 요소의 처리를 통해 구현한다.
- 인라인‘javascript: URL’의 실행
(예:img 요소의 src 속성이나 CSS style 요소 블록의 @import 규칙)
- addEventListener( )를 이용해서 DOM에 등록, 명시적인 이벤트 핸들러 내용 속성을
사용하거나 IDL 속성 이벤트 핸들러를 사용하여 구현한다.
- 고유의 스크립트 기능을 가진 XBL, SVG 같은 기술로 구현한다.
- W3C Web Application WG은 지속적으로 규격이 업데이트 되고 있으므로, 관련
표준 규격 확인 후 서비스에 구현해야 한다.
1.2 Custom URI Scheme
Custom URI Scheme은 특정 응용 프로그램을 가리키는 고유의 지시어이다. 이 규격은
브라우저에서 다른 응용 애플리케이션을 호출 하거나 반대로 응용 프로그램에서 브라우
저의 특정 페이지를 호출할 수 있다. 다만 URI Scheme을 처리하는 응용 프로그램은 신뢰
할 수 없는 메시지(악의적인 메시지)를 수신 할 수 있기 때문에, 대부분의 URI Scheme
방식으로 호출하는 응용 프로그램들은 이용자 계정 식별이 가능한 OS 기본 탑재 애플리
케이션에서 주로 사용한다.
만약 웹 서비스 개발사가 Custom URI Scheme를 통해 특정 응용 프로그램과 연동하도록
개발할 경우 보안 서버를 경유해서 메시지를 전달하는 방식과 같이 악의적인 데이터에
대응할 수 있는 방법을 고려하여 개발해야 한다.
가. Custom URI Scheme 등록
정의된 URI 체계를 처리 할 수 있는 응용 프로그램을 등록하려면 윈도우의 경우
HKEY_CLASSES_ROOT에 대한 적절한 하위 키와 값과 함께, 새로운 키를 추가해야 하며,
루트 키가 추가되는 URI 체계와 일치해야 한다. 아래는 HKEY_CLASSES_ROOT에게 경고
키를 추가하는 예제이다.
- 122 -
[예시 : HKEY_CLASSES_ROOT에게 경고 키 추가]
나. Custom URI Scheme 호출
시스템 Shell에 등록된 URI Scheme은 아래와 같은 방식으로 호출되어 사용된다.
- 웹 페이지에서 하이퍼링크 클릭 시 URI Scheme이 System에 전달됨
- System에 전달된 Custom URI Scheme을 보고 실행 가능한 응용 프로그램이
있는지 확인
- 해당 URI Scheme을 받을 수 있는 응용 프로그램이 있다면 실행시키고, URL에
포함된 값을 함께 전달한다.
- 응용 프로그램이 실행되면서 URL에 포함된 값을 참고해서 사전에 정의된 특정
기능을 수행한다.
- 별도 호출 후 특정 시간까지 반응하지 않을 경우를 대비해 고객 통보나 설치
유도와 같은 사전 정의된 예외처리를 구현해야 한다.
HKEY_CLASSES_ROOT
alert
(Default) = "URL:Alert Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "alert.exe,1"
shell
open
command
(Default) = "C:\Program Files\Alert\alert.exe" "%1"
- 123 -
[예시 : Custom URI Scheme 예외처리]
다. Custom URI Scheme 활용 시 유의사항
정의된 URI Scheme에 의한 특정 응용 프로그램 호출 및 메시지 전달 시 악의적인 추
가 명령 줄 매개 변수를 전달하기 위해 추가 따옴표 또는 백 슬래시 문자를 사용할 수
있다. 이는 Protocol Handler를 통해 메시지를 위변조하여 시스템에 악성코드나 바이러스
설치를 유도하는 방법으로 사용할 수 있어 외부 데이터에 의해 호출 메시지가 위변조
될 수 있는 상황에서는 가급적 URI Scheme을 사용하지 않는 것이 바람직하다.
또한 URL 파라미터 위변조를 방지하기 위해 보안 서버를 통한 HTTPS(SSL) 통신을 고려
해야 한다.
1.3 브라우저별 확장 기술
브라우저 개발사들은 자사 기술 전략에 따라 다양한 확장 기술을 제공하고 있으나 보안
취약점과 피싱과 같은 문제가 지속적으로 발생하여 최근에는 Sandbox 보안 모델을 준수
하는 검증된 확장 기술이나 HTML5 웹 애플리케이션 기술을 권고하고 있다.
<script>var appstoreUrl = "http://itunes.apple.com/kr/app/id393499958?mt=8"; //url 은 “naversearchapp://search?qmenu=voicerecg&version=1” function onClickApp(url) {
var clickedAt = +new Date; naverAppCheckTimer = setTimeout(function() {
if (+new Date - clickedAt < 2000){ if (window.confirm("네이버앱 최신 버전이 설치되어 있지
않습니다.\n설치페이지로 이동하시겠습니까?")) { location.href = appstoreUrl;
}}, 1500);
}}location.href = url; </script>
- 124 -
<표 4-2> 브라우저별 확장 기술 요약
브라우저별로 아래와 같이 NPAPI를 대체할 수 있는 플러그인 기술 및 확장 기술 사용한다.
- 구글 : 네이티브 클라이언트(NaCl, PNaCl), 설치형 웹앱, 네이티브 메시징 API등의
사용을 권장하고 있다.
- 모질라 : WebGL, Web Sockets, Web RTC, asm.js 등을 활용할 것을 권고하고 있다.
- 애플 : 기존 NPAPI를 사용하지만 보안 충돌을 고려하여 사용을 최소화하고 HTML5나
앱 방식으로 개발할 것을 권장하고 있다.
- 오페라 : 기존 NPAPI를 사용하지만 보안 충돌을 고려하여 사용을 최소화하고
HTML5나 PPAPI로 개발할 것을 권장하고 있다.
- 마이크로소프트 : Edge 버전부터 HTML5표준 사용을 권장하고 있다.
브라우저 플러그인 기반 기술 플러그인 기술 웹앱 기술
인터넷 익스플로러
(MS)
ActiveX(Edge Deprecated)
∙ Silverlight(Deprecated 예정)∙ Java 애플릿 플러그인∙ Flash Player 시스템 플러그인∙ Custom URI Scheme 연동
(ProtocolHandler레지스터 등록)
∙ HTML5∙ WinJS∙ asm.js (WebAssembly)
사파리(애플)
NPAPI(Deprecated)∙ Java 애플릿 플러그인∙ Custom URI Scheme 연동
(ProtocolHandler레지스터 등록)
∙ HTML5∙ asm.js (WebAssembly)
크롬(구글)
PPAPI(Bride)Native Client
Portable NativeClient NPAPI
(45 Ver. Deprecated)
∙ Native Messaging∙ 커스텀 URI Scheme 연동
(ProtocolHandler레지스터등록)∙ Legacy Browser Support(옵션)
∙ HTML5∙ Chrome App(IE Tab)∙ Chrome Web API∙ Chrome JavaScript API∙ asm.js (WebAssembly)
파이어폭스(모질라)
NPAPI(Deprecated)Native Client
∙ Java 애플릿 플러그인∙ Flash Player 시스템 플러그인∙ Custom URI Scheme 연동
(ProtocolHandler레지스터등록)
∙ HTML5∙ Add-on SDK
(Low Level APIs)∙ asm.js (WebAssembly)
오페라 NPAPI∙ Java 애플릿 플러그인∙ Flash Player 시스템 플러그인 ∙ Native Client
HTML5
- 125 -
관련 대체 기술과 관련한 구체적인 내용은 아래 URL을 통해 확인 가능하다.
- Browser Extension : http://en.wikipedia.org/wiki/Browser_extension
- Chrome Web API : https://developer.chrome.com/extensions/api_other
- NPAPI : http://en.wikipedia.org/wiki/NPAPI
- NaCl(Native Client) : https://developer.chrome.com/native-client
- WinJS : http://dev.windows.com/en-us/develop/winjs
- asm.js : http://asmjs.org
NPAPI는 샌드박스를 거치지 않고 동작하여 보안 문제가 발생할 경우 접속 통제 및 사
용 제한 없이 브라우저 강제 종료 및 사용자 시스템에 문제를 발생할 가능성이 있어 크롬,
파이어폭스, 오페라, 사파리에서 사용을 제한하거나 지원을 중단하고 있다.
이에 따라 각 브라우저 개발사 및 웹 서비스 개발사는 NPAPI를 WebGL, Canvas, Web
Socket, Web Worker, Video/Audio, Adaptive Streaming, Web RTC, WebVTT와 같은 웹
표준 기술로 대체하고 있다.
[그림 4-2] 크롬 지원 NPAPI 대체 플러그인 기술
- 126 -
2. 멀티 스크린 지원 방안
반응형 웹은 HTML5, CSS3를 기반으로 다양한 디바이스(PC, 태블릿PC, 스마트폰, 스마트TV 등)
의 특성(해상도, 화면비율)에 따라 유연하게 대응하여 노출되는 하나의 웹 문서 또는 사
이트를 의미하며, 디바이스의 해상도에 따라 레이아웃과 콘텐츠를 가변폭으로 표시하는 방
법을 의미한다.
- CSS3 Media Queries
- Fluid/Hybrid Grid Layout
- Flexible Media Content
- One HTML : 하나의 콘텐츠에 오직 하나의 HTML 소스만 있다. 만약 특정 장치에
최적화된 여러 벌의 HTML이 있으면 반응형으로 분류하지 않는다.
(CSS, JS 파일은 여러 벌 존재할 수 있다.)
- One URL : 하나의 콘텐츠에서 별도의 URL이 있으면 반응형으로 분류하지 않는다.
2.1 도입 배경
- 한 번의 구축으로 다양한 디바이스 대응
예전에는 PC와 모바일용 홈페이지를 각각 구축했으나 이제는 웹에 접속할 수 있는
디바이스가 다양해졌고, 스마트폰만 하더라도 브랜드에 따라 해상도가 천차만별이기
때문에 최적의 웹서비스를 제공하기 위하여 반응형 웹 디자인(RWD)을 이용하여 페이
지를 구현하는 사례가 증가하였다.
- 유지/관리의 효율성
하나의 소스로 구축하여 사용하기 때문에 (OSMU : One Source Multi Use) 콘텐츠 관
리 또한 하나의 소스로 가능하다. PC용, 모바일용 콘텐츠를 따로 생성하거나 수정할
필요가 없기 때문에 관리의 일원화로 매우 편리하며, 웹사이트 방문자 또한 PC에서
보던 내용을 연속해서 모바일 기기로 볼 수 있는 장점이 있다.
- 127 -
- 웹표준, 호환성 유지
반응형 웹은 다양한 브라우저(IE, Chrome, FireFox, Safari 등)의 호환성을 보장하여야
하며, 이를 위해 반드시 웹표준을 준수 하여야 한다.
2.2 반응형 웹 기법
가. ViewPort
ViewPort란 사용자가 볼 수 있는 화면에 웹 페이지의 영역을 지정하는 것을 말하며,
웹페이지를 보는 장치에 따라 각각의 해상도를 지원할 수 있는 기능이다.
특히 스마트폰 기기는 태블릿이나 데스크탑과 달리 독자적인 뷰포트 처리 방식을 가
지고 있는데, 단말기의 스크린 사이즈와 무관하게 웹 문서의 너비와 높이가 ViewPort가
되고 스마트폰 스크린에 웹 문서(ViewPort)를 모두 출력하기 위해 스크린 사이즈보다 큰
문서는 자동으로 줌 아웃 처리를 하게 된다. 다시 말하면 ViewPort를 스크린 크기에 맞
게 강제로 축소하게 됨으로써 데스크탑에 대응하도록 만들어진 문서를 스마트폰으로 열
어 보면 통상 3~4배 이상 줌 아웃 되어 글씨를 알아 볼 수 없는 형태로 작게 표시하게
된다.
이 문제를 해결하려면 HTML 문서 <head> 영역에 모바일 뷰 포트를 재설정하는
<meta>코드를 사용해야 하며, 아래와 같은 방식으로 사용한다.
[예시 : <meta>코드 적용방법]
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta> : 브라우저가 웹페이지의 크기를 설정할 수 있게 지시해주는 태그
width=device-width : 접속장치의 Width에 맞춰 페이지의 Width를 정해줌
initial-scale=1.0 : 브라우저에서 페이지가 처음 로드될 때 배율을 어떻게 할지 설정
- 128 -
<meta>를 설정하지 않으면, PC에서 보는 형태로 아래와 같이 노출되게 된다.
[그림 4-3] <meta>태그 미적용/적용 사례
Viewport를 재설정함으로써 스마트폰에서 웹 문서를 원본 크기로 표시하게 되면 스크
린 사이즈보다 더 큰 너비를 가지고 있는 문서는 가로 스크롤을 유발하게 되는데 웹 문
서와 콘텐츠의 너비를 가변폭으로 설정하고 미디어 쿼리를 이용해서 좁은 스크린 상태
의 레이아웃을 다시 배치하면 된다.
나. Media Query
콘텐츠 내용을 반응형으로 제어: CSS3 미디어 쿼리는 화면 크기에 따라서 각기 다른
CSS를 적용할 수 있는 중단점(혹은 분기점)을 제공한다. 데스크탑 브라우저의 창 크기를
조절해서 View Port의 크기가 달라질 때 마다 아래 그림과 같이 서로 다른 내용과 스타일이
화면에 표시 된다.
- 129 -
[그림 4-4] 기기에 따른 Media Query 적용 화면
- 글꼴 크기를 반응형으로 제어
a. 미디어 쿼리를 이용해서 화면 너비에 비례하도록 <html> 요소의 글꼴 크기를 절대
단위(px)로 지정한다.
b. <body>, <div>, <span> 등등… 반응형으로 글꼴 크기를 제어하고자 하는 요소를
선택하여 글꼴 크기를 상대(rem) 단위로 지정한다.
c. 사용자 환경에 따라 ViewPort의 너비가 달라지면 <html> 요소의 글꼴 절대 크기
도 화면 크기에 비례하여 달라진다.
d. <html> 요소의 글꼴 크기가 달라지면 <body>, <div>, <span> 등등… rem 단위를
적용한 요소의 글꼴 크기도 <html> 요소의 글꼴 크기에 비례하여 함께 달라진
다. 결국 사용자 단말의 화면 크기는 <html> 요소의 글꼴 크기를 결정하고, rem
단위를 사용한 요소들은 <html> 요소로부터 글꼴 크기를 결정하게 되어 화면 크기가
글꼴 크기에 영향을 미치는 원리이다.
- 130 -
- 웹 폰트 사용
미디어 쿼리를 통해 스마트폰 단말 영역으로 추정할 수 있는 해상도를 분기하고
스마트폰 단말에는 적용하지 않는 것이 좋은데 그 이유는 다음과 같다.
a. 한글 글꼴이 포함된 웹 폰트는 용량을 아무리 최적화 하더라도 일반적으로 웹
문서 용량의 30% 이상을 차지하게 된다.
b. 웹 폰트는 느리게 로딩되기 때문에 글꼴이 로딩되기 전까지 화면을 출력하지 않
거나 또는 글꼴이 로딩된 이후 화면을 다시 출력하는 문제가 있다.
따라서 웹 폰트를 사용하고 싶다면 테블릿 또는 데스크탑 화면으로 추정할 수 있는
화면 크기에 한해 제한적으로 적용하는 것이 좋다. 스마트폰 단말은 일반적으로 작은 화
면에 최적화된 시스템 글꼴을 제공하기 때문이다.
한편 웹 폰트 사용을 권장할만한 상황도 있다. 웹 폰트는 글꼴 아웃라인 정보만 담아
낼 수 있는 것은 아니기 때문에 다양한 형태의 그래픽 정보를 표현할 수 있고 벡터 방
식으로 출력하기 때문에 확대 축소를 해도 비트맵처럼 계단 현상이 발생하지 않는다. 또
한 웹 문서 안에서 글꼴처럼 다루기 때문에 하나의 심볼은 크기뿐만 아니라 색상 또한
자유롭게 변경하여 아래 그림과 같이 재사용이 가능하다.
[그림 4-5] 웹 폰트 그래픽
창 크기를 조절하면 이미지의 크기 또한 변경이 되는데 이 때 계단 현상 없이 어떤
크기로도 또렷하게 표시할 수 있다. 웹 문서에 이미지 사용이 많은 경우 이미지 대신 웹
폰트 그래픽을 사용하면 이미지 전송 요청 횟수와 그래픽 파일 용량을 줄여서 웹 문서
로딩 성능을 개선할 수도 있다.
- 131 -
Media Query 사용법은 아래와 같다. (Mobile – 767px 이하 해상도, 반응형 글꼴 제어)
[예시 Mobile 대상 Media Query 적용 소스]
다. 가변폭 미디어 콘텐츠
본문 영역을 가변폭으로 처리했다면 포함하는 콘텐츠 역시 가변폭에 대응해야 한다.
일반적인 문자열은 가변폭을 가진 부모 요소의 너비에 따라서 자동으로 줄바꿈 처리가
되지만 이미지와 비디오 같은 미디어 콘텐츠 요소는 기본적으로 고정폭을 지니고 있기
때문에 아래 그림과 같은 문제점이 발생할 수 있으며, 가변폭을 가진 본문 너비에 대응
할 수 있도록 너비를 다시 설정해 주어야 한다.
[그림 4-6] 고정폭/가변폭 콘텐츠 예시
@media (max-width:767px){ body { background-color: lightblue; font-size: 10px; font-family: Helvetica, Arial, Sans-serif; line-gheight: 1.5; }}
- 132 -
예를 들면 다음과 같은 원칙을 적용할 수 있다.
a. 본문 너비보다 작은 너비의 이미지는 아무런 처리를 하지 않는다.
b. 본문 너비보다 큰 너비의 이미지는 본문 너비를 초과하지 않도록 너비를 100%로
재설정 한다.
c. 비디오는 본문 너비와 동일하도록 무조건 100%로 다시 설정한다.
d. 이미지 또는 비디오의 너비가 재설정 될 때 높이 또한 동일한 비율로 다시
설정한다.
이런 원칙을 적용하면 가변 폭에 완벽하게 대응하는 본문 콘텐츠를 만들 수 있다.
데스크탑 브라우저의 창 크기를 조절하여 본문 콘텐츠(이미지, 비디오)가 가변폭에 대응
하는 것을 확인할 수 있다. 적용한 소스코드는 다음과 같다.
video {
max-width: 100%;
min-width: 100%;
height: auto;
}
img {
max-width: 100%;
height: auto;
}
[예시 가변폭을 적용한 video, img 콘텐츠]
2.3 반응형 웹 Framework
Bootstrap은 Twitter 내부에서 개발하던 라이브러리로 각종 UI Component들을 모아 놓은
Front-End Framework 이다. Bootstrap을 이용하면 간단한 스크립트와 CSS/HTML만으로
깔끔한 형태의 UI/UX를 구성할 수 있다. 디자인에 익숙하지 않은 개발자들이 데모 또는
프로토타입을 만들기에 아주 유용하며, 구현하기 까다로운 여러 Javascript action들도 간
단하게 라이브러리로 제공하고 있어 쉽게 사용할 수 있다는 장점이 있다.
- 133 -
가. Bootstrap의 구성
Bootstrap은 사용방법에 따라 크게 3가지(CSS stylesheet, Reusable component, Javascript
component)로 구분할 수 있다.
- CSS stylesheet
HTML 자체의 기능을 확장하고 강화할 수 있게 해주는 것이 CSS이다. Bootstrap의 UI
요소 중 가장 간단하게 사용할 수 있는 방법으로써 Boostrap의 CSS에 정의된 class들을
tag에 적용하여 사용할 수 있다.
[예시 Bootstrap Button CSS 코드]
[그림 4-7] Bootstrap Button
위 예시와 같이 간단한 버튼을 만들기 위해서는 일일이 마우스 이벤트들을 처리해야
하지만 이미 Bootstrap에 정의된 버튼 CSS를 사용하면 간단하게 버튼을 생성할 수 있다.
[예시 Bootstrap에서 제공하는 css]
Grid system : Grid 형태의 영역구분을 가능하게 해주는 Layout 체계
Typography : 각종 텍스트 서식을 위한 스타일
Code : 코드 또는 키코드 표시를 위한 스타일
Tables : 테이블 스타일
Forms : 폼 스타일
Buttons : 버튼 스타일
Images : 이미지 스타일
Helper classses : 자주 사용하는 기능을 모아 놓은 유틸
Responsive utilities : 반응형 페이지 동작을 위한 유틸
<a class="btn btn-primary" >link with bootstrap</a><a >link without bootstrap</a>
- 134 -
- Reusable component
HTML만으로는 표현할 수 없었던 화면 구성 요소들을 css와 javascript의 조합을 통해
다양하게 제공한다. 버튼 묶음을 예로 들면 HTML에서는 버튼을 단순하게 나열할 수밖에
없었지만 Bootstrap을 통하면 시각적으로나 기능적으로 묶음으로서의 동작을 구현할 수
있다.
Bootstrap 컴포넌트들을 사용할 때는 단순하게 tag안 class 입력만으로 가능하다.
[예시 Bootstrap Button Group 코드]
[그림 4-8] Bootstrap Button Group
<div class="btn-group">
<button type="button" class="btn btn-default">Left</button>
<button type="button" class="btn btn-default">Middle</button>
<button type="button" class="btn btn-default">Right</button>
</div>
- 135 -
[예시 Bootstrap에서 제공되는 Reusable component]
- Javascript component
jQuery를 이용하여 보다 다양한 Bootstrap의 기능들을 사용할 수 있다.
§ 장점으로는 반응형 웹을 지원하며 CSS에 대한 이해도가 낮은 초보자가 이용하기 편리하다.
§ 단점으로는 정형화되어 있는 CSS로 인해 흔한 디자인의 사이트가 양산될 수 있으며,
타 Front-end Framework과 구성은 비슷하나, 퍼포먼스가 나오지 않는다.
Glyphicons : 아이콘 컴포넌트
Dropdowns : 드랍다운 형태를 만들어주는 컨테이너 컴포넌트
Button groups : 버튼 그룹 컴포넌트
Button dropdowns : 버튼 액션에 드랍다운이 추가된 컴포넌트
Input groups : 입력폼 묶음 컴포넌트
Navs : 탭/버튼 형태의 각종 네비게이션 버튼 묵음 컴포넌트
Navbar : 네비게이션 메뉴바 컴포넌트
Breadcrumbs : 페이지 이동 경로 표시 컴포넌트
Pagination : 페이징 컴포넌트
Labels : 레이블/태그 컴포넌트
Badges : 알람등에 사용되는 뱃지 컴포넌트
Jumbotron : 타이틀 화면 구성용 컴포넌트
Page header : 페이지 상단 구성용 컴포넌트
Thumbnails : 썸네일 컴포넌트
Alerts : 알림 표시를 위한 컴포넌트
Progress bars : 프로그레스바 컴포넌트
Media object : 다양한 종류의 자료를 목록형태로 표시하기 위한 컴포넌트
List group : 목록 표 컴포넌트
Panels : 제목틀을 가진 패널 컴포넌트
Responsive embed : embed로 삽입된 객체의 반응형 처리를 위한 컴포넌트
Wells : 인용문구 표시 컴포넌트
- 136 -
나. Foundation
Foundation은 기본적으로는 Bootstrap과 마찬가지로 각종 UI/UX 컴포넌트를 제공하고
있지만 Foundation은 빠른 프로토타이핑을 위한 여러 장치들을 제공하고 있다.
[예시 Components of Foundation]
Foundation 홈페이지에서는 Learn 항목을 따로 내놓고 Foundation을 처음 접하는 개발자와
디자이너를 위한 강좌가 개설되어 있다.
- Foundation 구성요소
a. Structure : 반응형 웹 페이지 구성을 위한 각종 레이아웃 구성을 위한 기능들을 제공
[예시 Foundation에서 제공되는 Structure]
Media Queries : CSS Media Query를 이용한 화면 크기별 CSS 적용법
Visibility : 화면 크기 또는 화면 방향에 따른 표시 여부를 설정
Grid : 화면 크기에 따라 다양한 레이아웃을 적용할 수 있는 영역 설정법
Block Grid : 화면 크기에 따라 콘텐츠 블럭의 배열을 조정할 수 있는 영역 설정법
Interchange Responsive Content : 화면 크기의 변경에 따라 javascript 이벤트가 발생하여
상황에 맞추어 처리가능
HTML Templates : 웹페이지에 자주 사용되는 기본 HTML Template을 제공하여 불필요한
반복 코드 생산을 줄일 수 있다.
Stencils : Foundation 컴포넌트들의 스텐실을 제공함으로써 웹디자이너가 개발자에게
보다 정확한 시안을 제공하여 보다 빠른 프로토타이핑이 가능하다.
Icon packs : 프로토타이핑 시 자주 사용하는 icon을 기본적으로 제공하여 보다 빠른 프로토타이핑이
될 수 있도록 한다.
- 137 -
b. Navigation : 화면 이동 / 선택 등의 기능들을 제공
[예시 Foundation에서 제공되는 Navigation]
c. Media : 콘텐츠 사용되는 미디어를 표시하기 위한 기능들을 제공
[예시 Foundation에서 제공되는 Media]
d. Forms : 사용자 입력 데이터를 처리하기 위한 UI 기능
[예시 Foundation에서 제공되는 Forms]
Offcanvas : 메인 콘텐츠의 좌우에 메뉴를 숨겼다 열 수 있음, 안드로이드의 Drawer와
비슷한 기능
Top Bar : 웹페이지 상단에 다양한 형태의 메뉴를 표시할 수 있는 Navigation 바를
만드는 기능
Icon Bar : Navigation Bar에 Icon을 넣은 메뉴를 만드는 기능
Side Nav : 화면 양 옆에 표시할 수 있는 Navigation 바를 만드는 기능
Magellan Sticky Nav : 스크롤시에 상단에 따라오는 Navigation 바를 만드는 기능
Sub Nav : 간단한 Navigation 메뉴를 만드는 기능
Breadcrumbs : 단계가 있는 메뉴를 따라 이동시에 현재 단계를 나타내는 기능
Pagination : 페이지 구분을 기능을 간편하게 제공하는 컴포넌트
Orbit Slider : 이미지 슬라이더를 만드는 기능, 모바일의 경우 Swipe도 지원
Thumbnails : Thumbnail 이미지를 테두리와 함께 표시하는 기능
Clearing Lightbox : 화면의 크기에 따라 내부 콘텐츠의 표시 위치를 자동으로
변경해주는 기능
Flex Video : 화면의 크기에 따라 Youtube, vimeo 등의 embed 된 Video의 크기를
자동으로 변경해주는 기능
Forms : Form layout을 구성할 수 있는 기능
Switches : checkbox, radiobutton을 switch 형태로 표시하는 기능
Range Sliders : Slider를 구현할 수 있는 기능
Abide Validation : 입력 값의 형태가 유효한지 확인할 수 있는 기능
- 138 -
e. Buttons : 입력 버튼을 다양하게 구현할 수 있는 기능
[예시 Foundation에서 제공되는 Buttons]
f. Typography : 문자를 목적에 맞게 표현하기 위한 기능
[예시 Foundation에서 제공되는 Typography]
g. Callouts & Prompts : 특정 조건, 시점에 대한 알림이나 팝업에 관한 기능
[예시 Foundation에서 제공되는 Callouts & Prompts]
h. Content : 내용을 목적에 맞추어 가독성을 높이는 등 다양하게 표현하는 기능
[예시 Foundation에서 제공되는 Contents]
Buttons : Button을 구현할 수 있는 기능
Button Groups : Button을 묶음으로 구현할 수 있는 기능
Split Buttons : Dropdown Button과 유사하지만 Dropdown 메뉴 표시 영역이 다름
Dropdown Buttons : Dropdown Menu가 포함된 Button을 구현할 수 있는 기능
Type : 각 표시 목적별로 Style이 정의 되어있음
Inline Lists : List를 가로로 표시할 수 있는 기능
Labels : 다양한 형태의 Label을 구현할 수 있는 기능
Keystrokes : 키 입력을 표시할 수 있는 기능
Reveal Modal : Modal을 구현할 수 있는 기능
Alerts : 알림 메세지를 표현하는 기능
Panels : 여러 컴포넌트를 묶어서 표현할 수 있는 기능
Tooltips : 풍선 도움말을 표시하는 기능
Joyride : Step by Step 설명을 동적 화면 이동과 함께 표현할 수 있는 기능
Dropdowns : Dropdown을 구현할 수 있는 기능
Pricing Tables : 가격 테이블을 표현할 수 있는 기능
Progress Bars : 진행 상태 표시바를 구현할 수 있는 기능
Tables : Table 화면을 구성할 수 있는 기능
Accordion : Accordion 화면을 구성할 수 있는 기능
Tabs : Tab 화면을 구성할 수 있는 기능
Equalizer : 다양한 화면 크기에도 동일한 크기의 Panel을 구성해주는 기능
- 139 -
- 장점으로는 반응형 웹을 유연하게 구현할 수 있다.
- 단점으로는 초보자가 사용하기 매우 복잡하다.
다. Javascript Framework
1) Ionic
아이오닉(Ionic)은 하이브리드 앱 중 하나이다. 기본적으로 코르도바(Cordova) 개발 프레임웍
위에서 동작하고 앵귤러(AngularJS) 자바스크립트 프레임웍을 사용한다. 때문에 MVC
뿐만 아니라 MVW 디자인 패턴 구현이 쉽고, 웹에서 사용하는 앵귤러 코드를 그대로 모바일로
가져다 사용할 수 있는 코드 재사용의 이점이 있다. 아이오닉은 각 모바일 페이지 관리를
위해 UI Router라는 앵귤러 써드파티 라이브러리를 추가로 사용한다.
- 개발환경 구성 : 아이오닉은 노드 개발환경을 사용하기 때문에 Node.js를 설치해야 한다.
a. Npm으로 아이오닉과 코르도바(cordova)를 설치한다.
$ sudo npm install -g ionic cordova
아이오닉은 내부적으로 코르도바를 사용한다. 코르도바로 빌드하게되면 네이티브
앱이 만들어지기는 하지만 플랫폼에 어울리는 디자인은 아니다. iOS나 안드로이드
스타일의 컴포넌트 디자인이 아니라는 것이다. 하지만 아이오닉은 각 플랫폼에 맞는
스타일의 컴포넌트를 미리 제공하기 때문에 쉽게 UI를 개발할 수 있다. 또한 ionic
serve 명령어로 편리하게 개발할수 있고 결과물이 코르도바에 비해 뛰어난 성능을
보장한다.
이러한 장점에 더해 앵귤러가 제공하는 MV* 패턴으로 견고한 애플리케이션을
설계할 수 있는 장점이 있다.
b. 프로젝트 생성 : 아래 명령어로 helloWorld 아이오닉 프로젝트를 생성한다.
$ ionic start helloWorld blank
마지막에 blank 옵션 없이 사용하면 기본적으로 tabs 옵션이 따라 붙는다. 이것은
프로젝트 생성 시 템플릿을 설정하는 옵션이다. 푸시 노티피케이션 사용을 위한
ionic.io 계정 생성에 대한 질문을 하지만 n를 입력하고 진행한다. 설치가 완료되면
helloWorld 폴더가 생성되는데 이쪽으로 이동한 뒤 다음 명령어를 실행하면
[ $ ionic serve ] 로컬 서버가 구동되며, 웹브라우저를 통해 아래의 화면이 노출 된다.
웹브라우저를 시뮬레이터로 사용하면서 개발을 진행할 수 있다.
- 140 -
[그림 4-9] Ionic Simulator
코드 수정 : 생성된 폴더를 에디터로 열어보면 아래와 같다.
[그림 4-10] Ionic Folder Tree
- 141 -
www 폴더에 html, js, css 파일들이 있다. index.html을 열고 간단히 타이틀만
"Hello world"로 변경하고 저장하면 바로 ionic serve 명령어가 코드 변화를 감지하고
이를 웹브라우저에 반영한다.
[그림 4-11] 코드변화가 적용된 Ionic Simulator
- 142 -
아이오닉은 멀티플랫폼을 지원하여 다음 명령어를 사용하면
[ $ ionic serve —lab ] 각 플랫폼에서의 결과물을 테스트할 수 있다.
- 장점
§ 하나의 코드로 멀티 플랫폼을 지원한다.
§ 하나의 코드로 모든 디바이스 애플리케이션을 빌드할 수 있다.
§ 각 플랫폼에 최적화된 UI 컴포넌트를 제공한다.
§ Angular.js 의 모든 장점을 그대로 수용한다.
(데이터 바인딩, MVW 디자인 패턴, 테스트, 다양한 서트피티 모듈 등)
- 단점
§ 네이티브 모바일 애플리케이션에 비해 성능 및 일부 기능의 한계가 있다.
2) React
React는 사용자 인터페이스를 만들기 위해 페이스북과 인스타그램에서 개발한 오픈소
스 자바스크립트 라이브러리로써, 사용자 인터페이스(User Interface)에 집중하며, Virtual
DOM을 통해 속도와 편의를 높이고, 단방향 데이터플로우를 지원하여 보일러플레이트
코드를 감소시켜, 많은 사람들이 React를 MVC(Model View Controller)의 V(View)를 고려
하여 선택한다. 즉, React는 지속해서 데이터가 변하는 대규모 애플리케이션의 구축이라는
하나의 문제를 풀기 위해서 만들어졌다.
- React 특징
a. 뷰 레이어
React는 일반적으로 MVC, MV* 패턴에서 뷰 레이어만을 담당하며, 특별히 어떤
형태의 모델이 사용될 것인지에 대한 가정을 하지 않으므로, 아무 라이브러리나
사용해도 무방하며, 작은 앱이라면 굳이 사용하지 않아도 상관없다. 데이터를
서버에서 가져온다거나 (ajax 요청), 데이터들을 조작한다거나 (underscore/lodash)
location에 따라 다른 컴포넌트를 마운트해준다거나 (Backbone.Router, angular-route)
하는 기능은 직접 구현하거나, 상황에 맞는 라이브러리를 사용해야 한다. 페이스북
에서는 Flux 아키텍쳐을 이용하는데, 이를 React와 함께 사용할 수 있는 자바스크립트
리퍼런스 구현이 공개되어 있다.
- 143 -
b. Virtual DOM
Virtual DOM을 사용하면, 실제 DOM에 접근하여 조작하는 대신에, 이를 추상화
시킨 자바스크립트 객체를 구성하여 사용한다. 실제 DOM의 가벼운 사본이라고
생각하면 된다.
React에서 데이터가 변하여 브라우저상의 실제 DOM을 업데이트 할 때에는 다음과
같이 3가지 절차를 따른다.
① 데이터가 업데이트되면, 전체 UI를 Virtual DOM에 리렌더링
② 이전 Virtual DOM에 있던 내용과 현재의 내용을 비교
③ 바뀐 부분만 실제 DOM에 적용
Virtual DOM을 사용한다고 해서, 사용하지 않았을 때와 비해 무조건 빠른 것은
아니다. React 매뉴얼에 따르면, 지속해서 데이터가 변화하는 대규모 애플리케이션을
구축하기 위해 만들어 진 것이며 적절한 곳에 사용해야 React의 최적의 퍼포먼스를
뽑을 수 있다.
React와 Virtual DOM의 특장점은 바로 업데이트 처리에 대한 간결함이다. UI를
업데이트하는 과정에서 생기는 복잡함을 모두 해소해주고, 업데이트에 더욱 쉽게
접근 할 수 있게 해준다.
c. JSX
JSX는 JavaScript의 확장 문법이다. DOM 엘리먼트를 만들 때 JavaScript 형식으
로 작성해야 하는 것을, XML과 비슷한 형태로 작성할 수 있게 해준다. JSX는
템플릿 언어이지만 일반적인 템플릿 언어들과는 다르다. JSX는 EcmaScript로 치
환되는 간단한 치환/확장 언어로서, 지금은 사라진 언어 명세인 E4X에 영향을
받아 만들어졌다. React 컴포넌트와 React.DOM 가상 엘리먼트 생성자들은 트랜
스파일러를 통해 React.createElement함수 콜로 치환된다.
[예시 React.createElement함수 치환]
<div foo={0} bar={'baz'} />
<script>
//치환 후
React.createElement('div', { foo: 0, bar: 'baz' });
</script>
- 144 -
JSX는 Handlebars 나 Jinja2와 같이 자체적인 if-else, 반복문, 조건적 표현 블럭
등의 제어구조를 가지고 있지 않고, EcmaScript 표현식들을 {} 안에 써준다는 정도에
그치기 때문에 일반적인 템플릿 언어라고 보기에는 무리가 있다.
그렇지만 JSX는 EcmaScript로 치환되는 언어일 뿐이므로, 그냥 함수 호출 식으로
써도 무방하며, React에서는 JSX로 쓰기를 권장한다.
d. Component
React는 모두 Component로 구성이 되어있으므로 React 개발을 할 때는 모든 것을
Component로서 생각해야 한다. React는 컴포넌트 라이프사이클 훅을 제공하는데
컴포넌트가 마운트(Owner에서 React.CreateElement 함수 호출로 새 컴포넌트 인스
턴스를 만들거나, React.render로 DOM 컨테이너 위에 Render되는 순간) 되는 순간
과 언마운트되는 시점, 업데이트되는 시점 등등에 불리는 함수들을 컴포넌트 스펙
오브젝트에서 인터페이스를 구현하듯이 작성해 두며, 일종의 이벤트 훅 같은 것이
라고 생각하면 된다. 또한 모든 React 컴포넌트들은 HTML의 인라인 이벤트 핸들
러같은 onClick 등의 prop을 넘김으로서 인터랙션을 표현할 수 있다.
- 장점
§ 클라이언트는 물론, 서버에서도 렌더링 될 수 있음
§ 다른 프레임워크와 사용 가능
§ Component와 Data 패턴의 가독성이 높아 큰 규모의 애플리케이션의 유지보수가 가능
§ JavaScript 객체 형태의 Virtual DOM을 사용
(JavaScript Virtual DOM 처리가 실제 DOM 보다 빠르기 때문에 애플리케이션의
성능을 향상시킴)
- 단점
§ 모든 코드를 재사용할 수 있지는 않음
§ 내부적인 proxy 구현 등으로 인해 제약이 발생하는 경우도 있음
§ 아직은 버전이 낮은 편이고, 계속 개발중이라 API 가 업데이트 될 수도 있음
§ 애플리케이션의 'View' 레이어만 다루므로 이 외의 부분은 다른 기술을 사용해야 함
§ inline-template과 JSX를 사용하는데, 일부 개발자들에게는 적응이 안 될 수 있음
- 145 -
3) Angular.js & UI Bootstrap
AngularJS는 웹 애플리케이션 개발에 필요한 여러 기능을 제공하는 오픈 소스 자
바스크립트 프레임워크다. SPA(Single Page Application) 형태의 웹 애플리케이션 개발에
적합하며, 반응형 웹 디자인을 위해 고안된 프레임워크는 아니다. DOM 제어에 중점을
두지 않고 데이터 변화와 출력에 중점을 두는 특징이 있다. UI Bootstrap과 연동하기 좋다.
그러므로 Angular js의 기능적인 소개보다는 UI Bootstrap과 연동에 초점을 맞추어 서술한다.
UI Bootstrap 중 트위터에서 공개한 트위터 부트스트랩(Twitter Bootstrap)은 웹 프론트엔드
UI 작업 시 가장 인기 있는 라이브러리 중 하나이다. 앵귤러 UI팀에서는 이러한 부트스트랩
라이브러리를 앵귤러 디렉티브로 만들기 위한 UI-Bootstrap 프로젝트(UI Bootstrap)를 진행
하고 있다.
트위터 부트스트랩 컴포넌트 중 자바스크립트 연동이 필요한 컴포넌트를 앵귤러 디렉티브로
모듈화 하였다. UI-Bootstrap을 사용하면 템플릿 코드에서 디렉티브 선언만으로 부트스트랩
컴포넌트를 구현할 수 있다. 이러한 특징은 코드를 간결하게 유지할 뿐만 아니라 선언형
프로그래밍의 특징을 활용하여 로직을 모듈화 할 수 있다는 장점이 있다.
- UI Bootstrap의 구성 : UI Bootstrap은 부트스트랩의 컴포넌트 구성과 유사함
[예시 UI Bootstrap의 구성]
Accordion : 아코디언 디렉티브
Alert : 알럿 메세지 디렉티브
Carousel : 캐러셀(슬라이드) 디렉티브
Callapse : 컬랩스 디렉티브. 엘러맨트 요소를 숨기거나 보일수 있다.
Dropdown : 드랍다운 메뉴 디렉티브
Modal : 모달(팝업창) 디렉티브
Pagination : 페이지네이션 디렉티브
Popover : 팝오버 디렉티브
- 146 -
- UI-Bootstrap에서 별로도 제공하는 컴포넌트 목록이다.
[예시 UI Bootstrap의 Component 목록]
- 사용법
a. 템플릿에서의 선언
Alert을 생성하는 디렉티브를 사용하면 간단하게 아래와 같이 만들 수 있다.
[예시 Alert 생성 예시 코드]
[그림 4-12] Alert 예시
alert 디렉티브를 통해 생성되는 엘리먼트를 살펴보면 type 속성 값에 따라 클래스명이
동적으로 붙게 된다. type="danger”일 경우 .alert-danger 클래스가 붙고 type="warning”
일 경우 .alter-warning 클래스가 붙는 규칙이다. 만약 type="custom”이라고 선
언하면 .alert-custom 클래스가 붙게 될 것이다. 이러한 특징을 활용하여 커스텀
색상의 alert을 만들 수도 있다.
b. 컨트롤러 데이터와 바인딩
앵귤러를 사용하는 장점 중의 하나는 컨트롤러를 통한 템플릿과의 데이터 바인
딩이다. 컨트롤러의 스코프 변수에 alert을 위한 데이터를 정의하고 이것을 템플
릿에서 연결하여 alert을 동적으로 생성/삭제할 수 있다.
컨트롤러 코드를 먼저 살펴보자. 컨트롤러에서는 {type: “”, msg: “”} 객체를
정의하여 alert 데이터 객체 배열을 생성한다.
Buttons : 버튼그룹 디렉티브. 라디오박스, 체크박스 기능을 제공한다.
Datepicker : 데이트 픽커(날짜 선택) 디렉티브
Timepicker : 타임픽커(시간 선택) 디렉티브
Rating : 래이팅 디렉티브. 별점 주는 용도로 활용할 수 있다.
Typeahead : 타입어헤드 디렉티브. 자동완성 필드에 활용할 수 있다.
<alert type="danger">danger alert 입니다</alert>
- 147 -
[예시 컨트롤러 예시 코드]
사용자 입력에 따라 alert을 추가하기 위해 addAlert() 함수를 만들고 스코프 변수에
저장한다.
[예시 addAlert() 예시 코드]
Alert 우측 상단의 x버튼을 클릭하여 해당 alert을 삭제하기 위한 clseAlert() 함수도
만들어 스코프 변수에 저장한다.
[예시 closeAlert() 예시 코드]
angular.module('demo').controller('DemoCtrl', function($scope) {
$scope.alerts = [{
type: 'danger',
msg: 'danger 알람입니다.'
}, {
type: 'success',
msg: 'success 알람입니다.'
}];
});
$scope.addAlert = function(alert) {
// alert 파라매터가 비었을 경우 기본 값을 설정한다.
alert = alert || {
type: 'warning',
msg: 'warning 알람입니다'
};
alert.type = alert.type || 'warning'
alert.msg = alert.msg || 'warning 알람입니다'
// 배열에 alert 객체를 추가한다.
$scope.alerts.push(alert);
$scope.type = $scope.msg = ''
};
$scope.closeAlert = function(index) {
$scope.alerts.splice(index, 1);
};
- 148 -
위와 같이 컨트롤러를 구성한 다음 템플릿에 이 컨트롤러를 연결한다. 앵귤러 컨트롤러를
템플릿과 연결하여 스코프 변수를 사용하기 위해서는 ng-app="모듈명" 디렉티브를
이용하여 앵귤러를 사용을 명시한다.
[예시 앵귤러 사용 명시 코드]
그리고 컨트롤러를 연결을 위해 엘레멘트에 ng-controller="컨트롤러명”디렉티브를
추가한다.
[예시 컨트롤러 디렉티브 예시 코드]
컨트롤러에서 정의한 $scope 변수를 사용하여 alert를 생성한다.
[예시 $scope 변수를 이용한 alert 예시 코드]
컨트롤러 스코프 변수에 저장된 $scope.alerts 배열을 ng-repeat 디렉티브로 순회하면서
alert 엘리먼트를 생성한다. 그리고 close 속성에 closeAlert($index) 함수를 바인딩하여
클릭 시 알람을 제거 하도록 하였다. 여기까지 작성하면 템플릿은 아래와 같이 alert을
생성한다.
[그림 4-13] Custom Alert 예시
<html ng-app="demo">
<div ng-controller="DemoCtrl">
<alert ng-repeat="alert in alerts" type="" close="closeAlert($index)"></alert>
- 149 -
- 장점
§ 유지보수가 쉽고, 개발속도가 빠르다.
§ 간편한 데이터 바인딩을 통해 뷰 업데이트가 쉽다.
§ 코드 패턴이 동일해 개인 간 차이에 따른 결과물의 차이가 적다.
§ 코드량이 감소한다.
§ SPA개발에 최적화 되어있다.
§ 기능적인 분리가 명확해 협업이 쉽다. (MVC디자인 패턴)
- 단점
§ 크로스브라우징의 제약
§ Google 이외의 검색엔진에서 콘텐츠가 웹 크롤링 되지 않는다.
§ 버전 파편화 및 지나친 제약이 따른다.
Ⅴ.� NPAPI� 대체기술�
개요
- 153 -
Ⅴ. NPAPI 대체기술
1. NPAPI 대체기술 개요
브라우저 개발사들은 점진적으로 비표준 플러그인 기술(ActiveX, NPAPI)들을 아래와
같은 사유로 3년전부터 폐지하거나, 대체 방안을 제시하고 있으며, 특히 구글 크롬 브라
우저에서 지원되던 NPAPI의 경우 45버전부터 현재까지 유지하던 수동 설정 기능까지도
지원을 중단하였다.
구글의 NPAPI 지원 중단 사유는 다음과 같다.
- 보안 : 플러그인은 일반적으로 샌드박스를 거치지 않는 Low Level 언어(C, C++)
로 웹 브라우저의 CPU 자원을 남용하는 원인으로 지목되어 왔다.
- 안정성 : 플러그인 일반적으로 Low Level 코드로 시스템에 접근함으로써 웹 사이
트 강제 종료 및 수동 종료를 유도하는 주된 원인이었다.
- 성능 : NPAPI 사용 웹 콘텐츠들은 그래픽 가속화 등 구글의 최적화 기능을 사용할
수 없어 더 많은 전력을 소모하며, 전반적으로 브라우저의 성능을 저하시킨다.
- 호환성 : NPAPI는 전체적인 브라우저와 통합되지 않으며, 현재 급속도로 성장 중인
모바일 웹에서 지원하지 않는다.
- 사용량 : 구글이 NPAPI 지원 중단을 시작하기 전부터 플러그인 사용량은 급속도
로 감소하고 있으며, 지금 가장 자주 쓰이는 플러그인 조차 실행률은 1% 미만이다.
- 개발자 개발 부담 : NPAPI에 대한 지속적인 지원은 크롬 코드 베이스의 복잡성
을 증가시키고, 과도하게 개발 부담을 개발자에게 전가하고 있다.
가. 구글의 웹 사이트 및 개발자 지원 계획
구글은 이전에 발표한“*NPAPI 중단 관련 개발자 안내서”이외에 NPAPI 기능을 대체할
수 있는 최신 웹 기술에 대한 별도 계획은 없다. 특정 개발자 집단을 위한 개발 지원 계
획이나 실행 프로그램을 제공하지도 않는다. 기본적으로 NPAPI 대체 기술과 관련해서는
- 154 -
웹 서비스 개발사가 자사 서비스 정책에 맞는 다른 기술을 적용하는 것을 추천하고 있다.
또한 스택오버플로워(stackoverflow) 같은 개발자 사이트 정보를 참고하는 것을 권하고 있다.
*https://www.chromium.org/developers/npapi-deprecation
나. 구글의 NPAPI 중단 관련 개발 안내서 요약
NPAPI가 차단됨에 따라 기존에 각 운영체제별 NPAPI 플러그인에 의존하던 기능을 실
행할 수 있게 해주는 최신 기술에 관한 일부 개발자의 문의에 따라 일반적인 NPAPI 사
용 사례와 표준 웹 기술 기반 대안 방안을 제공한다.
일반적으로 주요 웹 표준 기반 기술(HMTL, CSS, JS)은 대부분 샌드박스 내부에서 클
라이언트 소프트웨어 개발에 적합하다. 만약 웹 샌드박스 외부의 기능에 대한 접근을
필요로 하는 경우 무수히 많은 *크롬 확장 기능과 **App API가 제한적인 OS 기능에 대
한 접근을 제공한다.
2015년 4월부터 크롬은 NPAPI 지원을 기본설정으로 비활성화 하였으며, 크롬 웹 스토
어에서 NPAPI 플러그인을 필요로 하는 확장 프로그램을 삭제하였다. 사용자 및 기업들에게
임시로 NPAPI를 사용할 수 있는 옵션으로 주소 창에 chrome://flags/#enable-npapi 기입을
통해 NPAPI 플러그인 설정을 변경하여 사용할 수 있는 방법을 제공하였다. 그러나 2015년
9월 이후에는 해당 방법 또한 NPAPI 지원 기능 종료와 함께 사용할 수 없게 되었다.
* https://developer.chrome.com/extensions
** https://developer.chrome.com/extensions/api_index
다. 브라우저 개발사 추천 확장 기술
브라우저별로 아래와 같이 NPAPI를 대체할 수 있는 플러그인 기술 및 확장 기술 사용한다.
- 구글 : 네이티브 클라이언트(NaCl, PNaCl), 설치형 웹앱, 네이티브 메시징 API등
의 사용을 권장하고 있다.
- 모질라 : WebGL, Web Sockets, Web RTC, asm.js 등을 활용 할 것을 권고하고 있다.
- 애플 : 기존 NPAPI를 사용하지만 보안 충돌을 고려하여 사용을 최소화하고 HTML5
나 앱 방식으로 개발할 것을 권장하고 있다.
- 155 -
- 오페라 : 기존 NPAPI를 사용하지만 보안 충돌을 고려하여 사용을 최소화하고
HTML5나 PPAPI로 개발할 것을 권장하고 있다.
- 마이크로소프트 : Edge 버전부터 HTML5표준 사용을 권장하고 있다.
(기존 IE에서는 ActiveX 지원)
<표 5-1> NPAPI 대체 기술
기술별 NPAPI적용 부분
세부기술 표준 대체 기술
비디오 및
오디오
기본 구성
요소
Ÿ HTML5 Media Elements : HTML5 표준은 <audio>, <video> 엘리먼트를 제공하며 대부분의 경우 <canvas>와 함께 사용 (예 : Video FX Chrome Experiment)
Ÿ WebRTC : Peer간 실시간 통신을 위해 설계되었으며 실시간 미디어, 데이터의 라이브 스트리밍 시 사용 가능
Adaptive
Streaming
(DASH)
Ÿ Silverlight의 Smooth Streaming 혹은 QuickTime의 HTTP Live Streaming과 같이 모던 웹에서 각각의 사용자들에게 반응적으로 스트리밍 할 수 있는 기술
Ÿ HTML Media 엘리먼트의 Media Source Extension으로 구현 가능
화상회의Ÿ WebRTC 에서 제공되는 JavaScript API를 이용하여 구현 가능
(예 : Cube Slam Chrome Experiment)
DRM
(Digital Rights
Management)
Ÿ EME(Encrypted Media Extensions) 표준으로 HTML5 video에 DRM 적용 가능하며, 공개 코덱인 WebM을 이용해서 비디오 구성요소의 미디어 확장 기능을 사용 할 수 있음
폐쇄 자막Ÿ WebVTT와 <video> 태그의 하위 엘리먼트인 <track>
구성요소를 이용하여 HTML 앱에서 시간 제한 텍스트 자막 기능을 추가할 수 있음
네이티브
애플리케이션과의
커뮤니케이션
- Ÿ 크롬 앱 및 크롬 확장 Native Messaging API를 사용할 수 있음
게임 및 3D -Ÿ Native Client(NaCl)의 크로스 플랫폼 게임 개발 환경 사용Ÿ WebGL 표준으로 3D 그래픽 가속 기능 사용
보안 - Ÿ TLS 로 전환을 권장하며 추후에는 Web Crypto 표준 사용을 권장
하드웨어 접근 -
Ÿ 웹캠, 마이크 등과 같은 사용자 PC의 외부 장비에 대한 접근을 Media Capture 표준으로 구현 가능
Ÿ USB 하드웨어에 대한 액세스 및 블루투스 장치를 액세스하기 위한 응용 프로그램 API(chrome.usb, chrome.bluetooth) 사용
화면 캡쳐 -Ÿ Desktop Capture 를 이용하여 전체 화면 캡처 가능Ÿ Tabs API의 captureVisibleTabs를 이용하여 개별 탭 캡처 가능
- 156 -
2. NPAPI 국내 사용 현황 및 분류
국내 민간 주요 200대 웹사이트 중 78개 웹사이트에서 241개의 NPAPI를 사용하고 있
으며, 주요 사용 기능은 결제, 보안, 인증, 게임실행, 멀티미디어, 파일 처리, PC제어(바
로가기 설치, 원격 제어), 전자문서(위변조 방지, 시점 확인, 출력)에 사용되고 있다. 분
야별로는 포털이 NPAPI를 가장 많이 사용하고 있으며, 결제, 보안, 인증 기능을 많이 사
용하는 금융 분야가 두 번째로 많이 사용하고 있다.
NPAPI를 사용하는 사이트 대부분이 10개 이하의 NPAPI를 사용하고 있으며, 직접 NPAPI를
개발하기보다는 웹 솔루션에 기능이 포함되어 사용하는 경우가 대부분이다.
<표 5-2> 국내 NPAPI 사용 현황
구분 민간 200대 사이트 NPAPI 사용 수
기능별
NPAPI
결제(전자서명, 전자결제) 123 51.0%
보안(백신, 방화벽, 로그인 보안, 키보드 보안) 56 23.2%
게임(게임 실행) 26 12.8%
인증(본인 확인, 시점 확인) 13 10.8%
멀티미디어(그래픽편집, 동영상, 음원 재생) 9 3.7%
파일 처리
(대용량 다중 파일 처리, 고속 파일 다운, 업로드)8 3.3%
PC제어(시스템 정보 확인, 장치 연동 관리) 6 2.5%
전자문서(문서 보호, 암호화, 출력) - -
기타(채팅 상담) - -
합 계 241(100%)
- 157 -
<표 5-3> 국내 NPAPI 사용 현황 및 분야
<표 5-4> 크롬 플러그인 실행 현황
순위 구분 기능 NPAPI 명 업체명 중복수 비중
1 WP 업데이트 SandBox Plugin think-bowl 41 17%
2결제
전자결제 INISAFE CrossWeb NP Plugin 이니텍 30 12%
3 전자결제 INICIS INIPay Plugin 이니시스 16 6.6%
4 보안플러그인
통합설치Veraport Mozilla Plugin 베라포트 12 4.9%
5결제
전자결제 KCP한국사이버
결제12 4.9%
6 전자결제 LG Uplus XPay Plugin npRuntime) LG U+ 11 4.5%
7
보안
관리
키보드보안 TouchEnKey for Multi-Browser 라온시큐어 10 4.1%
8 백신 AhnLab Online Security 안랩 8 3.3%
9 개인방화벽 nProtect Netizen v5.5 Install. 잉카인터넷 8 3.3%
10 인증인증서 관리,
암호화SoftForum XecureWeb Control Plug-in 소프트포럼 7 2.9%
합계 155 64.3%
구분 2013.09 2014.05 2014.10
Sliverlight 15% 13.3% 11%
Google Talk 8.7% 8.7% 7%
Java 8.9% 7.2% 3.7%
Facebook 6% 4.2% 3.0%
Unity 9.1% 3.1% 1.9%
Google Earth 9.1% 0.1% 0.1%
- 158 -
3. NPAPI 대체 기술
가. Native Messaging
Native Messaging은 크롬 브라우저에서 실행되는 웹과 Native 애플리케이션 사이에
메시지를 전달하여 통신할 수 있는 기능(API)을 제공한다.
Native Messaging으로 통신하기 위한 Native 애플리케이션은 Native 애플리케이션이 실
행되는 OS에 Native Messaging Host로 등록되어 있어야 한다. Native Messaging으로 통신
시 크롬은 각 Native 애플리케이션을 분리된 프로세스로 시작하며 standard input/output
(stdio) 스트림으로 메시지를 교환한다.
나. Native Messaging Host 등록
Native Messaging Host 등록은 통신에 필요한 설정으로 구성된 manifest 파일을 사용
한다. 다음은 manifest 파일을 구성한 예이다.
[예시 : manifest 파일 구성]
manifest 파일 구성 시 사용되는 필드별 설명은 다음 표와 같다.
{
"name": "com.my_company.my_application",
"description": "My Application",
"path":
"C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": [
"chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"
]
}
- 159 -
<표 5-5> manifest 파일 구성 필드
구성된 manifest 파일은 Native 애플리케이션이 동작하고 있는 OS에 따라 저장되는
위치가 틀리며 다음 표에서 확인할 수 있다.
<표 5-6> OS별 manifest 파일 위치
OS 설명
Windows
manifest 파일이 위치한 경로를 레지스트리에 등록해야 한다. 등록할 레지스트리 키 값은 아래 둘 중에 하나가 되어야 한다.HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_applicationHKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application.
OS X
아래의 경로에 manifest 파일이 위치해야 한다./Library/Google/Chrome/NativeMessagingHosts/com.my_company.my_application.json애플리케이션이 특정 이용자만 실행하도록 설치된 경우는 아래의 경로에 manifest 파일이 위치해야 한다.~/Library/Application Support/Google/Chrome/NativeMessagingHosts/ com.my_company.my_application.json
Linux
아래의 경로에 manifest 파일이 위치해야 한다./etc/opt/chrome/native-messaging-hosts/com.my_company.my_application.json애플리케이션이 특정 이용자만 실행하도록 설치된 경우는 아래의 경로에 manifest 파일이 위치해야 한다.~/.config/google-chrome/NativeMessagingHosts/com.my_company.my_application.json
필드 이름 설명
NameNative Messaging Host 이름.runtime.connectNative 과 runtime.sendNativeMessage API에서 전달되는 인자 중 Native Application을 지정할 때 사용한다.
description Native Application에 대한 설명
pathNative Application의 binary 파일에 대한 경로 정보.리눅스, OS X에서는 절대경로로만 지정해야 하며 Windows 경우에는 상대경로도 가능하다
type통신 방법을 지정하는 필드.현재 standard input/output 스트림으로만 통신이 가능하므로 이 필드의 값은 “stdio”만 사용할 수 있다.
allowed_origins Native Application으로 접근할 수 있는 Chrome Extensions 목록을 정의한다.
- 160 -
- Native 애플리케이션 연결 및 메시지 전송
runtime.connectNative로 Native 애플리케이션으로 통신할 수 있다.
다음은 runtime. connectNative의 사용 예이다.
[예시 : 연결 및 메시지 전송 예시]
위의 예와 같이 runtime.connectNative로 연결하고 해당 객체(예에서는 port)로 계속
통신하는 경우 Native 애플리케이션을 실행된 상태로 유지하면서 통신하게 된다.
runtime.connectNative를 사용하지 않고 runtime.sendNativeMessage로 통신하는 경우
실행시마다 Native 애플리케이션을 다시 실행 시킨다.
[예시 : runtime.sendNativeMessage를 통한 메시지 전송 예시]
브라우저에서 실행되는 Native Messaging API를 사용하는데 있어 다음과 같은 제약
사항이 있다.
Native Messaging을 사용하는 경우 크로스 사이트 스크립팅 공격에 노출될 수 있
어, 크로스 사이트 스크립팅 공격에 대하여 안전하도록 처리가 필요하다.
var port = chrome.runtime.connectNative('com.my_company.my_application');
port.onMessage.addListener(function(msg) {
console.log("Received" + msg);
});
port.onDisconnect.addListener(function() { console.log("Disconnected");
});
port.postMessage({ text: "Hello, my_application" });
chrome.runtime.sendNativeMessage('com.my_company.my_application',
{ text: "Hello" },
function(response) {
console.log("Received " + response);
});
chrome.tabs.sendMessage(tab.id, {greeting: "hello"}, function(response) {
// WARNING! Might be evaluating an evil script!
var resp = eval("(" + response.farewell + ")");
});
- 161 -
[예시 : 크로스 사이트 스크립팅 공격을 받을 수 있는 예]
이외 SDK, 개발방법 및 예제 소스, PPAPI 개발은 아래 사이트를 참조할 수 있다.
- https://developer.chrome.com/native-client/c-api
- https://code.google.com/p/naclports/wiki/PortList
- http://www.chromium.org/nativeclient/getting-started/getting-started-background-and-basics
다. Chrome Web API
대다수 확장 기능의 경우 웹 페이지나 웹 애플리케이션에 크롬 자바스크립트 API와
크롬 Web API를 포함하여 개발할 수 있다. 특히 네이티브 코드(C, C++)를 추가하지 않
고, 구글이 만든 추가 기능을 API를 통해 쉽게 활용할 수 있다.
크롬 브라우저에서 확장 할 수 있는 API 샘플은 아래와 같다.
- 표준 자바스크립트 APIs : 일반적인 웹 응용 프로그램에서 사용할 수 있는 (DOM)
API를 동일한 코어 자바 스크립트와 문서 객체 모델
- XMLHttpRequest : 하나 이상의 서버로부터 웹 서비스 데이터를 요청하는 XML
HttpRequest 객체를 사용한다. 확장 기능을 호스팅하는 매니페스트 권한 필드
요청을 보낼 수도 있다.
- HTML5 and other emerging API : 구글 크롬은 새로운 API와 함께 HTML5 기능을
지원한다. 다음은 사용할 수 있는 일부 API로써 아래와 같다.
§ audio, video
§ application cache
§ canvas
§ geolocation
§ local storage
§ notification
§ web database
chrome.tabs.sendMessage(tab.id, {greeting: "hello"}, function(response) {
// WARNING! Might be injecting a malicious script!
document.getElementById("resp").innerHTML = response.farewell;
});
- 162 -
이외 최신 튜토리얼과 정보는 html5rocks.com를 통해 확인할 수 있다.
- WebKit APIs: 구글 크롬은 웹킷 기반으로 구축되어 있기 때문에, 확장을 위해
웹킷 API를 사용할 수 있다. 특히 CSS 확장 기능을 통해 이미지 필터, 애니
메이션, 이미지 변형 등을 쉽게 제공할 수 있다.
- V8 APIs, such as JSON : JSON은 V8에 있기 때문에, JSON 기능을 사용할 수
있는 JSON 라이브러리를 포함할 필요가 없다.
- APIs in bundled libraries : 브라우저 (예를 들어, jQuery)를 제공하지 않는 라이
브러리를 사용하는 경우, 확장 기능과 라이브러리의 JavaScript 파일을 번들 할
수 있다. 번들 된 라이브러리들은 다른 웹 페이지와 마찬가지로 작동한다.
라. asm.js
asm.js는 NativeClient와 유사하게, C/C++로 개발된 소스를 웹에서 실행 가능하도록 단순히
자바스크립트로 변환해 주는 기술은 지속적으로 개발되어 왔다.
asm.js 코드는 (LLVM 기준) Emscripten 등의 소스 컴파일러에 의해 번역되고 수동 메모리
관리와 정적으로 입력 된 언어로 작성되는 자바스크립트의 엄격한 서브 세트로 구성되어있다.
최근보다 빠른 웹과 asm.js의 부족한 기능을 해결하기 위해 모질라, 구글, MS, 애플이
새로운 바이너리 표준(low-level programming language)인 WebAssembly를 개발하고 있
다. 이러한 WebAssembly는 웹 브라우저에 가상현실, 암호화 기술, 동영상, 3D 게임 등에
활용될 것으로 기대하고 있다.
asm.js를 이용하여 웹 서비스를 확장 할 수 있는 방법은 아래와 같다.
- asm.js의 경우는 현재 대부분의 최신 브라우저에서 지원되고 있기 때문에 Emscripten
이나 Mandreel 등의 컴파일러를 이용하여 기존의 C/C++로 개발된 코드를 자
바스크립트로 변환하고, asm.js를 아래와 같이 선언하여 실행한다.
- asm.js 소스 코드는 아래와 같으며, unreal engine에서 활용되어 초당 40 프레임의
퍼포먼스를 보여 주었다. 최근의 브라우저에서는 60 프레임까지 성능이 향상되는
것으로 나타나 상용화하기에 충분히 가능한 성능을 보여주고 있다.
- 163 -
[예시 : asm.js 소스 코드 예]
만약 기존의 게임이 C/C++이 아니라 Java 등의 다른 언어로 개발되어 있다면 XMLVM
등의 툴을 이용하여 자바 코드를 C++로 변환한 이후에 다시 Emscripten 등의 컴파일러를
활용하여 자바스크립트로 변환하면 된다.
[그림 5-1] asm.js 처리 플로우
function DiagModule(stdlib, foreign, heap) {
"use asm";
var sqrt = stdlib.Math.sqrt;
function square(x) {
x = +x;
return +(x*x);
}
function diag(x, y) {
x = +x;
y = +y;
return +sqrt(square(x) + square(y));
}
return { diag: diag };
}
- 164 -
asm.js는 자바스크립트 이지만 일반적으로 사용하는 자바스크립트와 아래와 같은 차이
가 있다.
- asm.js는 숫자타입만 다루고 다른 타입은 다룰 수 없다.
- 모든 외부 데이터는 유일한 힙 객체에 typed array 힙 객체에 모두 저장된다.
- 변수에 접근하거나 설정할 때는 특정타입으로 일관성 있게 강제한다
- 컴파일이 필요한 asm.js에는 "use asm” 디렉티브를 사용해서 명시적으로 컴파
일 대상을 지정한다.
-“use asm”디렉티브를 만나서 asm.js 코드를 처리할 때 엄격한 유효성검사를
통과하지 못하면 이는 무시한다. (오류는 아니고 콘솔에 경고를 출력한다.)
asm.js 및 WebAssembly를 활용하기 위한 관련 정보는 아래의 링크를 참조하면 된다.
- asm.js 관련 정보 : http://asmjs.org
- Low Level JavaScript : http://mbebenita.github.io/LLJS/
- XMLVM 관련 정보 : http://xmlvm.org/overview
- WebAssembly 정보 : https://www.w3.org/community/webassembly/
마. Chrome for Work(인트라넷)
Chrome for Work는 기관/단체의 요구사항을 충족시키는 100개 이상의 정책을 제공한
다. 직원들이 받는 애플리케이션 및 확장 프로그램을 설정하고 다양한 플러그인을 관리
할 수 있을 뿐 아니라, 맞춤 및 선별된 앱을 갖춘 사설 웹 스토어를 배포하고 이전 앱
의 호환성을 관리하는 등의 작업을 수행할 수 있다. 또한 자사 보안 정책에 맞춰 최신
보안 수정사항을 자동 업데이트 할 수 있으며, 제어 범위를 확대하려면 수동 업데이트
를 선택할 수 있다.
이를 통해 최신 웹 기술이 적용된 브라우저를 쓰면서도 회사 정책 및 환경에 맞는 맞춤
기능을 제공할 수 있다.
Chrome for Work : http://www.google.com/intl/ko/chrome/business/browser/
- 165 -
바. Legacy Browser Support(기존 브라우저 지원)
Legacy Browser Support(이하 LBS)는 Chrome for Work를 이용하는 조직에서 Chrome
브라우저를 활용하려고 하지만 사용자가 Internet Explorer가 필요한 기존 웹사이트와
앱에 계속 액세스해야 하는 경우 이 기능을 사용하여 브라우저 간에 쉽게 전환할 수 있
다. Chrome 기존 브라우저 지원 확장 프로그램을 사용하면 사용자가 Chrome과 다른 브
라우저 간에 자동으로 전환할 수 있다. 사용자가 ActiveX가 필요한 사이트 등 기존 브
라우저로 열어야 하는 링크를 클릭하면 URL이 자동으로 Chrome에서 기존 브라우저로
이동하여 열린다. 또한 네이티브 호스트 부가기능 실행파일을 설치하면 LBS에서 사용자
가 Chrome에서 기존 소프트웨어에 의존하지 않는 링크를 클릭하면 IE에서 링크가 열린
다. 이 네이티브 호스트 부가기능을 설치하면 Chrome과 IE는 액세스하는 앱이나 웹사이
트에 따라 최적의 브라우저로 전환한다. LBS는 Internet Explorer 6, 7, 8, 9, 10, 11과 호
환되며, LBS가 작동하려면 Windows의 향상된 보호 모드를 사용 중지해야 한다.
LBS 소개: https://support.google.com/chrome/a/answer/3019558?hl=ko
- 166 -
4. 주요 기능별 대체 기술 적용 방안
기존 NPAPI를 대체하기 위해서는 브라우저별로 지원하는 플러그인 기술과 웹 표준
기술을 확인하고 적용 가능성과 호환성, 유지보수성, 향후 지원 중단 가능성을 확인하고
대체 기술을 적용해야 한다. 또한 국내 법제도와 기술 가이드에 대한 인지를 통해, 실제
현장 적용 가능 여부에 대한 판단이 필요하다.
<표 5-7> 국내 기능별 대체 기술
기능 플러그인 기술 웹 표준 기술
전자결제 ∙ Custom URI Scheme 연동 (Protocol Handler 레지스터 등록)∙ Portable Native Client(PNaCl), NaCl ∙ PPAPI∙ Native Messaging∙ Chrome Apps∙ asm.js(WebAssembly)∙ Chrome for Work(Enterprise)∙ Legacy Browser Support (기존 브라우저 지원)∙ Chrome App IE Tab 호환성 지원
∙ HTML5, WebApplication∙ asm.js(WebAssembly)∙ Chrome Web API∙ Service Workers (Background Script)∙ File API∙ System Application API
보안
인증
멀티미디어∙ Portable Native Client(PNaCl)∙ PPAPI∙ EME (Encrypted Media Extensions) API
∙ HTML5, WebApplication∙ Chrome Web API∙ asm.js(WebAssembly)
파일처리∙ Portable Native Client(PNaCl), NaCl ∙ PPAPI∙ Native Messaging
∙ HTML5(File API)∙ asm.js(WebAssembly)
전자문서
∙ Portable Native Client(PNaCl), NaCl ∙ PPAPI∙ Custom URI Scheme 연동 (Protocol Handler 레지스터 등록)∙ Google Cloud Print, Cloud Documents DRM, WaterMark
∙ PDF.js∙ jsPDF∙ Web Open Document Format
게임 런처∙ Portable Native Client(PNaCl), NaCl ∙ PPAPI
∙ asm.js(WebAssembly)
- 167 -
가. 전자결제
전자결제 플러그인은 기술적으로는 웹표준 방식으로 쉽게 전환이 가능하지만 결제 서비스
를 이용하는 머천트의 동의나 새로운 연동에 소요되는 인력 및 시간 등의 요인이 장애 요소
가 되고 있다. 또한 다양한 기능들이 플러그인내에 결합되어 복잡성이 증가된 것 역시 문제
해결의 장애 요인이 되고 있다. 아래와 같은 대안을 하나 이상 사용하는 것을 권장한다.
<표 5-8> 전자결제 대체 기술
나. 키보드보안
키보드 보안은 이용자의 키 입력정보의 제3자 누출을 방지하기 위해 사용되며 OS 수
준에서 키 입력정보를 암호화하는 기술을 사용하기 위해서 ActiveX나 NPAPI와 같은 플
러그인이 선택되고 있다. 데이터 유출을 방지하기 위해서는 대안들 중 하나이상을 조합
하여 사용할 것을 권장한다.
<표 5-9> 키보드 보안 대체 기술
대체 기술 설명
HTML5 기반의 웹표준 결제 UI 구현
HTML5 등 웹표준 기술을 사용하여 전자결제 UI를 구현한다.CSS를 통해 가상키보드나 숫자키패드를 구현할 수 있다.
결제창의 기능별 분리전자결제의 다양한 기능들 (결제수단 등)을 논리적으로 분리하여 기능별로 플러그인 의존성을 해제해나가는 방식 권장한다.
충분한 리소스 투입충분한 리소스(인력, 비용, 시간 등)를 투입하여 전자결제 서비스를 이용하는 머천트 설득 및 결제연동 방식을 웹표준 방식으로 전환할 수 있는 기술을 개발한다.
대체 기술 설명
Browser Sandbox 활용브라우저 Sandbox내에서 구현되며 이용자의 직접적인 키 입력을 방지하기 위해서 마우스로 키 입력을 유도하는 On-Screen Keyboard, 키보드 커서키 사용을 활용한 Combo box 등이 대안이 될 수 있다.
간편결제
최초 인증에서 민감한 개인정보 유출의 위험이 있을 수 있지만 최초 결제 이후의 결제과정에서 민감한 개인정보 입력을 최소화할 수 있는 간편 결제 형태를 활성화하여 키보드 보안에 대응가능하며, 간편 결제 비밀번호 입력의 오용에 대해서는 FDS등 서버쪽의 기술을 사용하거나 고객 손해배상 보장 등 비 기술적인 요소를 사용할 수 있다.
다른 채널을 통한정보 입력
현재 접속한 채널이 아닌 다른 채널을 통한 정보입력을 유도하여 키보드 입력정보 보호를 달성할 수 있다.
- 168 -
다. 개인방화벽
개인방화벽은 이용자의 주도적인 선택에 의해서 활성화하거나 별도의 프로그램으로 설치
를 안내해야 하며, 서비스 운영업자가 개인방화벽의 활성화를 강제하는 접근은 지양한다.
라. 공인인증서
공인인증서를 전자금융거래에 사용해야 하는 법률적 의무가 없어지면서, 공인인증서
의 주요 2대 기능인 이용자 인증 및 거래사실 부인 방지에 대해서는 각각을 구분하여
해결방법을 모색하고 있다. 이용자 인증은 생체인증, OTP인증, 신분증 인증, 간접 인증,
간접 대면 인증 등 다양한 대안을 조합하여 인증하는 방법을 모색하고 있다.
<표 5-10> 공인인증서 대체 기술
기능 세부 기능 설명
생체인증
지문인식인증 등록된 이용자의 지문 일치 여부로 인증
화자인증음성인식과 구분되며 말하는 사람이 예전 등록된 화자와 일치하는지 여부 확인
서명인증 이용자의 서명 특성에 기반하여 인증
기타 홍체 인식, 심박 특성 인증 등
신분증 인증 여권 주민증, 면허증 등 신분증을 업로드하여 인증.
OTP 인증일회용 비밀 번호(One Time Password)를 통해 인증(S/KEY방식, 시간 동기화 방식, 챌린지 응답방식, 이벤트 동기화 방식)
AML KYC체크리스트에 의한 인증, 다양한 체크 Factor로 거래 상대방의 신뢰성, 진위 여부를 인증
간접 인증
정보 소유자가 해당 정보를 확인해낼 수 있는지 여부로 인증이메일 인증, 문자인증, AS인증, CallerID인증 등의 비 금융정보 기반 인증과 신용카드 금액인증, 계좌 1원 이체 후 소유주 확인증 금융정보 기반 인증으로 구분 가능.
평판이력 인증의 보조수단으로 사용. SNS평판, 검색 평판 조회
간접 대면 인증우편 수신 여부로 인증. 다른 신분증의 특성정보 이용한 인증. (신분증을 갖고 있는 사람만이 제시 가능한 정보 요구)
카드 인증 3D Secure, CVC, ARS등 신용카드 정보에 기반한 인증
- 169 -
거래사실 부인방지는 이용자에 대한 신뢰를 바탕으로 이용자가 본질적으로 거래한 사
실이 없다면 이용자의 손해를 보전하는 방향으로 발전해야 하며 거래사실이 있지만 이용
자가 부인하는 경우 정황 증거(접속 로그 등)나 기존 거래 내역 정보를 활용하여 이용자
의 사실 여부를 확인 할 수 있도록 사용 로그를 수집 관리해야 한다. 또한 Fraud Detection
System을 통해 사용자별 거래 유형을 분석하고 이상 거래를 모니터링 해서 사고를 조치
할 수 있는 모니터링 시스템을 구축하는 것이 바람직하다.
마. 멀티미디어
비디오/오디오와 같은 멀티미디어 사용은 HTML5 표준이 나오기 전에는 ActiveX,
NPAPI와 같은 플러그인 기술을 사용할 수밖에 없는 대표적인 분야였다. 그러나 HTML5
표준에서 멀티미디어 지원을 위한 비디오/오디오 재생 요소와 API, 자막을 위한 요소,
카메라/마이크 제어 API, 오디오에 에코와 같은 음향효과를 주는데 사용할 수 있는 웹
오디오(Web Audio), 멀티미디어 데이터의 스트리밍을 위한 데이터 제어를 위한 미디어
소스 확장(Media Source Extensions), 멀티미디어 데이터 DRM(Digital Rights Management)
를 위한 EME(Encrypted Media Extensions)과 같은 다양한 기능이 추가되어 비 표준 플러그
인을 사용하지 않고도 아래와 같은 웹 API를 통해 대부분의 멀티미디어 기능을 제공할
수 있게 되었다.
- HTML5 멀티미디어 요소: <video> 요소, <audio> 요소
- WebRTC(Web Real Time Communication), Media Streaming API, Media Capture API :
영상 커뮤니케이션과 녹취를 위한 기능
- 웹 오디오(Web Audio) : 오디오를 생성, 처리하는데 사용하는 자바스크립트 API
- MSE(Media Source Extensions) : HTML5 Video에서 멀티미디어 데이터 프리패칭
(prefetching)과 버퍼링(buffering) 등과 같은 스트림 제어
- EME(Encrypted Media Extensions) : HTML5 Video와 Audio 요소를 확장하여 플러그인을
사용하지 않고도 DRM(디지털 권한 관리) 보호된 콘텐츠를 사용할 수 있는 기
능으로 인터넷 강좌와 같은 멀티미디어 콘텐츠의 보호가 필요한 서비스를 위
해서 사용될 수 있다.
- 170 -
바. 전자문서
전자문서의 경우 빠른 리포팅과 그리드 처리, 위변조, 복제 방지를 위한 DRM과 워터마킹,
화면캡쳐방지, 원본진본 확인을 위한 전자서명 및 시점 인증 확인, 전자문서 출력 등을
위해 비표준 기술을 클라이언트에 배포, 처리했던 방식에서 클라우드 기반 서버 시스템을
통해 관련 기능을 제공하고, 화면 캡쳐와 같은 키보드 인식 및 이벤트 인식의 경우 실행
파일과 Custom URI Scheme 연동이나 Native Messaging을 통해 기 설치된 실행 파일과
연동을 통해 서비스를 제공할 수 있다.
전자문서 출력의 경우 클라우드 프린터를 활용하여 서비스를 제공할 수 있으나, 프린터가
클라우드 프린터 지원 여부 확인이 필요하며, 인쇄 영역을 지정할 경우 CSS로 인쇄 영역을
지정할 수 있다.
사. 게임런처
게임런처와 같은 서비스를 제공하고자 한다면, asm.js이나 PNaCl(NaCl)을 활용하여 게임
자체의 소스를 웹 기반으로 변환하거나 게임의 기획단계에서부터 HTML5 기반의 웹 표
준 게임 제작의 비율을 늘려나가도록 하는 등의 대책이 필요하다.
- 171 -
5. NPAPI 전환 적용 사례
가. Adobe PPAPI
어도비의 FlashPlayer는 ver 14부터 PPAPI에 대한 콘텐츠 디버거를 지원 했으며, ver 16
부터 원도우와 맥 운영체제에서 공식적으로 다운로드를 지원하고 있다.
기존 Flash Player는 Flash runtimes과 Adobe Flash Player browser plug-in으로 구성되
어 있으며 AIR는 Flash runtimes core위에 개발자가 독립적으로 콘텐츠를 배포 실행할
수 있도록 지원하는 런타임으로 구성되어 있다.
FlashPlayer는 다음과 같은 기능들로 구성되어 있으며, 공식적으로 PPAPI 적용 사항은
아래와 같다.
- Animation
- Vector-based graphics
- Audio (including MP3) (PPAPI)
- Multicast Video(PPAPI)
- Hardware video decoding(PPAPI)
- Microphone and webcam access
- Low-level bitmap manipulation(PPAPI)
- Binary-based sockets
- Strongly typed, class-based programming language
- Hardware-accelerated 2D and 3D content(PPAPI)
현재 기능 중 PPAPI를 사용하지 않는 기능들은 브라우저가 지원하는 HTML5, WebApplication
API, SVG, CSS, Web Animation을 통해 구현할 수 있다.
- 172 -
6. 비표준 대체 기술, 실행파일 보안 이슈
현재 Active와 NPAPI 비표준 대체 기술로 사용하고 있는 EXE 파일 방식의 경우 URI
프로토콜 핸드러, 브라우저별 익스텐션, 로컬웹서버 루프백 방식, Dll injection을 통한
메모리 이벤트 모니터링 방식을 사용하고 있으나 아래와 같이 배포, 실행, 운영(업데이
트) 중 문제점이 있어, 향후 별도 설치가 필요없는 Agentless 방식으로 전환하는 것을
고려해야 한다.
<표 5-11> 대체 기술 구분
구분설치/실행파일 있음 설치파일
없음
ActiveX Non ActiveX
기술명칭 플러그인 Non 플러그인 Agentless
기술구현방식 ActiveX NPAPIURI
프로토콜핸들러
Pure Web 브라우저별 익스텐션
로컬웹서버
Dll injection 웹표준
개요 및 특징 MS전용
비 MS 계열,
ActiveX와 기술적 유사성
표준규격Non
플러그인 대안으로
등장했으나 구동시간 지연 및 관리
이슈로 사용
하락세
자바스크립트로
구현하였으나
보안취약성으로 사용 하락세
각 브라우저
확장 규격으로
지원
Non 플러그인 방식의
시장수용도가 높은 대안
방식으로 등장했으나
보안 취약점 존재
Non 플러그인 방식의
시장수용도가 높은 대안
방식으로 등장했으나 운영체제 개발사의 기술방식
퇴출 가능성 있음
EXE 방식에 비해
보안성 및 가용성은 부적하나 향후 기술 발전가능성과 시장 수용성이
높음
파일포맷 CAB,MSI 등 파일 포맷
EXE 파일포맷별도 설치 파일 없음
지원 OS 윈도우 계열 멀티 OS 멀티 OS 멀티 OS 윈도우계열 윈도우계열 윈도우계열 멀티 OS
지원브라우저
IE(Edge는 지원안함)
Chrome, Firefox
지원 안함
멀티브라우저
멀티브라우저
개별 브라우저
멀티브라우저
멀티브라우저
멀티브라우저
사업자선호도 시장퇴출 시장퇴출
응답속도 지원으로
퇴출가능성 높음
보안성 취약으로
퇴출가능성 높음
전용스토어 사용
거부감, 개발비 증가로 사용
가능성 낮음
사용자 PC점유리소스 증대 및 향후
보안 문제 발생
가능성 있음
사용자 PC점유리소스 증대 및 향후 보안 문제 발생 가능성 있음
보안 취약점 보완을 위한
2factor 인증 및 FDS와 같은
보완재 필요
소비자선호도 낮음 낮음 낮음 낮음 낮음 낮음 낮음 높음
- 173 -
EXE 파일 방식의 보안 및 운영상 문제점은 배포, 실행, 운영 단계별로 세분화하고,
그에 대한 대응 방안을 고려해야 한다.
또한 EXE 파일 특성상 바이러스가 포함된 악성파일로 둔갑하기 쉬워 불법 유통의 위
험과 배포 신뢰성을 보장할 수 있는 방안을 강구해야 한다.
<표 5-12> EXE 보안 취약점
단계 보안 상 문제점
배포
로컬 웹 서버의 경우는 브라우저와 XHR이나 WebSocket으로 통신할 경우는 필요지만, Pipe로 직접 통신할 경우 브라우저 Extension을 사용하여 브라우저 쪽에서 EXE로부터 정보를 받아가며 이에 따라 실제로는 EXE만 배포하는 것이 아니 브라우저 Extension을 따라서 브라우저 마켓에서 따로 사용자가 설치를 해야 하는 문제가 있다.(이 경우 pNaCl을 사용할 수 있으나, 실행과 업데이트에 문제가 발생할 수 있다.)
실행
로컬 웹 서버 방식을 사용하는 경우는 자체 인증서 키쌍을 보유하고 있으며 브라우저 경고를 발생시키지 않기 위해서 상용인증서를 사용하거나 PC마다 다른 인증서를 생성해서 보유하고 있다.보안상 문제는 이 인증서들이 유출되어서 피싱이나 파밍을 유도할 수가 있으며, 상용인 경우에는 위법적 사용이어서 신고 등으로 판매자가 인지하는 경우 해당 인증서가 폐기될 경우 관련 서비스가 모두 중지하게 된다.또한 실행 중 보안 무결성을 보장할 방법이 없어 Pipe를 사용하는 경우는 중간에 정보를 쉽게 가로챌 수가 있다.(배포 후 해킹된 실행파일을 구분할 수 있는 제3자 검증 방법이 없음)
운영(업데이트)
항상 실행하고 있을 경우에는 버전 확인 및 자동 업데이트 기능을 구현하면 되나, URL Scheme 방식인 경우는 사용자 거부감으로 업데이트가 쉽지 않다.(모바일 애플리케이션처럼 사용자 인지 후 사용자가 선택해서 업데이트 시행해야 함)결국 실행할 때마다 업데이트를 점검해야 하는데 긴급 업데이트는 시간이 느리기 때문에 어려움이 있으므로 점검 페이지에서 먼저 모듈을 실행하여 버전을 점검한 후에 모듈 스스로 업데이트 점검을 하도록 기능을 개발하고, 업데이트 후 자체 검증을 수행해야 한다. 이러한 방식은 향후 운영체제 개발사의 정책 이 변경되거나 업데이트가 차단 될 경우 사용이 불가능할 수 있다.
Ⅵ.� HTML5
- 177 -
Ⅵ. HTML5
1. 개요
웹 브라우징을 위한 다양한 브라우저가 존재 하지만 글로벌 브라우저 점유율과는 다르
게 국내에는 인터넷 익스플로러 점유율이 높은 편이다. 국내 점유율이 높은 인터넷 익스
플로러의 경우 9 이전 버전의 경우 HTML5 표준을 지원하지 않고 있어 HTML5 표준으로
구성된 웹 페이지를 제대로 볼 수 없는 문제점이 있다.
아래는 StatCounter에서 확인한 2016년 5월 ~ 2016년 10월 사이에 국내 사용자가 데스
크탑에서 사용하는 브라우저 점유율이다.
[그림 6-1] 브라우저 점유율 (2016년 5월 ~ 2016년 10월)
문제가 되고 있는 부분은 IE8.0으로 1.97%로 나타난 부분이다. 국내에서 사용 중인 1.
97%의 브라우저만이 HTML5 표준으로 구성된 웹 페이지를 제대로 표시할 수 없는 상태이
다. 향후 국내 홈페이지가 HTML5 표준을 준수하여 작성되어야 할 것으로 보여진다.
- 178 -
2. HTML5 신규 기능별 보안 이슈
2.1 HTML5 신규 요소
HTML5 표준을 기반으로 웹 애플리케이션 개발 시 기존 HTML4.01 기반의 웹 애플리
케이션 보안 대응 방안 이외에도 HTML5 신규 명세에 따른 다양한 구성 요소의 DOM
조합이나 CORS(cross-origin resource sharing), Web Storage, WebSocket, Web Worker와
같은 새로운 기술 도입에 따른 보안 문제에 대한 대응 방안을 같이 고려해야 한다.
<표 6-1> HTML5 신규 기능 요약
단계 보안 상 문제점
신규 요소audio, video, source, canvas, embed와 같은 신규 태그와 각 태그에 대한
세부 기능에 대한 XSS 필터를 우회하는 조합이 가능하다.
CORS(Cross Origin
Resource Sharing)
CORS 는 브라우저가 XHR 을 이용하여 Cross-Origin 요청을 가능하게
한다. 해당 기술은 서로 다른 도메인(사이트)간 자원을 공유할 수 있게
해주며, 특정 조건들이 만족될 경우 동일출처정책 (SOP : Same Origin
Policy)에 의한 제한을 완화하는데 사용될 수 있으며, 다른 도메인의
리소스를 호출하여 서버 부하를 일으키거나, 스패밍, 비트코인 마이닝과
같은 다른 악성 행위에 악용될 수 있다
Web Storage
Web Storage는 브라우저에서 구현되는 약 5MB 크기의 저장 공간이며 각
도메인에 따라 별도로 제공 된다. 웹 애플리케이션은 정보 유지 및 관리를
위해 해당 공간에 다양한 정보를 저장할 수 있으며, 저장된 정보의 유출
및 변조에 따른 공격이 가능하다.
Web Socket
Web Socket 은 웹 서버와 User Agent간 지속적인 연결을 기반으로 하는
전이중 통신을 가능하게 해준다. 채팅, 주식 차트와 같은 실시간 통신이
필요한 애플리케이션에 활용할 수 있다. 또한 사용자의 정보를 탈취하는
은닉 채널로써 쓰일 수 있다.
Geolocation
Geolocation은 사용자(단말기)의 위치정보를 브라우저 단에서 측정할 수
있는 기능이다. 해당 기술은 모바일 장치에서 유용하게 사용되며 사용자의
위치 정보 노출로 다른 범죄에 악용될 수 있다.
Web Worker
HTML 4.01에서는 자바스크립트를 한 쓰레드로만 구동 가능하였으나, Web
Worker를 통하여 여러 개의 쓰레드로 자바스크립트를 구동할 수 있다.
Web Worker를 이용하여 악성 행위의 파급력을 증대할 수 있다.
- 179 -
2.2 보안 대응 이슈
안전한 웹 애플리케이션 개발을 위해서는 보안 취약점에 따른 적절한 대응 방안을 고
려하여 개발 및 운영하여야 한다. 또한 시스템 전체의 보안 취약점을 인지하고 웹 서버,
네트워크, 데이터베이스, 웹 기반 라이브러리에 대한 종합적인 보안 대응이 필요하다. 이
를 위해 자동화된 보안 점검 도구를 통한 지속적인 모니터링과 상시적인 웹 애플리케이
션 감시 체계를 구축하여야 하며, 특히 웹 애플리케이션의 경우 보안과 기밀성이 요구되
는 경우 SSL이나 TLS를 사용하여 데이터의 기밀성을 보장하는 방법을 고려해야 한다.
가. HTML5 신규 요소 관련 보안 위협
HTML5의 신규 요소 및 속성, API들은 보안의 관점에서 보면 보안 취약점을 통해 공격에
악용될 가능성이 높다. 예를 들어 onfocus, autofocus 등의 속성들은 기존 XSS(Cross-SiteScripting)
필터에 포함되지 않으면서 자바스크립트를 실행하는데 사용될 수도 있다.
Indexed DB
Indexed DB는 각 웹브라우저에서 도메인별로 DB를 제공/관리하는
기능이다. Web Storage와 마찬가지로 저장된 정보의 유출 및 변조에 따른
공격이 가능하다.
Pointer
Pointer API는 웹페이지 내 사용자의 마우스/터치 위치를 감지하는 API이다.
사용자의 마우스 이동/클릭 좌표와 터치 좌표를 알아낼 수 있어, 사용자의
행동을 유추하는 공격에 악용될 수 있다.
Vibration
Vibration API는 진동이 가능한 단말에 진동을 하는 API로, 일정 시간동안
진동하거나 패턴을 가지고 진동하는 두가지 방식이 가능하다. 오랜 시간
진동을 하여 사용자의 불편을 유발할 수 있다.
Custom Schema
Custom Schema는 웹브라우저에서 처리하는 프로토콜을 특정 웹
서비스로 처리할 수 있도록 등록하는 기능이다. 만약 악의적인
서비스로 특정 프로토콜을 처리하도록 하면, 해당 프로토콜을 사용할
때마다 악의적인 서비스가 구동될 수 있다.
SVG
XML 양식으로 이미지를 표현하는 SVG는 애니메이션, key 이벤트 탐지
등을 제공한다. SVG 내에 자바스크립트 삽입이나 사용자 Key 입력 정보
유출이 가능하다.
- 180 -
아래는 신규 video, audio 태그 및 속성을 이용한 XSS 취약점 예이다.
XSS외에도 신규 태그를 이용하여 사용자의 웹 페이지 사용을 저해할 수 있다. 기존의
서비스 거부(DoS)가 웹 서버가 아닌 사용자의 브라우저에서 일어나는 경우이다. 아래의 예
는 웹 페이지 내에 벗어날 수 없는 입력 폼을 삽입하여 다른 폼에 입력을 할 수 없도록
하는 예이다.
나. CORS(Cross Origin Resource Sharing)
웹 서비스 업체들이 제공하는 각종 콘텐츠와 서비스를 가져와 새로운 서비스를 재창
출하는 매시업(Mash-Up) 형태의 서비스가 활발하게 개발되고 있다. 이는 기존에 만들어
진 자원(또는 서비스)을 재사용하면 개발 비용 및 시간이 절약되기 때문이다. 하지만 동
일 출처정책(SOP: Same Origin Policy)에 의한 제한은 이러한 유형의 매시업 서비스 개
발을 어렵게 만들었다. 동일 출처 정책(SOP)이란, 웹브라우저들이 보안을 위해 자바스크
립트로 다른 도메인의 웹페이지에 접근하는 것을 못하도록 막아놓은 제약조건이다. 즉
호스트나 응용계층의 프로토콜, 포트번호가 일치하지 않는 곳으로부터의 요청 발생을
제한하는 정책이다.
기존에는 SOP를 우회하기 위해 Server-Side Proxy, JSONP 등의 다양한 편법들이 사용되
기도 했지만 웹 서비스 구현이 복잡해지고 성능에 영향을 준다는 단점을 가지고 있었다.
CORS는 웹 페이지에서 자바스크립트를 이용하여 XHR(XMLHttpRequest)을 다른 도메인
으로 발생시킬 수 있도록 해주는 기능을 가지고 있다. 해당 기술은 XHR 기반 CrossOrigin
요청을 이용하여 자원을 공유해야 하는 브라우저와 서버 사이의 대화 방법을 정의한다.
<video><source onerror=”alert(1)”></source></video>
<audio><source onerror=”alert(1)”></source><audio>
<select autofocus onfocus=”alert(1)”>
<textarea autofocus onfocus=”alert(1)”>
<input autofocus onblur=focus()></input>
- 181 -
CORS는 2004년 3월 미국의 통신회사인 Tellme Networks사의 엔지니어들이 처음 제안
했으며, 차후 W3C와 주요 브라우저 제조사들이 참여하여 표준화 작업을 진행하고 있다.
- CORS 관련 보안 위협
CORS의 근본적인 보안문제는 XHR을 다른 도메인으로 발생시킬 때, 사용자에게 허가
요청을 받지 않는다는 것이다. 이러한 문제는 사용자의 세션을 오용한 접근제어와 관
련된 보안 문제를 야기할 수 있다. 공격자가 사용자의 세션을 오용할 수 있게 된다는
것은 접근제어를 우회하여 허가되지 않은 리소스에 접근할 수 있다는 의미이다.
<표 6-2> CORS 관련 보안 위협
- CORS 보안 대응 방안
CORS를 이용한 사용자 개인정보 탈취 시나리오는 공격 대상 사이트의 파일 업로드
취약점(게시판 등에 저장된 자료에 대해 위치 지정에 대한 제한을 부여하지 않음으로
써 웹 서버 내의 비공개 자료를 다운로드/업로드 받을 수 있도록 하는 취약점)을 이
용하는 것으로 시작된다. 때문에 웹 서버의 파일 업로드 취약점에 대한 대응 조치를
한다면 악성 실행 프로그램을 업로드 하는 방식의 공격을 완화할 수 있다. 그리고 서
버는 Cross-Origin 요청을 모두 허용할 수 있는“Access-ControlAllow-Origin: *”과 같은
설정을 피하는 것이 좋다.
관련 보안 위협 보안 상 문제점
접근제어 우회
사용자가 속해있는 내부 네트워크에 존재하는 웹사이트가 “Access-
Control-AllowOrigin” 응답 헤더를 잘못 정의했을 경우 공격자는 외부에
서 직접 접근할 수 없는 내부 네트워크의 웹사이트에 접근할 수 있다.
CORS와 Web Socket을
이용한 원격 쉘 공격
XHR 과 Web Socket 기술을 이용하면 사용자의 브라우저 세션을 탈취하
고 행동을 제어할 수 있다. 대표적인 예로 세션 하이재킹 공격이 있다.
CORS와 Web Socket을
이용한 웹 기반 정보 유출
CORS와 Web Socket 기술을 이용하면 사용자의 브라우저들을 제어
하여 다양한 정보를 수 집하거나 명령을 내릴 수 있다. 또한 Cookie,
유출한 Web Storage, Indexed DB 정보를 외부로 보낼 수 있다.
CORS와 Web Worker를
이용한 DDoS 공격
CORS와 Web Worker를 이용하면 보다 효과적으로 DDoS 공격을
수행할 수 있다.
- 182 -
다. Web Storage
HTML5 이전 버전에서는 웹 애플리케이션 관련 콘텐츠를 클라이언트 측에 저장할 때
주로 쿠키를 사용하였다. 하지만 쿠키의 경우 몇 가지 문제점을 가지고 있다. 첫 번째는
도메인(사이트) 별로 20개까지만 쿠키를 생성할 수 있으며 각 쿠키는 4KB 크기를 넘을
수 없다는 것이다. 두 번째는 HTTP 요청이 발생할 때마다 쿠키 값이 포함되어 서버로
전송된다는 것이다. 이는 불필요한 오버헤드 및 웹세션 탈취 관련 문제점을 야기한다.
Web Storage는 이러한 문제점들을 보완하기 위해서 고안된 기술이다. Web Storage는
웹사이트와 관련된 콘텐츠를 사용자의 컴퓨터에 저장하고 이후에 자바스크립트를 이용하
여 접근하거나 통제할 수 있다. 컴퓨터에 저장할 수 있는 데이터의 용량은 브라우저의
종류에 따라 다르나 일반적으로 도메인당 5MB 정도의 크기를 사용할 수 있다.
<표 6-3> Web Storage 설명
- Web Storage 관련 보안 위협
Web Storage와 관련된 가장 큰 보안 이슈는 해당 영역에 저장되어 있는 데이터에 대
한 불법적인 접근과 이를 사용자 측에서 인지할 수 없다는 것이다. Web Storage에
대한 모든 접근 및 제어는 자바스크립트를 통해 이루어지며, 특정 도메인이 XSS 등
스크립트 기반 취약점을 가지고 있을 경우 공격자는 사용자의 브라우저에 있는 모든
Web Storage 데이터들을 사용자 모르게 조작하거나 가져올 수 있다. 해당 취약점은
HTML5 Web Storage의 자체적인 취약점으로는 볼 수 없지만, Cookie에 비하여 저장
공간이 크며, 다양한 정보가 저장되기 때문에 공격자가 탈취할 수 있는 정보 역시 많
다고 볼 수 있기에, 개발자는 해당 기술을 구현할 때 중요 정보를 암호화하여 저장하
거나 취급하지 않아야 할 것이다.
종류 설명
Session Storage기본적으로 Local Storage와 유사하나 브라우저 혹은 탭을 종료할 경우
데이터가 삭제된다.
Local Storage
해당 영역에는 모든 텍스트 값을 저장할 수 있다. 각 아이템들은 Key Name -
Value 쌍으로 구분되며, 존재하는 기존 아이템은 Key Name을 통해 접근할 수 있다.
사용자 혹은 웹 애플리케이션에 의해서 생성/삭제될 수 있으며, 브라우저를
종료해도 데이터들은 삭제되지 않는다.
- 183 -
- Web Storage 관련 보안 대응 방안
Local Storage에 저장된 사용자 개인정보 탈취 시나리오는 공격 대상 사이트의 XSS
취약점을 이용하는 것으로 시작된다. 때문에 XSS에 대한 대응조치(웹 방화벽 혹은 보
안코딩 등)가 되어 있다면 공격을 완화할 수 있다. 그리고 웹 애플리케이션 개발자는
평문 상태로 데이터를 저장하는 Local Storage에 사용자의 민감한 개인 정보를 저장
하지 않도록 하거나 암호화를 적용시켜 저장하도록 구현함으로써 정보 관리에 유의
하도록 한다.
라. Web Socket
웹에서 주로 사용되는 HTTP는 브라우저가 서버에게 요청을 해야만 서버에서 응답을
해주는 구조로 설계되어 있다. 이러한 구조는 채팅이나 주식시장 차트처럼 실시간 정보
전달을 요구하는 애플리케이션을 개발하는데 제한적이다.
네트워크 세션형성/종료에 많은 오버헤드를 가져오기 때문이다. 결국 한 번의 네트워
크 세션 형성을 통해 전이중 통신이 가능한 기술에 대한 개발자들의 요구사항이 커지게
되었고, 이러한 필요에 의해 HTML5의 Web Socket이 제안되었다.
- Web Socket 기술 관련 보안 위협
사용자의 허가 없이 다른 도메인으로 연결 요청을 발생시킬 수 있으며, 요청이 발생
했다는 사실을 사용자에게 알려주지 않는다. 공격자는 사용자의 브라우저에 임의의
자바 스크립트 코드를 실행하게 하여 사용자 모르게 브라우저를 통해 다른 도메인에
있는 시스템과 통신채널을 형성한 후 데이터 송수신이 가능하다.
- Web Socket 관련 보안 대응 방안
Web Socket API를 이용한 사설 네트워크 정보수집 시나리오는 공격 대상 사이트의
XSS 취약점을 이용하는 것으로 시작된다. 때문에 XSS 에 대한 대응조치(웹 방화벽
혹은 보안코딩 등)가 되어 있다면 공격을 완화할 수 있다. 만약 공격자의 사이트로
유도한 후 개인정보를 탈취하는 시나리오를 구현하는 경우라면 대응할 수 없다.
- 184 -
마. Geolocation
모바일 기기를 통한 인터넷 이용률 증가는 위치정보 기반의 서비스들이 급증하는데
큰 역할을 하였다. 대표적인 예가 SNS(페이스북 등)를 이용하여 자신의 위치를 공유하는
기능이다. 과거에는 이러한 기술을 구현하기 위해서는 부가적인 플러그인을 설치를 해
야만 가능했다. 하지만 HTML5의 Geolocation API가 등장하면서 브라우저 자체 기능만으
로 단말의 위치정보 계산이 가능해졌다.
일반적으로 스마트 단말의 경우 GPS(Global Positioning System), 3G, 4G네트워크 정보
등을 기반으로 위치정보가 수집되며, GPS가 없는 단말기의 경우에는 IP 주소 정보를 통
해 위치 정보를 계산한다.
- Geolocation 기술 관련 보안 위협
대부분의 브라우저들은 Geolocation API를 사용할 때 사용자에게 동의를 구하도록 설
계가 되어 있지만, 동일 도메인에서는 단 한 번의 동의를 통해 사용자의 위치정보를
계속 수집할 수 있는 경우가 있다. 이 경우 사용자가 공격자의 위치정보 수집 악성
링크를 클릭하고 무심결에 동의를 누를 경우 자신의 위치정보를 계속적으로 공격자
에게 전달할 수 있다. 이는 기존 Native-App에서도 발생 가능한 공격 기법이지만,
Geolocation을 적용한 HTML5 Web App의 경우 단순 사이트 방문만으로도 사용자의
위치정보가 노출될 수 있기 때문에, 기존 설치된 앱에서의 사용자 위치추적보다 위험
성이 크다고 볼 수 있다. Geolocation 기술 활용에 대한 개발자 및 사용자의 세심한
주의가 필요하다.
- Geolocation 보안 대응 방안
Geolocation API를 이용한 사용자 위치정보 추적 시나리오는 공격 대상 사이트의 XSS
취약점을 이용하는 것으로 시작된다. 때문에 XSS에 대한 대응조치(웹 방화벽 혹은 보
안코딩 등)가 되어 있다면 공격을 완화할 수 있다. 하지만 사용자를 공격자의 사이트
로 유도한 후 해당 시나리오를 구현하는 경우라면 대응할 수 없다. 개발자는 사용자
가 위치 정보 활용 동의를 할 때 정확한 가이드와 사업자 정보를 제공하는 방법으로
위치 접근에 따른 신뢰성을 높일 수 있다.
- 185 -
바. File API
File API는 자바스크립트를 통해 파일 시스템에 있는 파일의 데이터를 읽을 수 있게
하는 API를 말하며, Firefox 3.6 버전에서 처음 구현되었다. HTML5에서 해당 명세가 제
안되면서 웹 애플리케이션은 일부 브라우저상에서 플러그인의 도움을 받지 않고 시스템
에 있는 파일을 유연하게 다룰 수 있게 되었다.
- File API 기술 관련 보안 위협
현재까지 File API 자체 취약점은 알려진 바 없다. 악성 자바스크립트를 브라우저에
삽입한다 하여도 사용자가 자의적으로 파일을 선택하지 않는 이상 공격자는 아무런
공격을 수행할 수 없다. 하지만 사회 공학적 기법을 활용하면 사용자의 시스템에 있는
파일들을 탈취하는 것이 가능하다.
- File API 보안 대응방안
File API를 이용한 사용자 시스템 파일 탈취 시나리오는 공격 대상 사이트의 XSS 취약점을
이용하는 것으로 시작된다. 때문에 XSS에 대한 대응조치가 기본적으로 선행되어야 하고,
사용자가 파일을 저장할 때 사용자 정보 저장여부를 확인 할 수 있도록 해야 한다.
사. WebWorker
Web Worker는 기존의 자바스크립트를 단일 쓰레드로만 처리하는 문제점을 개선하기 위
하여, 자바스크립트를 여러 쓰레드로 처리할 수 있도록 제공된 기능이다. Web Worker를
이용하면 복잡한 연산을 병렬적으로 처리하여 높은 효과를 볼 수 있다.
- WebWorker 관련 보안 위협
Web Worker는 보안상의 이유로 별도의 자바스크립트를 구동하며, 이 별도의 자바스
크립트는 Web Worker를 구동하는 웹 페이지 내 다른 리소스에 접근이 불가능하다.
단, Web Worker는 외부로의 통신을 보낼 수 있기 때문에 DoS, 스패밍, 해시 크래킹,
비트코인 마이닝 등에 악용될 수 있다. 또한 사용자에게 Web Worker 구동에 대한
별도의 허가를 받지 않으므로, 사용자는 Web Worker가 자신의 브라우저 자원을 사
용되는 것을 모른 채 공격이 진행될 수 있다.
- 186 -
- Web Worker 보안 대응방안
Web Worker가 공격자의 웹 사이트에서 구동되는 경우, 의심스런 웹 사이트에 대한
접근을 주의하여야 한다. 정상 사이트에서는 XSS 취약점을 이용하여 Web Worker를
구동함으로 XSS에 대한 대응조치가 선행되어야 한다.
아. Indexed DB
Indexed DB는 각 도메인별로 DB 형태의 저장 공간을 제공하는 기능이다. Indexed DB를
이용하여 웹 사이트에서 처리할 정보를 사용자의 브라우저에 저장/사용할 수 있다.
- Indexed DB 관련 보안 위협
WebStroage와 마찬가지로 Indexed DB를 사용하는 웹 사이트에 XSS 취약점을 이용하여
악용하는 자바스크립트가 삽입되면, 사용자의 정보가 유출되거나 사용자가 의도하지
않은 악성 행위를 할 수 있다.
- Indexed DB 보안 대응방안
Indexed DB에 민감한 정보를 저장하지 말아야하며, 부득이하게 저장할 경우 암호화
하여 저장하도록 한다. 또한 정상 사이트에서 Indexed DB에 접근하는 악의적인 자바
스크립트를 XSS 취약점을 이용하여 삽입함으로 XSS에 대한 대응조치가 선행되어야
한다.
자. Pointer
Pointer API는 웹 페이지 내의 포인터가 될 수 있는 좌표 정보를 처리한다. 대표적으
로 마우스나 터치 위치를 이벤트로 감지한다. Pointer 이벤트는 다양한 기능을 구현하는
데 쓰일 수 있으나, 반대로 사용자의 행동을 파악하여 다른 공격에 악용하는데 쓰일 수
도 있다.
- 187 -
- Pointer 관련 보안 위협
Pointer API 자체의 취약점은 없으나, Pointer 정보는 경우에 따라 민감한 정보에 속할
수 있다. 특히 가상 키보드와 같이 마우스나 터치 입력으로 개인 정보를 다루는 경우,
해당 마우스/터치 위치가 공격자에게 전송되어 개인정보 유출로 이어질 수 있다.
- Pointer 보안 대응방안
마우스나 터치 입력이 읽히지 않도록 민감 정보를 다루는 영역에서 자바스크립트가
구동되지 않도록 한다. iframe내 자바스크립트 구동을 막는 sandbox 속성을 이용하거
나 민감한 영역을 별도의 영역으로 지정한다. 기본적으로 공격 코드가 삽입되지 않도
록 XSS에 대한 대응조치가 같이 진행되어야 한다.
차. Vibration
Vibration API는 진동이 가능한 단말에서 작동하는 API로, 특정 시간동안 혹은 특정
패턴으로 진동을 하도록 하는 API이다. Vibration API가 작동하는 웹 페이지가 가장 상
단에 활성 중인 상태여야 작동 가능하다.
- Vibration 관련 보안 위협
Vibration API는 최대 10분간만 진동할 수 있도록 되어있다. 패턴을 입력하는 경우도
마찬가지이다. 다만 Vibration API 자체를 여러 번 호출할 경우, 10분이 넘도록 진동
을 하게 할 수 있다. 웹 페이지가 켜져 있어야 작동하지만, 해당 웹 페이지를 이용하
는 동안에는 계속 진동을 하여 사용자 단말의 배터리를 소모하거나 사용자에게 불편
을 유발할 수 있다.
- Vibration 보안 대응방안
Vibration 보안은 웹브라우저에서 패치 되어야 할 내용으로 웹 사이트 관리자가 취할
수 있는 조치는 Vibration API가 삽입되지 않도록 주의하는 방법 외엔 없다.
- 188 -
카. Custom Schema
Custom Schema는 웹브라우저에서 처리하는 프로토콜을 특정 서비스로 연결시켜주는
기능이다. 예로 메일(mailto)의 경우 기본 메일 프로토콜 대신 지메일의 프로토콜을 쓸
수 있도록 설정해주는 경우를 들 수 있다.
- Custom Schema 관련 보안 위협
Custom Schema를 통하여 사용자가 자주 사용하는 메일(mailto), 공유 서비스(magnet)
을 악의적인 서비스에 연결하여 해당 프로토콜 내용을 유출할 수 있다. 또한 해당 프
로토콜을 사용할 때마다 공격자의 서비스가 실행됨으로 사용자를 공격자의 웹 사이
트로 이동시키거나 사용자의 브라우저 리소스를 다른 공격에 사용할 수 있다.
- Vibration 보안 대응방안
Protocol Schema는 사용자에게 해당 서비스로 등록할 건지 여부를 묻지만, 한 번 등
록되면 웹브라우저 설정에서 바꾸지 않는 한 변하지 않는 문제점이 있다. Protocol 등
록과 자동으로 연결되는 서비스에 주의하여야 한다. 또한 공격 코드가 삽입되지 않도
록 웹 사이트를 관리한다.
타. SVG
SVG는 벡터로 이미지를 표현하는 포맷으로, HTML5에서는 SVG 포맷과 SVG 태그를
지원한다. SVG는 XML 형태로 작성되고, SVG를 이용한 애니메이션이나 사용자의 키 입
력을 감지하는 이벤트 기능을 제공한다.
- SVG 관련 보안 위협
SVG 파일이나 태그 내에 자바스크립트 태그인 script가 삽입 가능하다. 즉, SVG 이미
지나 태그 내에 자바스크립트를 삽일 할 수 있다. SVG 내의 스크립트는 SVG 로딩과
함께 자동으로 실행된다. 이를 이용하여 다른 공격을 위한 XSS에 쓰일 수 있다.
- 189 -
- SVG 보안 대응방안
SVG내의 자바스크립트는 embed, object, iframe을 사용하였을 때 실행된다. embed,
object 태그를 이용하여 SVG를 로딩하지 않아야하며, iframe을 이용할 경우에는 자바
스크립트 실행을 막는 sandbox 속성을 함께 쓴다. 이미지를 처리하는 img, image 태
그로 SVG를 로딩하면 삽입된 자바스크립트가 실행되지 않으므로, img, image 태그를
이용하여 SVG를 처리하도록 한다. 또한 이미지나 파일 업로드 시 파일 확장자명을
제한하여 SVG 업로드를 막는다.
파. 기타 보안 이슈
- iframe 보안 이슈
HTML5에서는 투명한 iframe이 가능하다. 투명한 iframe을 이용한 사회공학적 기법인
Clickjacking은 사용자를 공격자가 의도한 웹 사이트로 이동시키거나, 사용자의 파일
업로드를 가로채 유출하는 공격이다. 이에 대응하여 iframe 삽입이 되지 않도록 웹
사이트에서 조치를 취해야한다. 단, HTML5에 추가된 iframe 속성인 sandbox는 iframe
내의 자바스크립트 실행을 방지하는 속성으로, 기존의 숨은 iframe을 제거하는 iframe
killer 코드와 충돌을 일으키기 때문에 사용에 주의해야 한다.
- 사회공학적 기법 이슈
HTML5 속성을 이용한 사회공학적 기법은 위에 언급한 ClickJacking 외에도 자동 완
성 기능을 악용한 정보 유출, 웹 페이지가 비활성화 상태일 때 웹 페이지의 내용을
바꿔서 다른 사이트로 착각하게 만드는 Tabnabbing, 사용자의 단말에 알림을 주는
Desktop Notification을 이용한 피싱 공격 등이 있다.
- 비공식 API 사용 이슈
HTML5 요소의 알려진 비공식적인 API를 웹 사이트 구축에 이용하는 경우가 있다. 대표적으로
FullScreen API는 HTML5 신규 API로 알려져 있으나, 실제로는 HTML5 신규 API로 채택
이 거절당했음에도 몇몇 웹브라우저에서 자체적으로 지원하는 기능이다. 또한 WebSQL은
Indexed DB 이전에 SQL문법을 이용하여 사용자 브라우저에 DB를 제공하는 방식으로 제
안되었으나, HTML5 표준으로 등록되지 못하였다. 이도 몇몇 웹브라우저에서 구현한 기
능이나, 이에 대한 검증이 부족함으로 이러한 기능을 사용하지 않도록 유의한다.
- 190 -
- 내부 네트워크 정보수집 이슈
HTML5에서는 XHR, WebSocket을 이용하여 외부로 호출을 보낼 수 있다. 보낸 호출
에 대한 응답 시간을 이용하여 해당 IP 혹은 Port가 활성화된 상태인지 확인할 수 있
다. 이런 사설 네트워크 정보 수집은 다른 공격에 악용될 수 있다. 내부 네트워크에
연결된 장비 중에 외부 호출에 반응하는 장비가 있을 경우, 추가적인 악성 행위를 할
수 있다. 예로 추가적인 보안 설정이 되지 않은 네트워크 프린터의 경우, 기본 포트
인 9100으로 웹 호출이 들어올 경우, 해당 웹 호출 정보를 종이에 출력한다.
- HTML5 모바일 앱 코드 인젝션
모바일 앱 중 HTML5를 기반으로 만들어진 앱의 경우, 앱에서 파일을 불러올 때, 파
일 이름이나 메타 정보에 들은 자바스크립트가 실행될 수 있다. 또한 입력되는 QR
코드나 바코드의 내용이 자바스크립트면 자동으로 실행되기도 한다. 이를 HTML5 코
드 인젝션이라 한다. HTML5 모바일 앱을 만들 경우, 외부로부터 입력되는 값에 대한
필터링이 필요하다.
하. OWASP(The Open Web Application Security Project)
<표 6-4> OWASP HTML5보안 위협 항목
공격유형 설명 대응 방안
크로스 사이트
스크립팅(XSS)
정상 웹 사이트에 태그와 속성을 이용하거나
업로드하는 리소스를 이용하여 자바스크립트를
삽입할 수 있는 취약점으로, 주로 사용자가
올리는 정보에 대한 필터링이 없는 점을
악용한다.
HTML 태그를 분석해 안전한 태그 및
속성 값만으로 HTML을 재구성하고 신뢰할
수 없는 스크립트 실행을 차단한다.
※ 시큐어코딩가이드 3 판, 크로스사이트
요청위조[19] 참고
크로스 사이트
요청(CSRF) 변조
웹 애플리케이션이 사용자 인증을 요청할 때
매번 HTTP 요청 시 마다 암호를 입력하도록
하지 않고 세션 쿠키나 HTTP 인증 헤더 등을
이용해 다수의 HTTP 요청에서 이를 사용한다.
CSRF 는 이점을 이용하며, 사용자가 신뢰할 수
있는 서비스에 로그인 되어 있다가 사용자인척
가장하여 서비스를 악용하거나 다른 공격에
사용한다.
폼 데이터를 전송할 때 해당 입력 값의
인코딩 방식 및 유효값 여부를 사전에
검사하고 신뢰할 수 있는 데이터만 처리한다.
※ 시큐어코딩가이드 3 판, 크로스사이트
요청위조[19] 참고
- 191 -
JSON 하이재킹
JSON 하이재킹은 CSRF를 기반으로 한 공격
방법이며, 일부 브라우저의 특성을 이용하여,
악성 사이트에서 JSON 포맷으로 된 기밀
데이터를 가로채어 공격한다.
클라이언트 코드의 무결성을 검증할 수
있는 코드를 별도로 구현한다
(MD5 기반 해시값을 사전에 서버로 보내
무결성을 검증하는 방법도 사용한다).
※ OWASP AJAX Security Guidelines[20] 참고
서비스거부 공격
(DoS, Denial of S
ervice)
일반적 DoS는 특정 웹사이트에 반복적으로
리소스를 요구하는 제3의 자바스크립트가
사용자의 브라우저에서 수행되어 특정 사이트를
반복적으로 응답 요청(공격)한다. Client DoS는
웹 사이트가 아닌 사용자의 브라우저에 부하를
주거나 사용자의 사용을 불가능하게 만든다.
웹 애플리케이션 특성상 경로를 허용하는
경우에는 ‘../’와 같은 상대 경로를
차단하고 절대 경로만 허용하도록 해야
한다.
사전에 허용된 경로가 아닌 곳으로
접근하는 것은 서버에서 차단해야 한다.
※ KISA DDoS 공격대응가이드[21] 참고
API Mashup을
통한 공격
비공식 외부 API를 통한 매쉬업 애플리케이션을
개발하여 배포할 경우 사용자와 매쉬업
애플리케이션 모두 보안 취약점을 갖게 되며,
매쉬업 애플리케이션에 악성 코드를 삽입하여
XSS, CSRF, DDoS 등을 포함하여 공격한다.
인가된 API key 값을 사전에 확인해야
하며, API 취약점 정보를 모니터링하고,
기술적 문제점을 보완해야 한다.
※ OpenAjax Alliance, Ajax and Mashup
Security[22] 참고
- 192 -
3. HTML5 브라우저 수용도
HTML5에 대한 브라우저별 수용도는 브라우저의 버전별로 차이가 있기 때문에 아래의
표는 현재 최신 버전의 기준으로 분류하여 수용도를 제공하였다.
본 문서의 웹브라우저 HTML5 표준 및 관련 규격 지원 여부를 측정을 위하여 벤치마크
사이트는 http://html5test.com에서 제공하였으며, 각 평가 항목에 대한 정보를 아래와 같다.
3.1 HTML5 수용도 평가 항목 분석
1) 구조규칙(semantics)
HTML5에서 문서의 구조 및 규칙을 의미하는 태그로 파싱규칙(parsing rules), 요소(element
s), 폼(Forms), 웹 구성요소(web components)로 구분되었고 웹을 구성하는 기본적인 의미
의 태그로 구분되었다.
가. 파싱규칙(parsing rules)
웹 페이지 상에 기술된 HTML5 명령어를 인식할 수 있는 기능을 정의 하는 부분으로 가
장 기본적인 부분으로 <!DOCTYPE html>은 웹브라우저가 읽게 될 문서의 종류를 정의
하는 부분이며 HTML5 tokenizer, HTML5 tree building, Parsing inline SVG, Parsing inline
MathML에 대한 파싱 규칙이 있으며 대부분 최신 브라우저에서는 모두 수용하고 있다.
나. 요소(elements)
요소는 시작과 끝을 의미하는 태그로 구성되어있고 태그 사이에는 콘텐츠를 포함하고
있다. 대표적인 태그는 header, footer 등이 있다. 섹션 태그 및 그룹핑 관련 태그들은
최신 브라우저에서 대부분 수용되고 텍스트 레벨 관련 요소들은 수용되지 않고 있다.
다. 폼(Forms)
폼은 텍스트 필드, 버튼, 체크박스, 범위 컨트롤, 색상 선택기 같은 폼 컨트롤, 필드의
정규식 규칙을 포함하고 있다. 특정 파일 필드의 업로드 기능을 제외한 폼과 관련한
기능은 대부분의 브라우저에서 수용하고 있다.
- 193 -
라. 웹 구성요소(web components)
웹 컴포넌트를 구성하는 템플릿, 새로운 요소를 만들 수 있는 커스텀 요소, DOM의
구조를 가지고 있으나 외부에 노출되지 않는 섀도 DOM으로 구성되어있다. 웹 컴포
넌트는 대부분의 브라우저에서 수용되고 그 밖에 커스텀 요소 및 섀도 Dom은 최신
브라우저에서 일부만 수용 되고 있다.
2) 단말접근(device access)
가. 위치 및 방향(Location and Orientation):
디바이스의 방향(가로, 세로), 모션(가속도, 회전), 위치를 포함하고 있으며, 최신 브라
우저에서 대부분의 기능이 수용되고 있다.
나. 출력(Output)
사용자에게 알리는 알림 및 전체 화면으로 볼 수 있는 기능을 포함하고 있으며, 최신
브라우저에서 대부분의 기능이 수용되고 있다.
다. 입력(Input):
게임패드 컨트롤, 터치 이벤트 등을 포함한 Pointer event, Pointer Lock기능을 포함하
고 있으며, Xbox 및 최신 브라우저에서 일부 수용 되고 있다.
3) 연결성(Connectivity)
가. 커뮤니케이션(Communication)
서버와 통신 시 발생하는 이벤트(컨넥트, 접속종료), 비콘 및 socket통신 활용을 위한
WebSocket 등 서버 및 다른 디바이스와 통신을 위한 기능을 포함하고 있으며, 대부
분의 브라우저에서 수용되고 있다.
- 194 -
나. 스트림 (Streams)
디바이스로부터 데이터를 읽거나 기록할 때 사용하는 중간 매개체의 역할 기능을 포
함하고 있으며, 데이터를 읽는 기능을 대부분의 브라우저에서 수용되고 기록에 사용
되는 기능은 모든 브라우저에서 수용되지 않고 있다.
다. 대등연결 (Peer To Peer)
계층통신으로 네트워크에 연결되어 있는 모든 컴퓨터들이 서로 대등한 입장에서 데
이터 혹은 주변장치를 공유할 수 있다. WebRTC, WebCam 접근 등의 기능을 포함하
고 있으며, 퍼미션 등의 보안권한이 필요한 Screen capture 등의 기능을 제외하고 최
신 브라우저에서 일부 수용되고 있다.
4) 동작 및 통합(Performance & Integration)
HTML5 에서 사용자와 상호작용하는 인터페이스 동작 및 Editing요소, 클립보드 기능을 포함하
고 있으며, 그 밖에 다중 프로그래밍을 위한 Woker 및 보안 기능, 결제 기능도 포함하고 있다.
가. 사용자 상호작용(User Interaction)
사용자와 상호작용하는 기능으로 Drag and drop(끌어다 놓기), Editing 요소, 맞춤법
검사, 복사 붙여넣기 기능을 포함한 클립보드 기능을 포함하고 있다. 최신 브라우저
에서 상호작용 기능이 수용되고 있다.
나. 동작(Performance)
멀티 쓰레드 기능을 포함한 Workers 기능을 포함하고 있으며 window.requestIdleCallback
기능을 제외한 Workers기능은 대부분의 브라우저에서 관련 기능이 수용되고 있다.
다. 보안(Security)
암호화 API 및 iframe에 제한이 엄격하여 생긴 sandbox iframe의 기능을 포함하고 으
며, 대부분의 브라우저에서 관련 기능이 수용되고 있다.
- 195 -
라. 결제(Payments)
HTML5 내에서 결제를 지원하는 기능으로 아직 실험단계이며, 브라우저에서 관련 기
능이 수용되지 않고 있다.
5) 다중매체 지원 (multimedia)
HTML5에서 다중매체를 지원하는 기능으로 video 요소, audio 요소 및 관련 코덱을 부
분적으로 지원하고 있다.
가. 영상(Video)
Video요소 및 자막 및 포스터 이미지의 기능을 지원하고 있다. 그 밖에 Video 관련
코덱을 지원하고 있지만 대부분의 브라우저에서 관련 기능이 수용되고 있지 않다.
나. 음성(Audio)
Audio요소 및 음성 API, 음성인식 기능을 포함하고 있다.
다. 전송(Streaming)
사용자들에게 각종 비디오, 오디오 등의 멀티미디어 디지털 정보를 제공하는 기술로
다운로드 없이 실시간으로 재생해 주는 기법이다. 그 밖에 디지털 저작권 관리라고도
불리는 DRM지원을 포함하고 있다. 대부분의 브라우저에서 관련 기능이 수용되고 있
지만 코덱은 제한적으로 제공하고 있다.
6) 입체, 영상 효과 (3d, graphics & effects)
HTML5에 시각적으로 보여주는 기능들을 포함하고 있다. 시각적으로 보여주는 기능으
로 반응형 이미지, 2D, 3D그래픽을 포함한 애니메이션을 포함한다.
가. 반응형이미지(Responsive images)
해상도에 따라 사이즈를 자동적으로 조절하는 picture 요소를 포함하고 있으며 sizes의
속성을 지원한다. 대부분의 브라우저에서 관련 기능을 수용하고 있다.
- 196 -
나. 2차원-평면- 이미지(2D Graphic)
캔버스를 활용한 2D 그래픽 기능을 포함하고 있다. 2D 그래픽 기능으로는 텍스트, 패
스, 선 종류 등이 있다. 지원하는 이미지로는 PNG, JPEG 포맷을 지원하고 있으며, 대
부분의 브라우저에서 관련 기능을 수용하고 있다.
다. 3차원-입체; 가상현실(3D and VR)
3D 그래픽을 활용하기 위해 OpenGL을 활용한 WebGL 기능 및 WebVR 기능을 포
함하고 있다. WebGL 기능은 대부분 브라우저에서 수용되고 있지만 WebVR 기능은
수용되고 있지 않다.
라. 애니메이션(Animation)
Web Animation API 기능을 포함하고 있다. (opacity, scale 등)
최신 브라우저에서 관련 기능이 일부 수용되고 있다.
7) 오프라인 저장공간 (offline & storage)
HTML5에서는 네트워크가 연결되지 않은 상태에서 실행 가능한 웹 응용프로그램 및
내부 저장소, DB를 포함한다.
가. 웹 응용프로그램 (Web applications)
클라이언트 측에 저장하고 활용하는 캐쉬 및 서비스 워커, 푸쉬메시지를 포함한다.
캐시 및 서비스워커는 최신 브라우저에서 관련 기능을 수용하고 있고 푸쉬메시지는
일부 모바일 브라우저에서 관련 기능을 수용하고 있다.
나. 저장공간 (Storage)
클라이언트사이드의 key-value형식의 저장소 및 IndexedDB를 제공한다. 그 밖에 Web
SQL Database를 제공한다.
대부분의 관련 기능이 브라우저에서 수용되고 있지만 Web SQL Database는 더 이상
업데이트 되지 않고 IndexedDB로 변경 예정이다.
- 197 -
다. 파일 (Files)
일반적인 파일의 읽기, Blob API 및 파일 시스템 API를 포함하고 있으나, 파일 시스
템의 쓰기 기능은 브라우저에서 수용되고 있지 않다.
8) 기타(other)
스크립트 및 세션 히스토리, 텍스트 선택 기능들이 포함되어 있다.
가. 스크립트 지원(Scripting):
ECMA-262 기술 규격에 정의된 표준화된 스크립트 프로그래밍 언어를 지원하고 있
다. 그 밖에 base64 인코딩, 디코딩 및 URL API 등을 포함하고 있으며, 일부 최신 브
라우저에서 ECMAScript6 까지 수용되고 있다.
나. 기타
세션 히스토리, Page Visibility API 및 텍스트 셀렉션 기능을 포함하고 있으며, 최신
브라우저에서 대부분 수용되고 있다.
- 198 -
3.2 HTML5 수용도 평가표
<표 6-5> 브라우저별 웹표준 수용도(○:수용, △: 분수용, ☆:별도처리, x:비수용)
구 분
Desktop browsers Mobile
IE11
Edge14
Chrome52
Safari9.1
Firefox48
Opera37
삼성인터넷4.0
iOS10
Parsing rules
<!DOCTYPE html> triggers
standards mode○ ○ ○ ○ ○ ○ ○ ○
HTML5 tokenizer ○ ○ ○ ○ ○ ○ ○ ○
HTML5 tree building ○ ○ ○ ○ ○ ○ ○ ○
Parsing inline SVG ○ ○ ○ ○ ○ ○ ○ ○
Parsing inline MathML ○ ○ ○ ○ ○ ○ ○ ○
Elements
Embedding custom
non-visible data○ ○ ○ ○ ○ ○ ○ ○
New or modified elements
Section elements ○ ○ ○ ○ ○ ○ ○ ○
Grouping content elements
△ △ ○ ○ ○ ○ ○ ○
Text-level semantic elements
△ △ △ △ △ △ △ △
Interactive elements x x △ △ △ △ △ △
Global attributes or methods
hidden attribute ○ ○ ○ ○ ○ ○ ○ ○
Dynamic markup insertion
○ ○ ○ ○ ○ ○ ○ ○
- 199 -
Forms
Field types
input type=text △ ○ ○ ○ ○ ○ ○ ○
input type=search ○ ○ ○ ○ ○ ○ ○ ○
input type=tel ○ ○ ○ ○ ○ ○ ○ ○
input type=url ○ ○ ○ ○ ○ ○ ○ ○
input type=email ○ ○ ○ ○ ○ ○ ○ ○
input type=date x ○ ○ x x ○ ○ ○
input type=month x ○ ○ x x ○ ○ ○
input type=week x ○ ○ x x ○ ○ ○
input type=time x ○ ○ x x ○ ○ ○
input type=datetime-l
ocalx ○ ○ x x ○ ○ ○
input type=number ○ ○ ○ ○ ○ ○ ○ ○
input type=range ○ ○ ○ ○ ○ ○ ○ ○
input type=color x ○ ○ x ○ ○ ○ x
input type=checkbox ○ ○ ○ ○ ○ ○ ○ ○
input type=image ○ ○ ○ ○ ○ ○ ○ ○
input type=file △ △ △ △ △ △ △ △
textarea ○ ○ ○ ○ ○ ○ ○ ○
select ○ ○ ○ ○ ○ ○ ○ ○
fieldset △ △ ○ ○ ○ ○ ○ ○
datalist ○ ○ ○ x ○ ○ ○ x
output x ○ ○ ○ ○ ○ ○ ○
progress ○ ○ ○ ○ ○ ○ ○ ○
meter x ○ ○ ○ ○ ○ ○ x
Fields
Field validation ○ ○ ○ ○ ○ ○ ○ ○
Association of controls and
forms△ △ ○ ○ △ ○ ○ ○
Other attributes △ △ ○ ○ △ ○ ○ ○
CSS selectors △ ○ ○ ○ ○ ○ ○ ○
Events △ ○ ○ ○ ○ ○ ○ ○
- 200 -
Forms
Form validation ○ ○ ○ ○ ○ ○ ○ ○
Web components
Custom elements x x ○ x x ○ ○ x
Shadow DOM x x △ x x △ △ ○
HTML templates x ○ ○ ○ ○ ○ ○ ○
HTML imports x x ○ x x ○ ○ x
Location and orientation
Geolocation ○ ○ ○ ○ ○ ○ ○ ○
Device Orientation ○ ○ ○ x ○ ○ ○ ○
Device Motion ○ ○ ○ x ○ ○ ○ ○
Output
Full screen support ☆ ☆ ☆ ☆ ☆ ☆ ☆ x
Web Notifications x ○ ○ ○ ○ ○ ○ x
Input
Gamepad control x ○ ○ x ○ ○ ○ x
Pointer Events ○ ○ x x x x x x
Pointer Lock support x ○ ○ x ☆ ○ ○ x
Video
video element ○ ○ ○ ○ ○ ○ ○ ○
Subtitles ○ ○ ○ ○ ○ ○ ○ ○
Audio track selection ○ ○ x ○ x x x ○
Video track selection x ○ x ○ x x x ○
Poster images ○ ○ ○ ○ ○ ○ ○ ○
Codec detection ○ ○ ○ ○ ○ ○ ○ ○
Video codecs
MPEG-4 ASP support x ○ x ○ x x x ○
- 201 -
H.264 support ○ ○ ○ ○ ○ ○ ○ ○
H.265 support x ○ x x x x x x
Ogg Theora support x x ○ x ○ ○ x x
WebM with VP8 support x x ○ x ○ ○ ○ x
WebM with VP9 support x x ○ x ○ ○ ○ x
Audio
audio element ○ ○ ○ ○ ○ ○ ○ ○
Loop audio ○ ○ ○ ○ ○ ○ ○ ○
Preload in the background ○ ○ ○ ○ ○ ○ ○ ○
Advanced
Web Audio API x ○ ○ ☆ ○ ○ ○ ☆
Speech Recognition x x ☆ x x ☆ ☆ x
Speech Synthesis x ○ ○ ○ x ○ x x
Audio codecs
PCM audio support x ○ ○ x ○ ○ ○ x
MP3 support ○ ○ ○ ○ ○ ○ ○ ○
AAC support ○ ○ ○ ○ ○ ○ ○ ○
Dolby Digital support x ○ x ○ x x x ○
Dolby Digital Plus support x ○ x ○ x x x ○
Ogg Vorbis support x x ○ x ○ ○ ○ x
Ogg Opus support x x ○ x ○ ○ x x
WebM with Vorbis support x x ○ x ○ ○ ○ x
WebM with Opus support x x ○ x ○ ○ ○ x
Streaming
Media Source extensions ○ ○ ○ ○ ○ ○ x x
DRM support ☆ ○ ○ ☆ ○ ○ ○ x
- 202 -
Adaptive bit rate
Dynamic Adaptive
Streaming / MPEG-DASH
x ○ x x x x x x
HTTP Live Streaming / HLS x ○ x ○ x x ○ ○
Codecs
Video codecs △ △ △ △ △ △ x x
Audio codecs △ △ △ △ △ △ x x
Responsive images
picture element x ○ ○ ○ ○ ○ ○ ○
srcset attribute x ○ ○ ○ ○ ○ ○ ○
sizes attribute x ○ ○ ○ ○ ○ ○ ○
2D graphics
Canvas 2D graphics ○ ○ ○ ○ ○ ○ ○ ○
Drawing primitives
Text support ○ ○ ○ ○ ○ ○ ○ ○
Path support x ○ ○ ○ ○ ○ ○ ○
Ellipse support x ○ ○ ○ ○ ○ ○ ○
Dashed line support ○ ○ ○ ○ ○ ○ ○ ○
System focus ring support x ○ ○ ○ ○ ○ ○ ○
Features
Hit testing support x x x x x x x x
Blending modes x ○ ○ ○ ○ ○ ○ ○
Image export formats
PNG support ○ ○ ○ ○ ○ ○ ○ ○
JPEG support ○ ○ ○ ○ ○ ○ ○ ○
JPEG-XR support x x x x x x x x
WebP support x x ○ x x ○ ○ ○
- 203 -
3D and VR
3D Graphics
WebGL ☆ ☆ ○ ○ ○ ○ ○ ○
WebGL 2 x x x x x x x x
VR Headset
WebVR x x x x x x x x
Animation
Web Animations API x x ○ x ○ ○ ○ x
window.requestAnimationFrame ○ ○ ○ ○ ○ ○ ○ ○
Communication
Server-Sent Events x x ○ ○ ○ ○ ○ ○
Beacon x ○ ○ x ○ ○ ○ x
Fetch x ○ ○ x ○ ○ ○ x
XMLHttpRequest Level 2
Upload files ○ ○ ○ ○ ○ ○ ○ ○
Response type support ○ ○ ○ ○ ○ ○ ○ ○
WebSocket
Basic socket communication ○ ○ ○ ○ ○ ○ ○ ○
ArrayBuffer and Blob support ○ ○ ○ ○ ○ ○ ○ ○
Streams
Readable streams x ○ ○ x x ○ ○ x
Writable streams x x x x x x x x
Peer to peer
Connectivity
WebRTC 1.0 x x ☆ x ○ ☆ ☆ x
ObjectRTC API for WebRTC x ○ x x x x x x
Data channel x x ☆ x ○ ☆ ☆ x
- 204 -
Input
Access the webcam x ○ ☆ x ○ ☆ ☆ x
Screen Capture x x x x x x x x
Enumerate devices x ○ ○ x ○ ○ x x
Recording
Media Stream recorder x x ○ x ○ ○ x x
User interaction
Drag and drop
Attributes △ △ ○ ○ △ ○ x x
Events ○ ○ ○ ○ ○ ○ x x
HTML editing
Editing elements ○ ○ ○ ○ ○ ○ ○ ○
Editing documents ○ ○ ○ ○ ○ ○ ○ ○
CSS selectors x ○ ○ ○ ○ ○ ○ ○
APIs ○ ○ ○ ○ ○ ○ ○ ○
Clipboard
Clipboard API and events x ○ ○ x ○ ○ ○ x
Spellcheck
spellcheck attribute ○ ○ ○ ○ ○ ○ ○ ○
Performance
Workers
Web Workers ○ ○ ○ ○ ○ ○ ○ ○
Shared Workers x x ○ x ○ ○ ○ x
Other
window.requestIdleCallback x x ○ x x ○ x x
Security
Web Cryptography
API☆ ○ ○ ☆ ○ ○ ○ ☆
- 205 -
Content Security Policy 1 x ○ ○ ○ ○ ○ ○ ○
Content Security Policy 2 x x ○ x x ○ ○ ○
Cross-Origin Resource Sharing
○ ○ ○ ○ ○ ○ ○ ○
Subresource Integrity x x ○ x ○ ○ x x
Cross-document messaging ○ ○ ○ ○ ○ ○ ○ ○
Authentication
Web Authentication /
FIDO 2x △ x x x x x x
Credential Management x x ○ x x x x x
Iframes
Sandboxed iframe ○ ○ ○ ○ ○ ○ ○ ○
iframe with inline contents x x ○ ○ ○ ○ ○ ○
Payments
Web Payments x x x x x x x x
Web applications
Offline resources
Application Cache ○ ○ ○ ○ ○ ○ ○ ○
Service Workers x x ○ x ○ ○ ○ x
Push Messages x x ○ x ○ ○ ○ x
Content and Scheme handlers
Custom scheme handlers x x ○ x ○ ○ ○ x
Custom content handlers x x x x ○ x ○ x
Storage
Key-value storage
Session Storage ○ ○ ○ ○ ○ ○ ○ ○
Local Storage ○ ○ ○ ○ ○ ○ ○ ○
- 206 -
Database storage
IndexedDB ○ ○ ○ ○ ○ ○ ○ ○
Objectstore Blob support ○ ○ ○ x ○ ○ ○ ○
Objectstore ArrayBuffer
support○ ○ ○ ○ ○ ○ ○ ○
Web SQL Database x x ○ ○ x ○ ○ ○
Files
Reading files
Basic support for reading files ○ ○ ○ ○ ○ ○ ○ ○
Create a Blob from a file ○ ○ ○ ○ ○ ○ ○ ○
Create a Data URL from a
Blob○ ○ ○ ○ ○ ○ ○ ○
Create an ArrayBuffer from
a Blob○ ○ ○ ○ ○ ○ ○ ○
Create a Blob URL from a
Blob○ ○ ○ ○ ○ ○ ○ ○
Accessing the file system
FileSystem API x x x x x x x x
File API: Directories and
Systemx x ☆ x x ☆ ☆ x
Scripting
Script execution
Asynchronous script execution ○ ○ ○ ○ ○ ○ ○ ○
Defered script execution ○ ○ ○ ○ ○ ○ ○ ○
Script execution events x x x x ○ x x x
Runtime script error reporting ○ ○ ○ ○ ○ ○ ○ ○
ECMAScript 5
JSON encoding and decoding ○ ○ ○ ○ ○ ○ ○ ○
- 207 -
ECMAScript 6
Modules x x x x x x x x
Classes x ○ ○ ○ ○ ○ x ○
Arrow functions x ○ ○ x ○ ○ x ○
Promises x ○ ○ ○ ○ ○ ○ ○
Template strings x ○ ○ ○ ○ ○ ○ ○
Typed arrays ○ ○ ○ ○ ○ ○ ○ ○
Internationalization ○ ○ ○ x ○ ○ x ○
ECMAScript 7
Async and Await x x x x x x x x
Other API's
Base64 encoding and
decoding○ ○ ○ ○ ○ ○ ○ ○
Mutation Observer ○ ○ ○ ○ ○ ○ ○ ○
URL API ○ ○ ○ ○ ○ ○ ○ ○
Encoding API x x ○ x ○ ○ ○ x
Other
Session history ○ ○ ○ ○ ○ ○ ○ ○
Page Visibility ○ ○ ○ ○ ○ ○ ○ ○
Text selection ○ ○ ○ ○ ○ ○ ○ ○
Scroll into view ○ ○ ○ ○ ○ ○ ○ ○
- 208 -
4. HTML5.1 글로벌 동향 분석
웹 표준화 단체인 W3C의 웹 플랫폼 워킹그룹(Web Platform Working Group)이 HTML5.1
을 W3C 권고안으로 공개했다. 지난 9월 권고를 목표로 작업을 진행하던 것이다.
W3C가 HTML5 권고안을 공개한 건 2014년 10월 28일 당시 권고안 공개는 지난 1999
년 HTML 4.01 이후 15년 만의 일이었다. HTML 4.01 당시에는 웹 응용 프로그램 등이
고려되지 않았고 웹 페이지를 기술하기 위한 포맷이었던 만큼 전면 개정됐다.
이번에 권고안을 공개한 HTML5.1은 원래 HTML5의 일부였던 규격이다. 하지만 모든
기능에 대한 버그 문제 해소를 목표로 했던 2014년 권고안이 늦어질 수 있다는 우려로
2012년 9월 플랜 2014가 제안됐다.
이 계획은 당시 안정화된 부분만 HTML5.0으로, 해결해야 할 문제가 있던 부분은 HTML5.1로
분할한다는 것이다. 이에 따라 HTML5.0을 2014년에 권고한 것이다. 또 HTML5.1은 2016
년 권고한다는 내용도 담고 있었다. 이런 계획에 따라 HTML5.1은 예정대로 11월에 권고
안으로 공개된 것이다.
HTML5.1 책정 작업은 2015년 말까지 HTML 워킹그룹이 진행했지만 웹 플랫폼 관련 분
야에 인계되면서 일정에 맞추기 위해 기술 사양을 깃허브에 공개했다. W3C 측은 HTML
포맷 안정화를 1년에 1번 권고안으로 공개할 수 있는 워크플로 개발을 목표로 한다고
밝히고 있으며 지금은 HTML5.2 책정 작업을 진행하고 있다.
4.1 HTML5 vs HTML5.1
HTML5.1의 스펙의 최근 표준화, 핵심 어휘와 기능은 HTML5와 비교하여 5가지 차이
점을 두고 확장을 했다.
- 원래 HTML5 사양에서 제거된 모듈은 개별적으로 표준화하기로 했다.
(Microdata 또는 Canvas와 같은 HTML5 ApIs)
- 다수 개 국어의 마크업 같은 HTML5 확장성으로써 HTML5.1은 소개되었다.
- HTML5 확장성 또는 SVG와 같은 특징처럼 HTML5.1은 별도의 사양으로 적용되었다.
- HTML5.1, HTML5.2 등 앞으로의 사양
(HTML5의 표준화를 최소화한 특정 기능개선)
- 구현의 부족함을 제거
(브라우저는 사용자의 키보드 인식, 포커스 탐색 고정, 누락된 이벤트를 추가)
- 209 -
4.2 HTML5.1 spec
HTML5.1 스펙 개발 작업은 주로 새로운 API나 이벤트 등 새로운 기능을 추가하는 작
업, 기존의 표준 내용을 수정하거나 실제 활용성이 떨어지는 기능은 삭제하는 방식으로
진행되고 있다.
2016년에 HTML5.1에서 구체적으로 정리된 내용들을 보면 Accesskey 속성 같은 단일
문자만 허용하도록 수정되었고, 패치(Fetch) 또는 로딩 알고리즘에서 필요 시 미디어 요
소(Media Element)에서 미디어 소스(Media Source)를 분리시키는 기능이 추가되었다.
또한 2013년에 HTML5 스펙에서 분리된 마이크로데이터(Microdata) 관련 속성이 제거
되었고, WHATWG(Web Hypertext Application Technology Working Group)와 조율 작업
을 하고, 표준 추가의 장점이 없다고 생각하여 <iframe>에서의 seamless 속성 및 테이블
정렬 모델을 스펙에서 삭제하였다.
또한, <figure> 엘리먼트 내에서 <figcaption>의 위치가 어디든 표현 가능하도록 수정
하였고, 보안 이슈 및 사용률이 낮은 <isindex>를 삭제하였다.
4.3 HTML5.1 한계
먼저 웹 기술 변화에 아주 큰 변화와 혁신이 일어나고 있는데 반해 웹 표준화 프로세
스는 여전히 과거의 프로세스를 그대로 답습하고 있어서 빠른 변화를 능동적으로 수용
하기에 한계가 있다. (물론 W3C가 메일링리스트 외부 개방, 표준 문서 소스 컨트롤 활
용, 커뮤니티 그룹으로 참여 확대 등 표준 제정 단계에 많은 변화를 받아들이는 점은
고무적이다.)
이에 따라 HTML5의 표준 에디터였던 이안 힉슨이 지난 4월부터 표준안 혁신을 지속
하려면 표준안 자체가 소프트웨어 개발 방식 같은 변화가 따라야 한다고 강조하면서 새
로운 표준 개발 협업 방식을 제안했다.
요컨대 2004년부터 2006년까지 W3C 이전에 HTML5 표준안 작업을 한 후, W3C에 제
출했던 WHATWG라는 표준 커뮤니티가 있다. W3C HTML W/G가 만들어진 후에도 활동
이 계속됐으나 이들 기능들이 빠르게 W3C 내부로 전달되어 포함되지 못했다.
따라서, WHATWG에서 HTML의 개발 버전(Living HTML이라고도 명명하고 소스 개발
상의 Trunk에 해당하는)을 담당하고, W3C가 외부 작업과 내부 작업을 병합해서 주기적
으로 표준안 스냅샷을 내놓는(일종의 Branch 버전) 방법을 제안해야 한다.
- 210 -
4.4 기능소개
가. 추가된 기능
a. <picture> 와 srcset 속성은 반응형 이미지 선택을 허락한다.
이미지 사이즈의 크기가 고정됐을 때 선택하는 디바이스 픽셀 비 기반 img 요소의 src
및 srcset 속성은 크기가 다른 여러 이미지를 제공하기 위해 x 기술이 사용된다.
뷰포트 기반 선택은 srcset 및 sizes 속성은 크기가 다른 여러 이미지를 제공하기 위해
w 기술이 사용된다.
예술 방향 기반의 선택은 <picture>요소와 <source>소자는 media 속성과 함께 이미지 내
용을 다르게 하는 다수의 이미지를 제공하는데 사용된다.
(작은 이미지는 큰 이미지를 잘라낸 버전)
<h1>
<img sizes="100vw" srcset="wolf-400.jpg 400w, wolf-800.jpg 800w, wolf-1600.jpg 1600w" src="wolf-400.jpg" alt="The rad wolf">
</h1>
<img sizes="(max-width: 30em) 100vw, (max-width: 50em) 50vw, calc(33vw - 100px)"
srcset="swing-200.jpg 200w, swing-400.jpg 400w, swing-800.jpg 800w, swing-1600.jpg 1600w"
src="swing-400.jpg" alt="Kettlebell Swing">
<picture>
<source media="(min-width: 45em)" srcset="large.jpg">
<source media="(min-width: 32em)" srcset="med.jpg">
<img src="small.jpg" alt="The wolf runs through the snow.">
</picture>
- 211 -
이미지 포맷에 기반을 둔 선택은 <source>요소의 type 속성 다른 형식의 여러 개의 이
미지를 제공하기 위해 사용된다.
b. <details> 및 <summary> 속성은 사용자가 읽을 여부를 선택할 수 있는
확장된 정보를 제공하기 위해 사용된다.
<details> 속성이 진행 보고서에서 기술적인 세부 사항을 숨기는 데 사용된다.
<h2>From today’s featured article</h2>
<picture>
<source srcset="/uploads/100-marie-lloyd.webp" type="image/webp">
<source srcset="/uploads/100-marie-lloyd.jxr" type="image/vnd.ms-photo">
<img src="/uploads/100-marie-lloyd.jpg" alt="" width="100" height="150">
</picture>
<p><b><a href="/wiki/Marie_Lloyd">Marie Lloyd</a></b> (1870–1922)
was an English <a href="/wiki/Music_hall">music hall</a> singer, ...
<section class="progress window">
<h1>Copying "Really Achieving Your Childhood Dreams"</h1>
<details>
<summary>Copying...
<progress max="375505392" value="97543282"></progress> 25%</summary>
<dl>
<dt>Transfer rate:</dt> <dd>452KB/s</dd>
<dt>Local filename:</dt> <dd>/home/rpausch/raycd.m4v</dd>
<dt>Remote filename:</dt>
<dd>/var/www/lectures/raycd.m4v</dd>
<dt>Duration:</dt>
<dd>01:16:27</dd>
<dt>Color profile:</dt>
<dd>SD (6-1-6)</dd>
<dt>Dimensions:</dt>
- 212 -
이번 항목은 세부 항목 요소가 기본적으로 일부 컨트롤을 숨기기 위해 사용하는 방법을
보여준다.
c. <menuitem>및 type="context"속성은 사용자가 브라우저의 컨텍스트 메뉴에
기능을 값에 추가할 수 있도록 한다.
사용자가 가진 요소를 마우스 오른쪽 버튼으로 클릭하면 contextmenu 속성, 사용자
에이전트가 먼저 발생한다.
<details>
<summary><label for=fn>Name & Extension:</label></summary>
<p><input type=text id=fn name=fn value="Pillar Magazine.pdf"> <p><label><input type=checkbox name=ext checked> Hide extension</label>
</details>
<dd>320×240</dd>
</dl>
</details>
</section>
<form name="npc">
<label>Character name: <input name=char type=text contextmenu=namemenu required></label>
<menu type=context id=namemenu>
<menuitem label="Pick random name" onclick="document.forms.npc.elements.char.value = getRandomName()"> <menuitem label="Prefill other fields based on name" onclick="prefillFields(document.forms.npc.elements.char.value)">
</menu>
</form>
<details>
- 213 -
고양이의 이미지는 네 가지 명령 컨텍스트 메뉴가 주어진다.
d. requestAnimationFrame API는 보다 효율적인 애니메이션을 할 수 있다.
requestAnimationFrame 설명은 각 문서는 처음에 비어 있어야 하고 애니메이션 프레임
콜백 식별자인 최상위 레벨의 browsing context와 관련되어있다.
이 애니메이션 프레임은 CallBack 목록 초기에 숫자 0이어야 한다.
requestAnimationFrame 메서드 설명은 requestAnimationFrame( ) 메서드가 호출될 때,
사용자 에이전트는 다음 단계를 실행해야 한다.
① 윈도우 객체의 문서 객체를 문서화 시켜야 한다.
② 문서의 애니메이션 프레임 콜백 식별자를 1씩 증가시켜야 한다.
③ 메소드 인수를 문서의 애니메이션 프레임 콜백 식별자의 현재 값과 연관된
애니메이션 프레임 콜백 목록의 문서에 추가한다.
④ 문서의 애니메이션 프레임 콜백 식별자의 현재 값을 반환합니다.
<img src="cats.jpeg" alt="Cats" contextmenu=catsmenu>
<menu type="context" id="catsmenu">
<menuitem label="Pet the kittens" onclick="kittens.pet()">
<menuitem label="Cuddle with the kittens" onclick="kittens.cuddle()">
<menu label="Feed the kittens">
<menuitem label="Fish" onclick="kittens.feed(fish)">
<menuitem label="Chicken" onclick="kittens.feed(chicken)">
</menu>
</menu>
- 214 -
e. enqueueJob 및 nextJob은 마이크로 태스킹 관점에서 약속된 해결책을
설명하는데 도움을 준다.
enqueueJob 설명 (queueName, job, arguments)은 자바 스크립트 사양이 EnqueueJob 추
상적 동작 호출할 때, 다음의 알고리즘은 자바 스크립트의 EnqueueJob 환경에서 사용되
어야 한다.
enqueueJob 추가 설명 사진
f. 링크에 대한 rev 속성은, 주로 RDFa를 지원한다. (이전 HTML 4에 정의)
g. HTMLMediaElement와 srcObject 객체들
HTMLMediaElement 설명은 HTMLMediaElement 객체(이 규격에서의 <audio> 및 <video>)
는 단순히 미디어 요소로 알려져 있다.
① Assert: queueName is "PromiseJobs". ("ScriptJobs" must not be used by user agents.)
② 세팅 객체의 작업이 [[Realm]]이 되게 한다.
③ 이벤트 루프 응답 세팅의 Queue a microtask는 다음 절차를 수행해야 한다.
- 스크립트를 실행시킬 수 있는 세팅인지 확인해야 한다. 만약 실행이 되지 않는다면
중단해야 한다.
- 스크립트를 다시 실행시키기 위한 세팅을 준비해야 한다.
- 인수의 요소를 사용하는 단계에 의해 지정된 추상 작업을 수행한 결과를 만들어야 한다.
- 세팅한 스크립트를 실행 후 클린 시켜야 한다.
- 결과가 갑자기 나오면 그 결과에 의해 표시된 Exception을 보고해야 한다.
A link with a rev attribute:<a rev="nofollow" href="http://www.functravel.com/" >Cheep Flights</a>
- 215 -
h. 교차 출처 track 및 EventSource 및 <canvas>에서 ImageBitmap 위한
교차 출처 콘텐츠 활성화
canvas 요소는 실시간으로 그래프, 게임 그래픽, 예술, 또는 다른 시각적 이미지를 렌더
링 하는 데 사용할 수 있고 해상도에 의존 비트 맵 캔버스와 스크립트를 제공한다.
track IDL 속성은 <track> 요소의 텍스트 트랙에 상응하는 해당 TextTrack 객체를 반환
해야 한다.
src, srclang, label, 및 default IDL 속성들은 있어야 특성을 반영하는 같은 이름의 각각
의 콘텐츠 특성을 반영한다.
이러한 종류 IDL 속성은 알려진 값에 한정된 동일한 이름의 콘텐츠 속성을 반영한다.
<section id="video">
<p><a href="playing-cats.nfv">Download video</a></p>
</section>
<script>
var videoSection = document.getElementById('video');
var videoElement = document.createElement('video');
var support = videoElement.canPlayType('video/x-new-fictional-format;codecs="kittens,bunnies"'); if (support != "probably" && "New Fictional Video Plugin" in navigator.plugins)
{ // not confident of browser support // but we have a plugin // so use plugin instead videoElement = document.createElement("embed");
} else if (support == "") { // no support from browser and no plugin // do nothing videoElement = null; }
if (videoElement) {
예를 들어,
값 "image/png의" PNG 화상을 생성하는 것을 의미한다,
값 "image/jpeg의" JPEG 화상을 생성하는 것을 의미한다,
"image/svg+xml" 값은 SVG 이미지 생성을 의미한다.
(이것은 일반적이지 않는 좋은 기능으로써 사용자 에이전트 트랙이 어떻게 비트맵을 추
적할지를 요구한다. )
- 216 -
i. event-source-error, event-track-error 및 event-track-load 미디어 피칭
에 대한 이벤트
j. onrejectionhandled 및 onunhandledrejection 그리고 거부된 약속을 위한 APIs
Unhandled promise rejections 설명은 동기 런타임 스크립트 오류 이외에 unhandledrejec
tion 및 rejectionhandled 이벤트를 통해 추적된 경우 스크립트는 비동기 약속 거부가 발
생할 수 있다.
Unhandled promise rejections 절차
while (videoSection.hasChildNodes())videoSection.removeChild(videoSection.firstChild); videoElement.setAttribute("src", "playing-cats.nfv"); videoSection.appendChild(videoElement);
}
</script>
<video src="brave.webm">
<track kind=subtitles src=brave.en.vtt srclang=en label="English">
<track kind=captions src=brave.en.hoh.vtt srclang=en label="English for the Hard of Hearing">
<track kind=subtitles src=brave.fr.vtt srclang=fr lang=fr label="Français">
<track kind=subtitles src=brave.de.vtt srclang=de lang=de label="Deutsch">
</video>
동기 런타임 스크립트 오류 외에도, 스크립트는 처리되지 않은 거부 및 거부당한 이벤트를 통해 추적된 비동기식 약속 거부를 경험할 수 있다.
사용자 에이전트가 주어진 환경 설정 객체 설정 객체에서 거부 된 약속에 대해 통지할 때, 다음 절차대로 수행되어야 한다.
① 거부된 약속 목록들을 통보하는 세팅 객체들의 복사 리스트를 만들어야 한다.
② 만약 리스트가 비어 있다면, 다음 절차를 실행해야 한다.
③ 거부된 약속 목록들을 통보하는 세팅 객체들을 클린 시켜야 한다.
- 217 -
k. HTMLTableCaptionElement, HTMLTableSectionElement, HTMLTableRowElement,
HTML 테이블 요소.
HTMLTableCaptionElement은 만약 <caption> 속성이 부모를 가지고 있고 <table> 요소 면은
<caption>요소는 부모 테이블의 제목을 나타낸다. <caption>요소는 테이블 모델의 일부분이다.
<table> 요소가 <figure>요소 외에 <figcatpion> 요소를 포함하고 있을 때, <catpion> 요소
는 <figrcatpion> 요소의 종류로 생략되어야 한다.
<caption>
<p>Table 1.
<p>This table shows the total score obtained from rolling twosix-sided dice. The first row represents the value of the first die,the first column the value of the second die. The total is given inthe cell that corresponds to the values of the two dice.
</caption>
1 2 3 4 5 61 2 3 4 5 6 72 3 4 5 6 7 83 4 5 6 7 8 94 5 6 7 8 9 105 6 7 8 9 10 11
④ 다음 하위 단계를 실행하는 작업을 대기 열에 넣는다.
- 만약 p’s [[PromiseIsHandled]] 내부 슬롯이 사실이면, 루프의 다음 반복을 계속 수행해야 한다.
- 정렬되진 않지만 취소 가능한 새로운 신뢰할 수 있는 PromiseRejectionEvent 객체로 이벤트를 보낸다, 그러면 이벤트 이름에 처리되지 않은 응답들이 있을 것이다.
- 이벤트의 promise 속성을 p로 초기화해야 한다.
- 이벤트의 reason 속성을 p [[PromiseResult]] 내부 슬롯의 값으로 초기화해야 한다.
- 설정 개체의 전역 개체에서 이벤트를 보낸다.
- 이벤트가 취소된 경우 약속 거부가 처리되고, 그렇지 않으면 약속 거부가 처리되지 않는다.
- p [[PromiseIsHandled]] 내부 슬롯이 false인 경우 설정 개체의 미해결 거부 약속 약점 세트에 p를 추가한다.
- 218 -
HTMLTableSectionElement의 <section>속성은 간략한 설명을 제공하는 aria-lable 속성을 가
지고 있다. 보조 기술들은 유저들의 힌트로써 aria-label 값과 함께 region 역할을 전달할 수 있다.
l. history.scrollRestoration은 그들의 역사를 탐색할 때 사용자의 뷰 방향 위치를
제어할 수 있다.
<head>
<script>
if ('scrollRestoration' in history)
history.scrollRestoration = 'manual';
</script>
</head>
<article>
<header>
<h2>Apples</h2>
<p>Tasty, delicious fruit!</p>
</header>
<p>The apple is the pomaceous fruit of the apple tree.</p>
<section aria-label="Red apples.">
<h3>Red Delicious</h3>
<p>These bright red apples are the most common found in many supermarkets.</p>
</section>
<section aria-label="Green apples.">
<h3>Granny Smith</h3>
<p>These juicy, green apples make a great filling for apple pies.</p>
</section>
</article>
- 219 -
m. 컬렉션을 반환하는 일부 개체에 대한 IDL [SameObject]
n. 브라우징 컨텍스트는 분리 될 수 있도록 rel와 window에 noopener를 추
가하는 것을 허락한다.
[Unforgeable]
interface Location {
stringifier attribute USVString href;
readonly attribute USVString origin;
attribute USVString protocol;
attribute USVString host;
attribute USVString hostname;
attribute USVString port;
attribute USVString pathname;
attribute USVString search;
attribute USVString hash;
void assign(USVString url);
void replace(USVString url);
void reload(); [SameObject] readonly attribute USVString[] ancestorOrigins;};
interface HTMLScriptElement : HTMLElement {
attribute DOMString src;
attribute DOMString type;
attribute DOMString charset;
attribute boolean async;
attribute boolean defer;
attribute DOMString? crossOrigin;
attribute DOMString text; attribute DOMString nonce;};
- 220 -
o. 콘텐츠 보안 정책의 사용을 지원하기 위해 <script>및 <style>에 nonce 속성 추가
나. 제거된 기능
- appCache
- 미디어 컨트롤러
- commandAPI.
- <object>에 usemap 속성
- accessKeyLabel IDL 속성
- form 속성은 더 이상 <label> 태그에 유효하지 않다.
- input type="range"에서 multiple 속성
- <area>에서 hreflang과 type에 속성
- <section> 요소로 각각의 윤곽을 만들 수 있는 <h1> 중첩의 사용한다.
- form submission에서 특별 취급의 isindex
- navigator.yieldForStorageUpdates() 와 the Storage mutex.
- tbody 하기 전에 tfoot 사용을 금지한다.
- HTMLHyperLinkElementUtils 위한 [Exposed=Window], DOMStringMap 위한
[Exposed=Window, Worker] 그리고 IDL Date
다. 변경된 기능
- accesskey는 하나의 문자 값으로 가져온다.(HTML 4처럼)
- 각각의 레벨이 섹션 요소 내에 있으면 <header> 및 <footer> 요소는 중첩 될
수 있다.
- <option> 요소는 비어있을 수 있다.
- mousewheel 이벤트는 wheel로 부른다.
- 221 -
- input type="submit" 속성의 값은 변경될 수 있다.
- <figcaption> 태그는 <figure> 태그 내에서 어디서나 나타낼 수 있다
- 제목을 갖고 있거나 또는 친구에게 이메일을 작성하는 alt 속성이 없는 <img>
태그를 만들지 않는다.
- <time> 콘텐츠는 내용 또는 텍스트를 분할한다.
- 중복된 href 속성을 가진 area 요소에 빈 alt은 더 이상 준수하지 않는다.
- 내부적으로 탐색할 때, 링크 등을 위한 다음 검색은 내비게이션에 이동한 곳
에서 시작된다.
- <img> 와 관련된 요소는 width="0"를 지원한다
- .tFoot 그리고 .createTFoot()은 항상 테이블의 끝에 삽입해야 한다
- fieldset와 namedItem는 HTMLFormControlsCollections와 HTMLOptionsCollectio
ns도 아닌 HTMLCollections를 만든다.
- frameElement null 값을 반환할 수 있다
- 해결자에게 주어진 URL currentSrc가 해결되지 않은 이미지는 절대적으로 필
요로 하지 않는다.
- script IDL 속성을 반영한다.
- meta refresh는 ‘;’또는 ‘url=’ 이 선택적일 수 있도록 허락한다.
- navigator.javaEnabled()는 함수이다.
- fileCallback은 blobcallback라고 부른다.
- toBlob()은 null 입력이 가능하다.
- HTMLHyperlinkElementUtils와 Location 본원은 읽기 전용이다.
- titleSVG의 첫 번째 자식 제목은 마지막이 아닌 그것의 제목이다.
- window.open()은 null로 반환 할 수 있다.
Ⅶ．부록
- 225 -
Ⅶ. 부록
1. 용어집
자바스크립트(JavaScript)
미국의 넷스케이프 커뮤니케이션즈 사(Netscape Communications)가 개발한 스크립트 언어. 1996년 2월에 발매한 월드 와이드 웹(WWW) 브라우저인 넷스케이프 내비게이터(Netscape Navigator) 2.0에 실장하였다. 브라우저에서 실행하는 스크립트 언어를 기술한다. 언어 규격은 자바의 부분 집합(subset)으로 되어 있다. 하이퍼텍스트 생성 언어(HTML) 문서를 작성하는 수준의 이용자가 사용하는 것을 주안점으로 하여 자바의 언어 규격으로부터 변수의 형(정수형이나 문자열형 등)을 생략하거나 새로운 클래스 정의를 할 수 없도록 하였다. 스크립트는 HTML 문서 속에 직접 기술하며, ‘script’라는 꼬리표를 사용한다.
액티브X (ActiveX)
윈도 이용자들이 인터넷을 편리하고 쉽게 이용하도록 MS에서 개발한 것으로, 기존의 응용 프로그램으로 작성된 문서 등을 웹과 연결시켜 그대로 사용할 수 있게 하는 기술. 인터넷 익스플로러를 위해 고안되었으며, 실생활 페이지에 접속하면 자동으로 내려받기 되어 설치된다. 선 마이크로시스템즈사의 자바(Java) 기술에 대항하는 기술이다.
플래시 (Flash)어도비사에서 개발되었으며 액션 스크립트와 모션 그래픽을 이용하여 PC용, 웹 용 모듈을 작성할 수 있는 도구이다.
이용자 에이전트(User-agent)
HTTP 요청 시 HTTP 헤더에 넣어 전송하는 문자열로 브라우저에서는 브라우저 이름, 버전정보 등이 포함된다. 각 브라우저 , 검색로봇 마다 다른 문자열이 포함된다.
하이퍼텍스트 전송 규약(HTTP)
인터넷의 월드 와이드 웹(WWW) 서버와 WWW 브라우저가 파일 등의 정보를 송수신하는데 사용되는 클라이언트/서버 규약. WWW 브라우저의 화면상에서 URL(uniform resource locator)를 지정하는 데 사용된다. 예를 들면 ‘http://www.snu. ac.kr/index.html’과 같이 ‘http://’로 시작되는 URL을 지정하면, 여기에 있는 데이터를 하이퍼텍스트 전송 규약(HTTP)을 사용하여 서버에서 브라우저로 전송한다.
XMLHttpRequest브라우저에서 XML을 요청할 수 있도록 하는 내장객체로 자바스크립트로 제어가 가능하여 동적인 웹페이지를 만드는데 사용된다.
암호수출제한정책(Encr 미국 정부에서 전통적으로 강력한 암호에 대해서 강력한 통제를
- 226 -
yption Export Controls)
지속해왔다. 1996년부터 비군사적인 항목에 대해서 조금씩 완화되기 시작하여 여러 차례의 관련 규제조항의 수정을 거쳐서 적대국가가 아닌 나라에 대해서는 2001년까지 대부분 완화 되었다.
중간자공격(Man in the Middle Attack,
MITM)네트워크 통신을 중간에서 조작하여 도청하거나 변경하는 공격
HTML5(HyperText Markup
Language 5)
HTML의 차기 주요 제안 버전으로 W3C에서 표준을 제정하고 있는 핵심 마크업 언어. 2007년 초기 리뷰 기반으로 시작하여 2014년 4 분기 표준 권고안(Recommendation)을 목표로 하고 있으며, 다양한 서비스를 지원하기 위한 규격들이 추가되고 있다.
웹 애플리케이션자바스크립트(JavaScript), HTML, CSS등 Web 기반 언어로 개발된 응용 프로그램에서 클라이언트로 브라우저나 웹 런타임을 사용하는 모든 응용 프로그램이다.
자바스크립트 API
자바스크립트와 같은 인터페이스 정의 언어(IDL)를 사용하여 정의된 웹 애플리케이션을 위한 프로그램 인터페이스. 일반적으로 디바이스 기능(device capabilities)에 대한 접근을 위해 웹 애플리케이션을 실행하기 위한 수단으로써 제공된다.
CSS(Cascading Style Sheets)
웹 문서의 전반적인 스타일을 미리 저장해 두는 기술로 월드 와이드 웹 컨소시엄(W3C)에서 표준화한 하이퍼텍스트 생성 언어(HTML)용 스타일 시트. HTML을 이용해서 웹 페이지를 개발할 경우 전반적인 틀에서 세세한 글꼴을 일일이 지정해 주어야 하지만, 웹 페이지의 스타일을 미리 저장해 두면 웹 페이지의 한 가지 요소만 변경해도 관련되는 전체 페이지의 내용이 한꺼번에 변경되므로, 문서 전체의 일관성을 유지할 수 있고 작업 시간도 단축된다. 하나의 스타일을 정의하면 여러 개의 문서에서 사용할 수 있으며 수정이 쉽다
DOM(Document Object Model)
문서 형식 선언(DTD : Document Type Declaration) 또는 DOCTYPE이란 어떤 SGML이나 XML 기반 문서 내에 그 문서가 특정 문서 형식 정의(Document Type Definition)를 따르는 것을 지정하는 것이다. 본래 DTD에 기반한 SGML 도구를 이용해 문서 해석 가능성과 유효성을 검사하기 위한 목적으로 문서 내에 삽입된다.
SEED1999년 한국정보보호진흥원에서 개발한 대칭키 블록 암호 알고리즘. 128bit로 표준화 되었고 256bit까지 있다.
Site Key이용자가 이미 등록해 놓은 정보를 통하여 웹에서 이용자 사이에 상호 인증하는 방식. 피싱 방지 목적으로 사용 됨
CAPTCHA자동화된 입력인지 사람이 입력하는지를 식별하기 위한 방법. 임의의 숫자나 문자를 컴퓨터가 알아보기 어렵게 하여 표시한 후 이에 대한 값을 입력하도록 요청하는 방식. 때로는 사람도 알아보기 어렵다.
- 227 -
2. 약어집
AA Amount AuthenticationAPI Application Program InterfaceARS Advanced Record System
CAPTCHA Completely Automated Public Turing test to tell Computers and Humans ApartCORS Cross-Origin Resource SharingCMP Certificate Management ProtocolCMS Content Management SystemCSR Certificate Signing Request
DDoS Distributed Denial of Service attackDTD Document Type Definition
ECMA European Computer Manufacturers AssociationFDS Fraud Detection SystemEME Encrypted Media ExtensionsHTTP Hyper Text Transfer ProtocolHTTPS Hypertext Transfer Protocol over Secure Socket LayerIDL Interface Definition LanguageHSM Hardware security moduleISP Internet Secure PaymentISO International Organization for Standardization
JSON JavaScript Object NotationMPEG Moving Picture Experts GroupNPAPI Netscape Plugin Application Programming InterfaceOTP OneTime PasswordOS Operating System
OWASP The Open Web Application Security ProjectPCIDSS Payment Card Industry Data Security Standard
PKI Public Key InfrastructureRDP Remote Desktop ProtocolRFB Remote Frame BufferTCP Transmission Control ProtocolTLS Transport Layer SecurityTTP Trusted Third PartyURL Uniform Resource LocatorURI Uniform Resource IdentifierSEED 128-bit Symmetric Block CipherSSL Secure Socket LayerVNC Virtual Network ComputingVPN Virtual Private NetworkW3C World Wide Web ConsortiumXBL XML Binding Language
XHTML eXtensible HyperText Markup Language
- 228 -
3. 참고자료 및 인용
[웹 기술]
1. 웹 표준 진단도구
http://www.koreahtml5.kr
2. W3C HTML5 표준
W3C, HTML5, http://www.w3.org/TR/html5/, 2014
3. w3school.com
http://www.w3schools.com/
4. New Tricks in XMLHttpRequest2(Eric Bidelman)
http://www.html5rocks.com/en/tutorials/file/xhr2/?redirect_from_locale=ko
5. Internet Explorer 호환성 도움말
https://msdn.microsoft.com/ko-kr/library/dn384059(v=vs.85).aspx
6. 브라우저 HTML5 지원 확인
http://caniuse.com/
7. 네이버 개발자 블로그 - 브라우저는 어떻게 동작하는가
http://d2.naver.com/helloworld/59361
8. Rendering: repaint, reflow/relayout, restyle
http://www.phpied.com/rendering-repaint-reflowrelayout-restyle/
9. How (not) to trigger a layout in Webkit
http://gent.ilcore.com/2011/03/how-not-to-trigger-layout-in-webkit.html
10. 프론트엔드 개발자를 위한 렌더링 성능 인자 이해하기
http://cwdoh.com/workshop/2014/06/14/understanding-rendering-performance-matters-in-chrome/
11. W3C CSS3 MediaQuery
http://www.w3.org/TR/css3-mediaqueries/
12. W3C Drag&Drop
W3C, HTML5, Drag and Drop, http://www.w3.org/TR/html5/editing.html#dnd, 2014
13. W3C FileAPI
W3C, File API, http://www.w3.org/TR/FileAPI/. 2013
14. W3C FileWriter
W3C, File API: Writer, http://www.w3.org/TR/file-writer-api/, 2014
15. W3C IndexedDB
W3C, Indexed Database API, http://www.w3.org/TR/IndexedDB/, 2013
- 229 -
16. W3C WebMessage
W3C, HTML5 Web Messaging, http://www.w3.org/TR/webmessaging/, 2012
17. W3C Web RTC
W3C, WebRTC 1.0, http://www.w3.org/TR/webrtc/, 2013
18. W3C WebStorage
W3C, Web Storage, http://www.w3.org/TR/webstorage/, 2013
19. W3C XHR
W3C, XMLHttpRequest Level 1, http://www.w3.org/TR/XMLHttpRequest/, 2014
20. W3C XHR2
W3C, XMLHttpRequest Level 2, http://www.w3.org/TR/XMLHttpRequest2/, 2014
21. Bootstrap
http://getbootstrap.com/
22. jsPDF / pdf.js
https://github.com/MrRio/jsPDF
https://mozillalabs.com/en-US/pdfjs
23. MSXML 사용 방법
http://blogs.msdn.com/b/xmlteam/archive/2006/10/23/using-the-right-version-of-msxml-
in-internet-explorer.aspx
24. XML 파서 사용 방법(libxml2)
http://xmlsoft.org/
25. HTML5 Video Player 비교
http://praegnanz.de/html5video
26. Top 10 Best HTML5 Audio Players
http://www.scratchinginfo.net/top-10-best-html5-audio-players
27. HTML5rocks- 크롬의 렌더링 가속: 레이어 모델
http://www.html5rocks.com/ko/tutorials/speed/layers/
28. Google검색- GPU Accelarated Compositing in Chrome
http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome
29. HTML5rocks- Scrolling Performance
http://www.html5rocks.com/en/tutorials/speed/scrolling/?redirect_from_locale=ko
30. HTML5rocks- Jank Busting for Better Rendering Performance
http://www.html5rocks.com/en/tutorials/speed/rendering/?redirect_from_locale=ko
31. HTML5rocks- CSS 페인트 타임과 페이지 렌더 가중치
http://www.html5rocks.com/ko/tutorials/speed/css-paint-times/
- 230 -
32. HTML5rocks- 불필요한 페인팅 회피하기
http://www.html5rocks.com/ko/tutorials/speed/unnecessary-paints/
33. HTML5rocks- 불필요한 페인팅 회피하기: Animated GIF버전
http://www.html5rocks.com/ko/tutorials/speed/animated-gifs/
34. HTML5rocks- 고성능 애니메이션
http://www.html5rocks.com/ko/tutorials/speed/high-performance-animations/
35. Getting Started with WebRTC
http://www.html5rocks.com/ko/tutorials/webrtc/basics/
36. Saying Goodbye to Our Old Friend NPAPI
http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
37. W3C Standards for Web Applications on Mobile: current state and roadmap
http://www.w3.org/Mobile/mobile-web-app-state/
38. 공개 프레임워크와 라이브러리, 툴 기술 자료
http://webframeworks.kr
[보안]
39. TLS Cipher Suite Registry
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
40. OWASP HTML5 Security Cheat Sheet
https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet
41. 보안서버보급지원 정보 사이트
http://opa.or.kr/Business-secureserver_support.do
42. SSL 테스팅 툴
https://www.ssllabs.com/ssltest/
43. FIDO(Fast IDentity Online) Alliance
https://fidoalliance.org/
44. Web Cryptography API
W3C, Web Cryptography API, http://www.w3.org/TR/WebCryptoAPI/
45. CryptoJS
Google, JavaScript implementations of standard and secure cryptographic algorithms,
https://code.google.com/p/crypto-js/, CryptoJS 3.1
46. CSP
W3C, Content Security Policy 1.0, http://www.w3.org/TR/CSP/, 2012
- 231 -
47. CSP2
W3C, Content Security Policy Level 2, http://www.w3.org/TR/CSP2/, 2014
48. 브라우저 Sandbox 보안 모델
W3C,HTML5Sandboxing,http://www.w3.org/TR/html5/browsers.html#sandboxing,2014
49. Keygen
W3C, HTML5 keygen element, http://www.w3.org/TR/html5/forms.html#the- keygen-element, 2014
50. MSRCRYPTO
Microsoft Research, MSR JavaScript Cryptography Library, v1.2, http:// research.mic
rosoft.com/en-us/downloads/29f9385d-da4c-479a-b2ea-2a7bb335d727/, 2014
51. SCJL
Stanford University, Stanford Javascript Crypto Library, http://crypto. stanford.edu/sjcl/, 2009
52. PKCS1
RSA Laboratories PKCS#1, RSA Cryptography Standard v2.1, 2001
53. PKCS5
RSA Laboratories PKCS#5, Pasword-Based Cryptography Standard v2.0, 1999
54. PKCS8
RSA Laboratories PKCS#8, Private-Key Information Syntax Standard, 1993
55. PKCS10
RSA Laboratories PKCS#10, Certification Request Syntax Specification, 2000
56. PKCS11
RSA Laboratories PKCS#1, Cryptographic Token Interface Standard v2.1, 2001
57. PKCS12
RSA Laboratories PKCS#12, Personal Information Exchange Syntax Standard v1.0, 1999
58. RFC2511
IETF, RFC 2511, Internet X.509 Certificate Request Message Format, March 1999
59. RFC4210
IETF, Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP), 2005
60. RFC6454
IETF, The Web Origin Concept, 2011
61. RFC6712
IETF, Internet X.509 Public Key Infrastructure -- HTTP Transfer for the Certificate
Management Protocol (CMP), 2012
62. HTML5 Security Cheatsheet
https://html5sec.org
- 232 -
63. HTML5 Top 10 Threats Stealth Attacks and Silent Exploits
https://media.blackhat.com/bh-eu-12/shah/bh-eu-12-Shah_HTML5_Top_10-WP.pdf
64. 홈페이지 취약점 진단·제거 가이드(정보 보호 시스템 관리)
http://www.kisa.or.kr/public/laws/laws3.jsp
[인증/결제]
65. MPay
https://mpay.lgcns.com:8443/web/getNoticeView.dev
66. 페이팔 개발자 센터
https://developer.paypal.com/
67. e-ID
BSI TR-03112 Das eCard-API-Framework, https://www.bsi.bund.de/DE/ Publikationen/
TechnischeRichtlinien/tr03Au112/index_htm.html, 2014
68. W3C, Web Payments use cases 1.0
http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150730/
69. Wiki, Multi-factor authentication
https://en.wikipedia.org/wiki/Multi-factor_authentication
70. OASIS, OASIS Security Services (SAML)
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security
71. OAuth
http://d2.naver.com/helloworld/24942
https://developers.google.com/youtube/v3/guides/authentication?hl=ko
[MS IE, Edge]
72. Edge 개발자 사이트
https://dev.modern.ie/
73. Microsoft Edge 호환성 확보
http://event.ndeavor.co.kr/2015/edge_seminar/Windows10_edge_seminar.pdf
74. Microsoft 윈도우 드라이버 코드 사이닝 실용 가이드
http://heejune.me/2015/07/14/
75. Internet Explorer Support Lifecycle Policy FAQ
https://support.microsoft.com/en-us/gp/microsoft-internet-explorer
인터넷 이용환경 개선 기술 안내서(2016년 개정판)
인 쇄 ┃ 2016년 12월
발 행 ┃ 2016년 12월
발 행 인 ┃ 백기승
발 행 처 ┃ 한국인터넷진흥원(KISA, Korea Internet&Security Agency) 서울시 송파구
중대로 135 (가락동) IT벤처타워 Tel: (02) 405-6637
인 쇄 처 ┃ (주)웹소울랩
<비매품>
1. 본 안내서는 미래창조과학부의 출연금으로 수행한 “HTML5 기술지원”사업의 결과입니다.
2. 본 안내서의 내용을 발표할 때에는 반드시 한국인터넷진흥원 “HTML5 기술지원” 사업의
결과임을 밝혀야 합니다.
3. 본 안내서의 판권은 한국인터넷진흥원이 소유하고 있으며, 당 진흥원의 허가 없이 무단 전재
및 복사를 금합니다.
![시맨틱 웹 응용을 위한 웹 온톨로지 구축기법Logic)[4]와 규칙 언어(Rule Language) [5,6]를 기반으로 시 맨틱 웹과 웹 온톨로지의 특징을 만족하는](https://img.pdfslide.tips/doc/110x75/5e60ee872833913b0a55fadb/oee-oeoe-eoe-eee-logic4-eoe.jpg)
