margalog

일본은 ActiveX를 사용하지 않는다.

http://bizenjoy.tistory.com/219

지금 소개하는 방법은 서버에 txt파일을 CGI프로그램의 도움이 없이도 항상 동적으로 불러서 화면에 출력해주는 Active X의 활용방법입니다. 즉, 웹서버측에 다음과 같은 table_list.txt 파일이 있고, 이를 자동으로 테이블로 구성하여 보여줍니다.

table_list.txt 파일의 구성내용은 아래와 같습니다.

no,성별,이름,나이,주소,전화번호
1,남,홍길동,30,광주광역시 동구,062-444-1111
2,여,유관순,32,전라남도 여수시,061-777-7777
3,남,이순신,45,서울특별시 강남구,02-111-0000
4,여,심청이,23,서울특별시 동작구,011-600-0000
5,남,심봉사,55,경상남도 마산시,016-555-0000
6,남,대통령,77,강원도 춘천시,011-000-0000

NO.	성별	이름	나이	주소	전화번호
1	남	홍길동	30	광주광역시 동구	062-444-1111
2	여	유관순	32	전라남도 여수시	061-777-7777
3	남	이순신	45	서울특별시 강남구	02-111-0000
4	여	심청이	23	서울특별시 동작구	011-600-0000
5	남	심봉사	55	경상남도 마산시	016-555-0000
6	남	대통령	77	강원도 춘천시	011-000-0000

<object classid="clsid:333C7BC4-460F-11D0-BC04-0080C7055A83" width="1" height="1" id="clist" border="0">
<param name="DataURL" value="/SRC/javascript/table_list.txt">
<param name="UseHeader" value="True">
</object>

<center>
<table border=0 cellpadding=3 width=450 cellspacing=1 bgcolor=999999 datasrc="#clist">
<THEAD>
   <tr align=center bgcolor=efefef>
     <td><b>NO.</b></td>
     <td><b>성별</b></td>
     <td><b>이름</b></td>
     <td><b>나이</b></td>
     <td><b>주소</b></td>
     <td><b>전화번호</b></td>
   </tr>
</THEAD>
<TBODY>
   <tr bgcolor=white align=center>
     <td><DIV DATAFLD="no"></DIV></td>
     <td><DIV DATAFLD="성별"></DIV></td>
     <td><DIV DATAFLD="이름"></DIV></td>
     <td><DIV DATAFLD="나이"></DIV></td>
     <td><DIV DATAFLD="주소"></DIV></td>
     <td><DIV DATAFLD="전화번호"></DIV></td>
   </tr>
</TBODY>
</table>

원문 : http://channy.tistory.com/136

지금까지 ActiveX와 공인 인증에 대한 문제에 대해 너무 많은 토론이 있었기 때문에 다들 문제 의식에는 공감을 하고 있을 것이다. (ActiveX에 대한 진실과 거짓말 II 참고)

사 실 이 문제는 꽤 뿌리가 깊다. 수 년 동안 계속되어온 소수 사용자 요구가  법적 소송이라는 방식으로 청구가 되어서야 문제를 인식하게 된 것은 때 늦은 감이 있다.  비 IE와 비 윈도우 사용자에게도 공인 인증을 사용할 수 있도록 해달라는 오픈 웹 활동이 이제는 우리 나라 공인 인증 전반에 대한 새로운 성찰을 요구 할 수 있게 된 것은 무척 기쁜 일이다.

그럼 이것을 해결하기 위한 대안은 무엇일까? 하나씩 살펴 보도록 하자. 현재 제기되는 가장 큰 문제는 아래 두 가지 이다.

• 공인 인증을 위한 ActiveX 기술 사용 문제
• 윈도우 자체 보안 문제

4 년 전만 하더라도 [2]번 문제는 존재하지 않았지만 지금은 키보드 해킹 방지, 스파이웨어 방지 프로그램이 모든 웹 사이트의 기본 사항이 될 정도로 문제가 커져 있다. 이것은 윈도우 OS 자체가 가지는 문제이기 때문에 장기적으로 MS가 계속 풀어가야할 과제이다.

[1]번을 범용 기술로 돌리더라도 [2]번 문제를 제기하는 사람이 많기 때문에 이 두 가지를 함께 살펴 봐야 한다.

[1] 공인 인증을 위한 ActiveX 기술 사용 문제

가 장 큰 문제는 현재 공인 인증 기술이 IE & 윈도우 사용자만 가능하다는 것이다. Firefox & 윈도우도 불가능 하다. 그 이유는 현재 공인 인증 기술이 SSL 기술을 기반으로 두고 있지만, 한국 자체 암호 알고리듬(SEED)을 강제하고 있고, 모든 암호 메시지에 전자 서명을 추가(Digital Signature)하도록 하고 있기 때문에 브라우저 내부 기술을 사용할 수 없다. 이를 위한 해결 방안은 다음과 같다.

(1) 단기- 플랫폼 독립적인 범용 플러그인 기술로 개발
대 표적인 방법이 자바 서명 애플릿이다. 자바 애플릿은 Java VM에서만 구동 되므로 안전하다. 간혹 소스 디컴파일에 대한 문제를 제기하는데 원래 PKI 기술 자체는 암호화를 기반으로 하고 있기 때문에 기본 기능에만 충실히 코드를 짜면 디컴파일 돼도 문제가 되지 않는다. UI상 좀 더 미려하게 하기 위해서는 Flash 기술을 접목해도 된다. 덴마크에서는 이미 간단한 기능이지만 자바 기반 공인인증 처리를 하고 있다.

사실 국내 공인 인증 암호화 규격에는 SEED와 DES가 함께 사용 가능하 다. 단지 보안 심사를 SEED만 하기 때문에 DES를 못쓰는 것 뿐이다. 만약 DES를 쓸 수 있다면 몇몇 주요 웹 브라우저에서도 플러그인 없이 가능하다. 예를 들어 IE CAPICOM과 Firefox의 crypto.signText 같은 것을 이용하는 방법이다. (하지만 이는 범용성이 떨어지는 단점이 있다.)

또 하나의 방법은 공인 인증용 독립 어플리케이션을 배포하는 것이다. 문제는 웹에서 해결 불가능한 것을 자꾸 웹에서 해결하려고 했던 데 있다. 과거에도 KT 월릿(Wallet) 프로그램이나 독립 프로그램으로 인터넷 뱅킹을 했었다. 모든 것을 웹으로 해결하려고 들지 말고 신한 은행 이지플러스 처럼 독립 프로그램을 제공하는 것도 검토해야 한다.

(2) 장기- 표준 SSL 기반 인증 및 서명 방법 개발
웹 브라우저에 몇 가지 기능이 추가 되면 범용 SSL 프로토콜을 써서 공인 인증이 가능하게 된다. 이를 위해서는 1) KISA루트 인증서 2) SEED 알고리듬 3) 전자서명 기능이 브라우저에 탑재 되어야 한다.

1)번의 경우 IE에 탑재되었고 Firefox에서 진행 중이다. 2)번의 경우 SEED가 2005년에 국제 표준이 되었기 때문에 연내에 윈도우와 OpenSSL(Firefox, Safari, Opera)에 탑재될 수 있을 것이다. 3)번의 경우가 가장 힘들다. 현재 몇 군데 표준 단체에 XML 전자서명을 통한 Web PKI 표준을 제정하도록 소수의 사람들이 함께 설득을 계속하고 있는 중이다.

하지만 실현이 되려면 꽤 많은 노력이 필요하다. 우리 나라 전자 서명법을 세계적으로 만들려면 KISA와 정부가 오히려 이런 데 정치적인 힘을 발휘해 주길 바란다.

(3) 장기- 리치 웹 어플리케이션 기술로 개발
현 재 글로벌 웹 기술은 리치 웹 어플리케이션으로 가고 있다. MS 비스타, 파이어폭스, 어도비 아폴로 플랫폼 등이 차세대 데스크톱 웹 어플리케이션 개발 플랫폼을 제공하기 위해 심혈을 기울이고 있다. 여기에 애플과 사파리 등이 WHATWG라는 표준활동을 통해 웹 표준으로도 리치 어플리케이션을 만들 수 있는 작업을 하고 있다.

글로벌 웹 기술의 변화는 플러그인에 있지 않다. 이점을 잘 인식하고 리치 웹 어플리케이션 기반 공인 인증 기술도 고민해야 한다.
 
[2] 윈도우 자체 보안 문제

공 인 인증 기반 체계과 별개로 인터넷으로 데이터를 도둑 맞는 스파이웨어 프로그램으로 생기는 보안 문제가 국내에서는 심각하게 대두 되어 있다. 스파이웨어에 대해 전 국민이 방지 프로그램을 설치하게 하는 창을 방패로 막으려 하지 말고 더 근본적인 방법을 도입해서 문제를 풀어야 한다.

(1) 단기 - 국내 사용자의 보안 수준 강화
- 윈도우 보안 수준 강화
우 리 나라 사람들은 전 세계 어디를 비교해 봐도 매우 교육 수준이 높다. 교육에 따라 얼마든지 보안 수준이 올라갈 수 있는 국민이다. IE의 보안 수준을 고급으로 올리도록 하고 윈도우 권한을 '일반 사용자'로 바꾸도록 사용자 교육을 강화할 필요가 있다.

국가에서 이를 권장하고 필요하다면 MS에 이야기 해서라도 한국어 버전에 보안에 대한 간단한 TIP을 나오게 하는 것도 가능할 것이다.

- 오프라인 인증 강화
공 인 인증만으로 인증이 다 됐다고 생각하는 건 큰 오산이다. 일반 SSL이든 공인 인증이든 PC의 보안이 뚫리면 끝이다. 지금까지 한 20개 정도가 조합되는 단순한 보안 카드에 거래를 의존해 왔다. 외국에서는 다양한 오프라인 인증 기기들이 존재한다.

단순한 보안 카드가 아니라 OTP(원타임패스워드) 같은 좀 더 복잡한 형태의 오프라인 인증기기의 사용을 늘일 필요가 있는 것이다. 특히 휴대폰이나 PMP 단말기 등에 인증 프로그램이 설치 될 수 있도록 지원할 필요가 있다.

- 데이터 해킹 보안 강화
키 보드 해킹 방지를 위해 스크린 키보드로 선택 하게 하거나 그림 문자를 통한 인증 수단도 함께 활용해야 한다. 스크린 키보드는 위치를 랜덤하게 표시하거나 그림 문자를 기계가 좀 더 해독하기 어렵도록 함으로서 보안은 충분히 강화된다.

- 개인 보안 수준 강화
가장 중요한 것이다. 스스로 보안은 스스로 지킨다는 의식을 가지도록 하는 게 좋다. 개인이 스스로 백신 프로그램을 구입 하여 설치하고 사용하도록 권장한다. 이게 SW 업계에도 이익이 된다.

특히 은행이나 금융권에서는 비 IE, 비 윈도우 사용자들 처럼 자신의 PC를 지킬 수 있다는 사람에 한해 계약을 통해 키보드 해킹 방지나 스파이웨어 방지 프로그램을 강제 설치 하지 않도록 할 필요가 있다.

(2) 장기 - 차세대 윈도우 OS나 대안 OS를 사용한다.
이건 말할 것도 없다. Vista를 사용하게 하거나 맥이나 리눅스 데스크톱을 사용하는 사용자가 늘어 나면 되는 것이다. 사실 어찌보면 이게 제일 중요하다.

-----
지금까지 현재 문제에 대한 다양한 해결 대안들을 살펴 보았다. 물론 이게 당장 해결 할 수 있는 것은 아니지만 장기적인 로드맵으로 꼭 해결 해야 될 걸로 본다.

IE 설계 변경에 따른 영향
IE 설계 변경에 따라서 달라지는 것은 무엇일까? 웹 페이지 내에서 'object', 'applet', 'embed' 태그에 의해 로드된 액티브 X, 자바 애플릿, 멀티미디어 파일의 경우, 사용자가 이를 클릭해서 명시적으로 활성화(Activation)시키기 전까지는 임베딩된 개체에 사용자가 직접 상호작용(Interaction)하는 것이 불가능하며, 상호작용과 관련된 DHTML 이벤트도 사용이 불가능하다는 것이다.

이번 패치의 영향을 받는 대상은 웹 페이지 내에 'object', 'applet', 'embed' 태그를 사용해서 지정되고, 눈에 보이는 UI를 가지며, 사용자가 마우스나 키보드 입력을 통해 이벤트를 처리하는 상호작용 컨트롤에만 해당된다.

상호작용 컨트롤의 예는 미디어 플레이어, 애플의 퀵타임 플레이어, 매크로미디어의 플래시 등이 있다. UI를 가지지 않는 비상호작용 컨트롤이나 외부 스크립트를 통해 로딩된 상호작용 컨트롤에는 아무런 영향이 없다.

인터넷 뱅킹 시스템의 경우, UI가 없는 키 로깅 방지 컨트롤은 영향이 없으며, 공인 인증서도 UI가 웹 페이지 내에 임베딩된 것이 아니라 별도의 다이얼로그 창으로 나오기 때문에 영향을 받지 않는다.

아래 그림은 웹 페이지에 'object' 태그나 'embed' 태그를 사용해서 미디어 플레이어 액티브 X를 구동해 동영상 콘텐츠를 재생하고 있는 모습이다. 활성화되지 않은 상호작용 컨트롤은 마우스나 키보드 이벤트 등의 사용자 입력에 반응하지 않는다. 마우스 커서를 올려놓았을 때 컨트롤 주위에 점선 테두리가 나타나며, 그림과 같은 풍선 도움말이 나타난다.

컨 트롤을 활성화하려면 마우스로 해당 컨트롤을 클릭하거나 탭 키로 포커스를 이동한 후 스페이스 바나 엔터 키를 누르면 된다. F5 키를 눌러서 페이지를 갱신했을 경우 컨트롤이 다시 비활성화되며, 페이지 내에 컨트롤이 여러 개 있는 경우에는 각각을 활성화해야 한다는 것에 주의해야 한다.

혼동해서는 안 될 것은 상호작용이 불가능하다는 것이지, 임베딩한 개체가 아예 로드되지도 않고 작동하지도 않는다는 것은 아니다. 즉, 위의 예에서 동영상 콘텐츠 자체가 아예 재생되지 않는 것은 아니다. 다만, 동영상을 멈추기 위해서 정지 버튼을 누르려면(즉 상호작용을 하려면) 컨트롤을 클릭해서 활성화시켜야 한다는 것이다.

국내 웹사이트의 파급 효과
위에서 예로 든 멀티미디어 콘텐츠(동영상, 음악) 외에 국내 사이트에서 이 패치에 대해 영향을 받는 것은 어떤 것이 있을지 몇 가지 예를 들어보자.

요즘 몇몇 사이트들에서는 사진이나 그림을 업로드하기 전에 이미지를 편집할 수 있도록, 이미지 툴 액티브 X를 제공하는 곳이 있다. 이러한 이미지 툴 컨트롤을 사용하려면, 컨트롤을 한 번 클릭해서 활성화시켜야 한다. 또한 업무용 시스템을 보면 차트, 그리드와 같은 요소를 서드파티 액티브 X 컨트롤로 사용하는 경우가 많다. 이 경우 상호작용을 하려면 화면 내의 컨트롤을 각각 활성화시켜야 한다.

액티브 X 컨트롤도 문제지만, 필자가 생각하기에 국내에서 가장 광범위하게 영향을 받을 것이라고 생각되는 것은 바로 플래시다. 국내 사이트들은 메뉴 등의 네비게이션 UI, 광고, 플래시 게임, 플래시 축하카드 등 플래시에 대한 의존도가 매우 높다. 거의 모든 UI를 플래시로 도배한 모 사이트의 경우, 화면의 대다수가 비활성화되는 현상이 발생했다(하다못해 필자 회사 홈페이지도 메뉴가 플래시로 돼 있다).

마우스를 올렸을 때 팝업 형태로 메뉴를 보여주는데, 비활성화된 상태에서는 메뉴가 전혀 나타나지 않는다. 사실 활성화를 위해 클릭 한 번 하는 것이 별로 힘든 일은 아니지만, 잘 모르는 사용자의 경우에는 상당히 당황스러울 수 있다는 생각이 든다.

이러한 사용자들의 혼란을 방지하려면 'object', 'applet', 'embed' 태그를 사용하는 페이지의 경우 수정이 불가피하다. 이를 위해 MS는 상호작용 컨트롤이 이전과 동일하게 즉시 활성화되게 하고 싶으면 외부 스크립트에 의해 상호작용 컨트롤을 로드하라고 권하고 있다.

예를 들어 다음과 같이 'embed' 태그를 사용하는 페이지가 있다고 가정하자.

MyPage.html을 로드하면 해당 컨트롤은 비활성화된 상태가 된다. 이를 방지하려면, 다음과 같이 'embed' 태그를 write 해주는 코드를 외부 스크립트 파일(embed.js)로 작성해서 빼고, MyPage.html에서는 이 스크립트 파일을 지정하면 된다. 이렇게 하면 이전과 동일하게 이 컨트롤은 로드 후 즉시 활성화된다.

액티브 X, 플래시의 남발 자제해야

이러한 준비는 언제까지 마쳐야 할까?
MS는 1차적으로 3월 1일에 이 IE 패치를 윈도우 업데이트를 통해 선택적으로 배포할 예정이다. 즉 설치를 원하는 사용자만 이 패치를 설치하면 된다. 그러나 4월부터는 보안 업데이트에 일괄 적용되므로, 보안 업데이트를 설치하면 이 패치를 함께 설치하게 된다. 그러므로 사실상 4월 전까지는 위 방법을 통해 패치에 대한 대비책을 세우는 것이 바람직하다고 생각된다.

이 패치가 궁극적으로 국내 웹사이트에 미치는 영향이 얼마나 될지는 아직 미지수다. 하지만 분명히 외국 사이트에 비해서는 상당히 파급 효과가 클 것으로 예상된다. 그 이유는 국내 사이트들이 액티브 X, 플래시 등에 대한 의존도가 매우 높으며, 많이 사용하고 있기 때문이다. 특히 해외에서 국내 사이트들에 접속해보면 새삼스레 국내 네트워크 인프라의 우수성에 놀라게 된다.

국내 웹사이트들은 윈도우 XP 서비스팩 2에서 팝업 창 차단 때문에 대대적인 수정을 하는 홍역을 치른 적이 있다. 이제 시도때도 없이 뜨는 팝업 창뿐만 아니라 여기저기에서 남발됐던 액티브 X 및 플래시에도 제재가 들어오게 된 셈이다.

이러한 소동과 후유증을 겪어야 하는 것은 이올라스나 MS에도 책임이 있겠지만 웹 기획자, 디자이너, 개발자들, 고객이 스스로 이러한 문제를 초래했다는 것을 부인하지 못할 것이다.

이번 사건 이후에 액티브 X나 플래시 사용을 자제하는 바람직한 모습으로 가는 계기가 될지, 아니면 XP 서비스팩의 팝업 창 차단 이후 레이어를 통해 팝업 창을 흉내내는 기괴망측한 꽁수가 등장했듯이, 이번 사건 역시 개발자에게 스크립트 작업만을 잔뜩 추가해주게 될지는 두고 볼 일이다.