previous  next  Title  Contents  Index               Last Update: 10 May 2001

13 어플리케이션 보안

in English

인터넷/인트라넷

도입

인터넷 어플리케이션은 HTTP, wais, gopher, telnet 또는 ftp 같은 일반적인 인터넷 응용계층의 프로토콜을 사용하는 프로그램이다.

기존의 인터넷은 보안이 취약했으나 이제는 달라지고 있다. 보안시장은 빠르게 발전하고 있는 다양한 보안제품들을 선보이고 있다.
본 장에서는 인터넷/인트라넷 보안에 관한 모든 것을 다루지는 않는다. 기법(메커니즘)편, 방화벽편 그리고 가능한 UNIX/NT 편을 살핀 후 본 장을 읽을 것을 권장한다.

위험을 어떻게 줄이는가?

보안 문제들은 크게 클라이언트 관점에서의 보안과 서버 관점에서의 보안으로 나눌 수 있다.

클라이언트 관점에서의 보안과 브라우져

인터넷에서 다운로드 받기

트로이의 목마, 그릇된 문서나 프로그램 그리고 바이러스들로 인한 손해를 피하기 위해서 인터넷에서 파일을 다운로드시에는 많은 주의가 필요하다.

자바

1995년에 Sun Microsystems가 발표한 자바는 새로운 바람을 일으키고 있다. 자바는 C/C++와 닮은 언어로서 멀티쓰레드, 객체지향, 네트웍 그리고 바이트 코드 (byte code)를 이용한 이식성을 제공한다. 바이트 코드는 자바 가상 머신을 탑재한 어떠한 컴퓨터 상에서도 실행 또는 해석될 수 있다. 하지만 바이트 코드의 사용은 높은 이식성을 제공하는 대신 성능저하를 유발한다. (해석기가 느리기 때문이다. - 하지만 이것은 자바칩과 JIT (Just In Time) 컴파일러가 널리 사용되면서 극복될 것이다.)

자바는 두가지 상태로 돌아가게 설계되었다: 독립된 하나의 어플리케이션 (application) 개발을 위한 자바와 "애플릿 (applet)"으로서의 자바. 애플릿은 웹 페이지에서 브라우져로 다운받는 작은 자바 프로그램이며 브라우져에 의해 실행된다.

자바는 호화로운 WWW 홈 페이지와 높은 이식성을 가진 어플리케이션의 개발을 가능하게 했다 (Microsoft 는 자바의 이식성을 멈추기 위해 최선을 다하고 있지만). 일부 전문가들은 자바의 높은 이식성이 클라이언트/서버 환경의 미래라고 주장하고 있다.
자바 V1.02는 Navigator V2 (와 이후 버젼) 에서, IE3과 Mosaic과 PowerBrowser에서 지원한다. 자바 V1.1은 IE4, 1998년1월자 JVM fix가 설치된 Navigator 4.04 나 Navigator4.05 및 이후 버젼에서 작동한다.

자바는 외부 코드의 실행에 안전한 환경을 제공하도록 설계되었다:

자바 애플릿들에는 다음의 제한이 추가된다:

어떤 위협들에 대해서는 자바 설계에서 다루어지지 않았다:

위의 내용들은 이론적인 관점에서 다루어진 내용이다. 자바가 보다 많이 사용되면서 문제점들이 생겼다.

우리는 현재의 자바를 안전하게 만드는 것이 어렵다고 생각한다. 언어 자체, 바이트 코드의 형식, 그리고 런타임 시스템의 완전한 재설계만이 보다 높은 신뢰도를 가진 시스템으로의 발돋움을 가능하게 할 것이다. 공식적인 근거 없이, 시스템 보안에 대한 성명은 결정적일 수 없다.

자바에 결함이 있다고 해서 다른 경쟁 시스템들이 보다 안전하다는 의미는 아니다. 경쟁 시스템에 동일한 수준의 정밀조사가 적용되었다면 결과는 비슷했을 것이라고 추측한다. 원격에서 로드된 코드를 실행하는 것은 비교적 새로운 동향이며 이를 안전하게 하려면 보다 많은 노력이 필요하다.

현재는 (2000년 7월, 4년 후), 다른 보안 문제들은 소수 발생했고 (예를들면 브라우져 자체의 보안 버그와 비교하여) JDK 1.1이 대부분의 브라우져에서 지원됨으로 인해, 서명 애플릿의 사용이 두드러질 것이다.

결론:

자바스크립트

자바스크립트는 자바와 구문법은 비슷하지만 자바와는 아무 관계가 없다. 자바스크립트는 클라이언트측에서 해석되는 스크립트 언어로 Netscape 에서 개발하였다.
자바와는 달리 sandbox에서 작동하지 않으며, 파일 올리기, 메일 보내기, 어떤 것이든 쓰여진 내용을 대화상자로 표시하기, 그리고 로컬 파일에 쓰기를 한다 (대화상자를 통해서라도). 자바스크립트에는 두개의 보안정책이 있다:

  1. 동일 출처 정책 (same origin policy) 은 Navigator 2.0 부터 디폴트 정책이었다. 한 출처로부터 문서를 적재할 때는, 다른 출처에서 로드된 스크립트는 윈도우나 프레임, 객체(그림, 레이어, 주소, 창, 문서) 에서 속성을 가져오거나 설정할 수 없다.
  2. Communicator 4.0 에서 새로 나온 서명된 스크립트 정책 (The signed script policy)은 새로운 자바 보안 모델인 객체 서명을 토대로 한다. 자바스크립트의 새로운 정책을 사용하려면, 새로운 자바 보안 클래스를 사용하고 자바스크립트로 만든 스크립트들에 서명한다.

보안관련 버그가 계속 발견되므로 수개월마다 반드시 최신판 브라우져로 업그레이드한다.

Note: 자바스크립트가 이메일로 첨부된 html 파일로 배달될 경우에는 무슨일이든지 할 수 있다, 즉 대화상자 프롬프트 없이, 사용자가 이를 시작할 때 이미 권한을 가지게 된다! 이를테면 사용자의 PC의 파일 시스템을 이메일로 보낼 수도 있다.

권고사항

Hot Java

Hot Java는 자바 언어가 어떤 것을 할 수 있는지 증명하기 위해 개발된 Sun Microsystems社의 WWW 브라우져이다. Hot Java 는 지원이 없고 순수히 자바의 가능성을 입증을 위해 만들어졌고, 특히 Hot Java 는 보안에 여러 개의 보안 결함들이 있으므로 일반 사용자들이 사용해서는 안된다. ([java1]을 참조한다.)

브라우저의 ActiveX

ActiveX는 웹 페이지의 프로그램을 PC에서 실행하도록 설계되었다. ActiveX에는 프로그램의 출처를 인증하는 기능외에는 어떠한 보안 정책이나 보안 개념조차 없다. 웹 브라우져를 통해 받은 ActiveX 프로그램들은 사용자의 PC에서 아무 제한없이 실행된다. 예를 들면 하드디스크를 포멧하거나 시스템 종료같은 작업들이 가능하다. ( 몇 가지 예를 보려면 www.halcyon.com/mclain/ActiveX 를 참조한다.)

Netscape Navigator

PC부터 UNIX까지 다양한 플랫폼에서 작동하는 Netscape 의 브라우져는 많은 사용자들의 기본 브라우져로 애용되고 있다.

Microsoft Internet Explorer

Explorer 3.0은 자바, SSL 2, SSL 3, 소프트웨어 서명, PCT 1.0, ActiveX 그리고 ActiveX 스크립트/VB스크립트를 지원한다.

문제점들:

Executing Code on IE 4.0 and 4.01 (Jan.13'98)
Cracking Windows 95 Share
Passwords (Jan.9'98)
Teardrop 2 Attack (Jan.9'98)
IE Page redirect (Nov.19'97)
land Attack (Nov.17'97)
IE4 (Oct.11'97)
IE4 & DHTML (Oct.16'97)
IE4 & Java (Sep.12'97)
OOB Attack (May.9'97)
IE & Powerpoint (May.7'97)
Samba Can Grab Win95 Passwords (Mar.17 '97)
IE Hole with NTLM (Mar.15 '97)
IE & Netscape Hole Found (Mar.14 '97)
Run Local Commands With IE (Mar.7 '97)
Get IE To Launch Remote Apps (Mar.6 '97)
IE .LNK and .URL Problems (Mar.3 '97)
Potential Active Server Problem (Feb.20 '97)

Microsoft 가 모호함에 의한 (알고리듬, 사내 프로그램 평가 또는 보안 취약점등을 항상 사용자들에게 알리지 않고) 보안을 성취하려는 한 Explorer는 높은 수준의 보증을 제공할 수 없다. 하지만 IE는 Microsoft 의 운영체제와 하나가 되어가고 있으며 무료로 배포되고 있기에 앞으로 더욱 많은 사용자를 확보할 것이다.

서버들: WWW (World Wide Web)

Servers: WWW (World Wide Web)

참고 문서

  1. WWW 서버를 설치하기 전에, 다음 FAQ을 읽는다. 다음의 FAQ들은 서버 설정과 cgi 스크립트에 관하여 매우 자세히 설명되어있다.
    www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html와 www.cerf.net/~paulp/cgi-security 또는 hoohoo.ncsa.uiuc.edu/cgi/security.html.
  2. HTML관련 서적: "Webmaster in a Nutshell" (O'Reilly), "Teach Yourself Web Publishing with HTML in 14 Days", ISBN 1-57521-014-2 또는 "How to set up and maintain a World Wide Web Site: The Guide for Information Providers", Lincoln Stein (Addison-Wesley), ISBN 0-201-63389-2.
  3. WWW 보안에 관한 메일링 리스트
    www-security-request@nsmx.rutgers.edu
    body= SUBSCRIBE www-security YOUR_ADDR

안전한 HTML 버전과 Web상에서의 트랜잭션 처리의 보안에 관해서는 다음 링크들을 방문한다:

http://home.Netscape.com/info/SSL.html
http://www.commerce.net/information/standards/drafts/shttp.txt
http://www.w3.org/hypertext/WWW/Shen/ref/security_spec.html
http://www.w3c.org/
http://www.fv.com/
http://www.digicash.nl/
http://www.cybercash.com/
http://www.mcom.com/
http://www.algroup.co.uk/Apache-SSL

간단한 인증에 대한 정보는 다음 링크를 방문한다:

http://www.w3.org/hypertext/WWW/AccessAuthorization/Basic.html

서버 상태 코드에 관해서는 다음 링크를 방문한다:

http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTRESP.html
부록 C에 기재된 인터넷 참조문도 참고한다.

개요

WWW은 매우 빠르게 발전하고 있고 여러 업체들의 임의추가, 프로토콜, 다른 사용자 환경등으로 매우 복잡해지고 있다. 본 절에서는 안전한 WWW 서비스 제공과 관련된 WWW의 일부분만 언급한다.

일반

HTTP는 클라이언트가 연결을 시작하고 서버는 응답 후 연결을 종료하는, 비 상태기반 (stateless) 프로토콜이다. HTTP/1.0 요청은 사용자의 이메일 주소를 가리키는 from 필드, URI를 획득한 곳을 나타내는 referrer 필드 (즉 사용자의 컴퓨터와 도메인) 그리고 현재 사용중인 브라우저를 나타내는 user-agent 필드를 제공한다. 이러한 필드들은 사용자의 브라우저의 설정에 따라 사용 또는 사용되지 않는다.

Fail //*
Fail *//*
Fail /./*
Fail */./*

인증

대부분의 서버들은 access.conf와 같은 전체설정 또는 .htaccess/ .nsconfig와 같은 폴더별 설정을 사용하여 특정 파일들로의 접근을 패스워드를 사용하여 제한할 수 있다. 이것을 기본인증(Basic Authentication)이라 한다. IP주소나 컴퓨터이름에 근거한 접근제한 또한 대부분의 서버들은 지원한다. 이 두가지 방법은 간단한 것이 아니다 (예: 기본적인 auth는 base64로 사용자이름과 패스워드를 암호화한다. 이러한 암호화는 풀기가 쉽고 따라서 암호화하지 않는 것만 못하다).
access.conf는 Apache/NCSA를 참조하고 .nsconfig는 Netscape를 참조한다.

접근 통제

User-agent: *
Disallow: /

프라이버시 이슈 / 쿠키

쿠키는 위에 설명한 대로, 서버를 위해 (사용자) 상태 정보를 유지하려는 목적으로 만들어졌다. 서버 쿠키는 정보 항목과 함께 유효한 도메인 이름, 유효기간, 버전 및 안전하게 전송되어야 하는지 (즉 HTTP/SSL을 통해) 를 가리키는 플래그를 가지고 있다. 클라이언트 쿠키는 정보 항목과 함께 유효한 도메인 이름, 버전 및 경로를 가지고 있다. 클라이언트들은 쿠키당 4KB와 1.2MB 데이타로, 총 300 개의 쿠키를 가질 수 있을 것으로 가정된다 (서버당 20 쿠키).
가능한 문제들:

쿠키가 걱정스럽다면, Navigator & Explorer 를 설정하여 서버가 쿠키 설정을 요청하면 경고를 발생시키도록 할 수 있다. 많은 사이트들이 쿠키를 광범위하게 사용하고 있기 때문에 실제로는 이것이 어렵다. 또다른 대안은 쿠키를 관리하기 위한 도구를 설치하는 것이다.

가용성

가능한 한 전용 WWW 웹 서버를 사용하여 서버가 침투됐을 시의 피해를 최소화한다.

중복성 (Redundancy)

별개의 IP 주소를 가지나 같은 DNS 이름으로 매핑되는 동일한 WWW 서버를 사용함으로써, 중복 (redundant) WWW 서비스가 제공될 수 있다. 이 때 문제는 다중 서버들 간에 자동적으로 문서를 동기화 하는 것이다. SSH 와 rdist 를 사용하여 이를 해결할 수 있다.

인터넷 화폐

이 짧은 절은 호기심 많은 사람들을 위해 넣은 것이다. 인터넷 상거래로의 어려운 장애물 중 하나는 상품/서비스를 어떻게 하면 안전하게 주문하고 지불할 수 있느냐이다.
고전적인 방법은 SSL을 써서 온라인 주문 세션을 암호화 하고 신용카드를 써서 지불하는 것이다. 그러나, 새로운 지불 시스템들이 나오고 있다, 예를 들면:

이메일

다양한 많은 제품들(종종 호환되지 않는)이 다양한 많은 플랫폼 상에서 사용되고 있다: MS-Mail, Teamlinks, VMSmail, X.400, Mail Exchanger, 인터넷 (유닉스) 메일 및 IBM Host 메일 등등. 대기업 내에서는 보통 X.400 이 백본 프로토콜로, 독자적 프로토콜들에 대한 게이트웨이를 가지고 있다. Lotus notes 는 아마도 오늘날 가장 일반적인 시스템일테지만, 저자는 이에대한 경험이 없다 (그래서 여기에 언급하지 않았다).

X.500 은 표준화된 디렉토리 서비스이며 승인을 구하고 있는 중인데, 진척이 느리다. 이를 인터넷 디렉토리로 구현한 LDAP 은 일상화되고 있다.

안전한 이메일

회사의 통일된 보안 메일 시스템은 매우 중요하게 다루어져야 한다. 하지만 전세계적으론 말할 것도 없거니와 미국 내에서도 이러한 서비스를 제공하는 제품은 거의 없다.
아직 일반적으로 통용되는 보안 메일 체계가 없지만 S/MIME은 조금이나마 보안 메일 시스템의 미래를 제시한다. (밑을 참조한다) 보안 메일 시스템의 개념에 다음을 고려할 수 있다:

저자가 아는 보안 메일 시스템 중 위에 나열된 모든 조건을 만족하는 시스템은 없다. 그밖에 보안 메일 시스템 평가시 고려할 사항들은:

안전한 전송과 전자 서명을 제공하는 몇몇 다중 플랫폼 제품들이 있다.

PGP

PGP를 제공하는 무료/유료제품들이 있으며, 전자우편이나 파일을 암호화하는데 사용된다. PGP는 보안 메카니즘 장에 언급되어있다.

PEM

PEM (Privacy Enhanced Mail) 은 보안 메일 표준으로 제안되었는데, Internet Activities Board 에서 아직 채택되지는 않았다. PEM 은 인증과 키관리를 포함하고 있으며, 공개 및 공용 키 암호 시스템을 모두 사용한다 (어떤 암호를 선택하는지 사용자가 선택한다).

S/MIME (May'98)

Secure MIME 은 안전한 이메일 교환을 위한 새로운 (제안된) 인터넷 표준으로 RSA에서 개발했다. 아직 공식적인 표준은 아니지만, 여러 벤더들이 (Netscape를 포함해서) 이미 S/MIME을 지원하고 있다. 공개 인터넷 표준이므로, 아마도 가장 좋은 장기적 솔루션일 것이다.

일반적으로 서버에서 S/MIME을 위한 변경은 필요치 않다. 예를 들어 MS Exchange 에서는, MAPI 인터페이스를 통해 익스체인지 클라이언트와 통합된다.

몇몇 제품들은:

Open Soft (www.opensoft.com 1997) 는 사용자당 $32 이고, 익스체인지와 동작하며 키 서버를 포함하고 있다. 미국 수출 규제 대상. 익스체인지와는 확실히 잘 동작한다.

Deming (www.deming.com) 도 익스체인지 호환 시스템을 제공하고 사용자당 $90 정도. 미국 수축 규제 대상.

이점:

  1. Eudora Pro 3.0 과 Exchange 모두와 작동한다 (그리고 같은 시스템에서 같은 인증서를 쓸 수 있다).
  2. 익스체인지 서버에는 변경이 필요없다.
  3. 인증서는 자체 서명되거나, VeriSign 같은 TTP에 의해 서명될 수 있다 (디폴트). 추후에는 텔레콤 TTP 에 통합될 수도 있다.

단점:

  1. 사용자 인터페이스가 완벽하지 않다, 이를테면 사용자가 우발적으로 암호화되지 않은 이메 일을 보내기가 쉽다. 이메일을 나타내는 데 사용되는 아이콘은 수신된 이메일이 성공적으로 해독되었는지 그리고 서명이 확인되었는지 표시하는 것 같지 않다. 지원 비용을 높이기는 하지만, 이러한 문제들은 툴바에 별도의 버튼을 추가함으로써 극복할 수 있다.
  2. 서명된 메시지가 현재 인증서가 없는 사용자로부터 수신되었을 때, 인증서는 인증서 데이타베이스에 자동적으로 추가된다. 이 인증서가 사용될 수 있으려면, 먼저 수작업으로 신뢰되어져야(trusted) 한다. 이 절차가 일반 사용자들에게는 약간 헷갈리며, 서명된 이메일이 수신되었을 때 멋진 팝업 상자로 처리되어야 한다.
  3. 인증서의 형식이 평범한 X.509 (.crt)가 아니라 PKCS (.p7c) 인 것 같다.

MailSecure:

Baltimore Technologies (http://www.baltimore.ie)의 MailSecure 는, 군사급 강도의 암호화를 가지는 얼마 안되는 S/MIME Exchange 플러그인 중 하나이다. Baltimore 는 20년간 암호학 연구에 활발한 활동을 했으며, 이들이 암호화 알고리듬을 안전하게 구현할 수 있다는 확신을 갖게 하는 참고자료들을 제공한다. 이들은 안전한 웹 트랜잭션, 자바, 익스체인지 및 윈도우를 위한 제품들을 가지고 최근에야 상용 시장에 뛰어들었다.

이점:

  1. 강력한 암호화: 대칭 키: DES, 3DES 그리고 RC2 40-128 bit 및 공개 키 512-2048 bit. SHA-1 및 MD5 서명 알고리듬이 사용된다.
  2. Exchange 에 완전히 통합 (Exchange와 POP3 서버 모두에 대해 테스트됨).
  3. 패스문구는 아래와 같이 물을 수 있다:
    • 매번 또는
    • 시작할 때 (그리고 시작 후 특정 시간이 지나면 메모리에서 지워질 수도 있다).
  4. S/MIME 툴킷은 원한다면 개발자들에게 별도로 판매될 수 있다.
  5. V1.1.2 은 Exchange 4와 테스트되었다. Outlook 도 동작할 것이지만, 아직 테스트는 못해봤다.

단점 (주요 이슈들은 굵은 글씨로):

  1. Exchange 5 는 MailSecure와 문제가 있다.
  2. 메시지가 압축되지 않는다, 실제로 메시지 크기는 암호화될 때 거의 두배가 될 수 있다.
  3. 인증서를 보호하기 위해 사용되는 패스워드에 대한 제약을 사용자에 맞게 조정할 수 없다. 사용자 필요에 따라 디폴트 설정이 너무 제한적일 수도 너무 느슨할 수도 있다. 사용자가 로그인 하는 다른 시스템들의 패스워드 제약조건과 같아야 한다.
  4. 개발이 느린 것 같다: 베타에서 안정적인 제품으로 가는데 6개월 걸렸다. 지난 9개월 동안 새로운 기능은 추가되지 않았다.
  5. Inbox assistant를 사용하여 암호화된 목적지로 자동 이메일 전달이 불가능 (패스문구가 매번 입력되어야 하므로)
  6. 간헐적인 버그가 한두번 발견되었다: 메일작성(compose) 윈도우의 MailSecure 속성(File->Properties)은 Exchange 메시지 속성을 숨기고 있어, 메시지 속성이 (우선순위, 중요도, "보낸 편지함"에 복사본을 저장할 것인지 등) 변경되지 못한다.
  7. 간헐적인 버그: 새 메일을 작성하고 나서, 인쇄하려고 하면 암호화할 것인지를 묻는다! 아무 의미가 없다.
  8. 버그: 메일을 작성하다가, 도중에 무슨일이 있어 사무실을 나가야 했기에, 서명과 암호화 옵션을 모두 활성화 하여 메일을 저장했다. 저장된 메일은 더이상 읽을 수가 없었다 (smime-attachment로 암호화된 텍스트). (추측건대 수신자의 공개키로 메시지를 암호화해서, 원래 발신자가 읽을 수 없게 되는 것 같다?). 작업할 때: 임시 저장하지만 아직 보낼 준비가 안된 이메일은 암호화하지 말라.
  9. 유용할 사용자 인터페이스 기능:
    • 보다 나은 인증서 관리:
      • 인증서를 삭제할 수 있어야 한다.
      • 여러개의 개인 인증서를 가질 수 있고 서명에 어떤 인증서가 사용될 지 선택할 수 있어야 한다.
      • 인증서는 설치되는 동안을 제외하고는 가져오기/내보내기할 수 없다.
      • 당장은 자체서명 및 Baltimore 서명된 인증서들만이 지원된다.
      • 사용자가 이메일 주소를 여러개 가지고 있을 수 있으므로 (이를테면 인터넷, X.400, Exchange..), 여러 개의 이메일 주소를 하나의 인증서에 할당할 수 있어야 한다.
    • 패스문구를 물어보고 나서 일정한 시간동안 메모리에 유지하는 패스문구 (Passphrase) 옵션 (시작할 때 뿐 아니라).
    • 메시지 민감도가 기밀로 설정되어 있으면 (Message properties 참조), 자동적으로 암호화 되어야 한다.
    • 인증서 디렉토리 서비스 (Certificate directory service): 새로운 메시지를 생성할 때, 동일한 이메일 주소와는 별도로 주소록에 있는 사용자들과 쓸 수 있는 인증서를 연관시킬 어떤 방법이 있어야 한다. 이메일 주소는 계속 변하므로 별명을 쓸 수도 있을 것이다. 이메일 주소 변경에 따라 각각 새로운 인증서가 필요하다. 새로운 V1.2 는 확실히 X.500 디렉토리를 지원한다.
    • 주소록에 있는 특정 사용자에 대해 암호화된 이메일을 필수로 "표시" 하는 것도 좋을 것이다. 또 추가 옵션으로 이 사용자들에게 이메일이 보내졌을 때만 "서명/암호화" 프롬프트가 나오도록 설정할 수 있다.
    • Eudora, Lotus Mail 은 지원되지 않지만, 차후에는 될 지도 모른다.

권고사항:

HKEY_CURRENT_USER/SOFTWARE/Baltimore-Technologies/BMail/RAEmail

UniMS Certificate request 프로세서의 이메일 주소로 편집한다.

이메일 서버와 시스템들

Microsoft Exchange V4

Exchange 는 Microsoft 의 이메일 기반 그룹웨어 제품으로서 3.51 또는 이상의 NT에서 작동하는 서버 프로그램이다. Exchange에는 MS-Mail, X400, 인터넷 메일 (SMTP) 이 기본으로 포함되어있고 Novel, cc:Mail 그리고 IBM PROFS 시스템을 위한 추가모듈을 제공한다. X.500 디렉토리 서비스를 완전히 지원하지 않으나 독자적 디렉토리 서비스 (proprietary directory service) 는 제공한다. Windows 95 와 NT4 에는 rich text format, 그룹 일정관리, 메시지 중요도 부여 그리고 온라인/오프라인 작업을 지원하는 Exchange 클라이언트가 포함되어 있다.

보안 관점에서 볼 때 Exchange V4는 다음 기능을 제공한다:

  1. 안전한 데이타 교환:
  2. 입증/부인방지: 사용자는 수신자가 이메일을 수신했는지 그리고/또는 읽었는지 확인을 요청할 수 있다. 수신자가 고급 보안 설정을 가지고 있다면 (즉 전자서명 사용), 사용자는 올바른 수신자가 실제로 그 정보를 읽었다는 것을 무리없이 확신할 수 있다.
  3. 키 관리:
  4. 식별 & 인증:
  5. 접근 통제:
  6. 감사/로그: NT 보안 로그에 이벤트들이 로그된다. 디렉토리 객체와 서비스의 변경에 대한 감사를 설정할 수 있다.
  7. 가용성:

문제점:

Exchange 5.0 에서 약속되는 향후의 기능들:

권고사항:

MS-Mail

Microsoft 메일은 다음 모듈들의 집합이다:
1. 클라이언트 (윈도우 상의 MS-mail).
2. 메일박스 서버 (우체국 PostOffice 이라고 불림).
3. 메일 주소 디렉토리 서버.
4. 메일 배달 프로세스 (외부).
5. X.400 백본에 대한 게이트웨이.

해결되지 않은 이슈

유닉스 메일 (SMTP, MIME, sendmail, MMDF)

관련 모듈들은
1. 클라이언트 메일 프로그램 (사용자가 메일을 읽을/보낼 수 있게 함), e.g. Mailtool, CDE dtmail, mailx, Zmail, /bin/mail...
2. 로컬 배달 프로그램, e.g. sendmail.
3. 로컬 수신 프로그램, e.g. sendmail, popper
4. 메일박스 서버, e.g. NFS server.
5. 도메인 게이트웨이 (로컬도메인으로(/부터 다른 도메인으로) 메일 전달).
6. 인터넷 게이트웨이 (인터넷으로의 방화벽).
7. X.400 게이트웨이 (또는 다른 기업 백본 프로토콜).

Sendmail

Sendmail 은 복잡하고, 역사적으로 아주 버그가 많은 프로그램이다. Sendmail 문제들에 대한 예는 부록에 있는 CERT 권고문들의 목록을 참고한다. 대부분의 벤더들은 약간 변형된 sendmail을 가지고 있지만, 최신의 V8 sendmail을 쓰는 벤더는 별로 없는데, V8은 더 많은 기능을 가지고 있으면서도 더 안전한 것으로 추정된다. [4].

==> PGP 같은 도구와 함께 사용하는 경우가 아니면 기밀 이메일의 전송에 sendmail 을 사용하지 않도록 한다.

MMDF (Multi-channel Memo Distribution Facility)

아래는 몇몇 MMDF 문서들 중에서 추출한 것이다:

MMDF 는 다양한 사용자 인터페이스와 배달 메카니즘을 지원하는 메일 전송 시스템이다. 설계는 기존의 메일 시스템들과 호환될 필요성에 구애받지 않았고, 결과적으로 MMDF 는 통합 메일 처리 프로그램 집단이 되었다.
MMDF 의 설계는 단일 호스트 시스템으로부터 대형 메일 릴레이로 메일 시스템의 성능 저하 없이 성장할 수 있게 하며, 부하가 거대해짐에 따라 성능은 점차적으로 (gracefully) 저하되도록 한다. 대용량 메일 릴레이에 대한 요구가 MMDF의 많은 혁명적인 설계 선택들로 이어졌다.
다른 몇몇 시스템들과 달리, MMDF는 메일 의뢰와 배달에 별개의 프로세스를 가지고 있다. 죽은 호스트들 각각에 대한 재시도 이력에 따라 지능적인 재시도 전략을 허용하는 최근의 배달 소프트웨어 변화가 설명될 것이다. 새로운 도메인 서버 메카니즘의 주소 확인에 대한 효과가 논의될 것이다.
메일을 채널로 분리하는 것이 MMDF의 대량메일 처리능력에 대한 열쇠이다. 각 채널은 서로 다른 배달등급을 나타내고 각 채널이 자체적으로 대기열을 가지고 있다. 이것은 문제를 고립시키고 서로 다른 채널마다 서로 다른 레벨의 서비스를 제공할 수 있게 해준다.

MMDF 시스템은 원래 Delaware 대학에서 개발되었으며 Ballistic Research Laboratory 와 University College London 에서 괄목할만한 개발 성과를 보았다.

MMDFII 소프트웨어는 무료로 (테이프 복사 비용등은 제외하고), 다음의 내부에서만 사용할 수 있다: Ballistic Research Labs를 통해 미국 정부 기관에서, BBN의 CSNET Coordination and Information Center 를 통해 CSNET 사이트에, 그리고 Delaware 대학 Electrical Engineering and Computer Science Department의 David Farber 교수를 통해 다른 곳에.
내부 사용이 아닌 MMDF에 대한 상업적 관심을 Farber교수와 계약해야 한다.

1994년 이후로는 진보하지 않은 것 같고, 현재 버전은 V2.4.3 이며 MMDFIIb 라고 불린다. http://www.cs.okstate.edu/~vasoll/mmdf도 참조한다.

사무 자동화

MS-Office (윈워드/ 엑셀/ 파워포인트)

Microsoft 워드는 윈도우 3.1용 워드 6.0, 매킨토시용 워드 6.01, 윈도우 NT(TM)용 워드 6.0 에서 생성되는 문서를 통해 스스로 배포되는 장난(prank) 매크로의 표적이다. 장난 매크로는 윈도우나 매킨토시용 워드의 이전 버전에는 영향을 미치지 않는다. 매크로를 포함하는 문서를 연 다음, 이후에 저장되는 문서들은 그 매크로의 복사본을 포함한다. 한번 설치되면, 이 매크로는 문서를 템플릿으로 저장할 수만 있게 한다. 이 매크로는 그 외에는 문서의 내용에 영향을 주지 않는다.

WordPerfect

WordPerfect 는 매크로가 문서 파일이 아닌 별도의 파일에 저장되기 때문에 윈워드만큼 매크로 바이러스 공격에 민감하지 않다.

윈도우 도움말 파일

윈도우 도움말 파일은 DLL을 호출할 수 있다. 따라서 신뢰할 수 없는 소스로부터 온 도움말 파일은 열어보지 않도록 한다. 만약 꼭 봐야 한다면, 특권없는 (unprivileged) 사용자로서 연다.

Postscript

Postscript 는 매킨토시 세계에서 비롯되어 문서 인쇄를 위한 표준 언어가 되었다. 그러나, Postscript는 파일시스템에 대한 직접 접근을 허용할 수 있는 (레벨 2.0부터) 해석(interpredted) 언어로, 따라서 postscript 파일들을 이용하여 다른 파일들을 읽거나 쓸 수 있다!

Ghostscript

Ghostscript 는 공개 도메인 postscript 해석기로 무료 소프트웨어 재단 (GNU) 에서 개발했다. Ghostview 는 Ghostscript 해석기 엔진을 사용하는 postscript 파일 뷰어이다. Ghostscript 는 버전 3.22 베타부터 -dSAFER 옵션을 가지고 시작되어 파일 쓰기를 허용하지 않을수 있다. Aladdin 버전은 이 fix를 가지고 있는데, GNU 버전은 없다 (아직, 1995년 9월). Ghostscript 가 다양한 프론트 엔드들로부터 불려질 수 있기 때문에, 명령줄을 변경하는 것이 항상 가능한 것은 아니다. 그러므로:

% SAFER not { ( %END SAFER) .skipeof } if
......
% %END SAFER 

호스트 에뮬레이터 (vt100, vtxx0, 3270)

어떤 에뮬레이터에서는 패스워드를 키보드 매크로로 프로그램할 수 있다. 만약 이 기능이 사용된다면, 에뮬레이터 초기화 파일 (매크로가 씌어진) 은 다른 사용자들이 읽을 수 없어야 한다.이것은 홈 디렉토리가 서버상에 있을 때 특히 문제가 된다.

Teemtalk

Teemtalk 은 3270 (IBM 메인트레임 접근용) 과 VT340 (VAX 접근) 에뮬레이션을 제공하여 다양한 호스트 어플리케이션을 직접 사용할 수 있게 해준다. 두 가지 에뮬레이션 모두 파일 전송을 위한 기능을 포함하고 있다. Teemtalk 은 "Winsock" 통신 프로토콜을 사용하여, 3270 에뮬레이션에는 3174 게이트웨이를 거치고, VMS 시스템 접근은 소켓을 통해 직접한다.

에뮬레이터는 호스트 기반의 데이타에 접근할 때 필요하다. 보안 관점에서 볼 때 이것의 의미는:

  1. 사용자들은 메인프레임 호스트에 접근하기 위해 사용자이름과 패스워드를 입력해야 한다. 이 패스워드들은 Telnet 프로토콜의 사용으로 인해 네트웍을 clear text 로 다니게 된다 (호스트 보안 저하).
  2. 호스트와 PC 간 트러스트가 필요 없다 (호스트 보안 개선).
  3. 사용자들이 다중 계정과 패스워드를 가지므로, 어디서나 동일한 패스워드를 사용할 수도 있고, 적어 놓을 수도 있고 또는 추측하기 쉬운 패스워드를 사용할 수도 있다 (보안 저하).

암호화되지 않은 상태로 네트웍을 돌아다니는 로그인 이름/패스워드는 네트웍상에 "스니퍼" 를 돌리고 있는 직원이나 건물 간 전용회선 (네트웍 절 참조) 을 "듣고 있는 (listening)" 외부 해커에 의해 "보일" 수 있다. 이는 Telnet 프로토콜의 취약성에 기인한다. 이 프로토콜에 대한 독자적인 보안 확장도 있지만 (아직) 널리 채택된 것은 없다.

 

X 윈도우

도입

X 윈도우 시스템은 매우 유연하고, 표준화되어 있지만, 종종 안전하지 못한 그래픽 사용자 인터페이스 (GUI)가 유닉스 시스템, PC, NT 그리고 심지어 VAX 에서도 사용가능하다.X 윈도우는 MIT 에서 (공개 도메인으로) 개발되었으며, 클라이언트/서버 기반의 아키텍쳐를 가지고 있다. 처음으로 광범위하게 채택된 X 윈도우 버전은 버전 11, 릴리즈 3 이었다. 이것은 X11R4 로 알려져 있다.?? 현재 버전은 X11R6 이다. X11이라는 말이 종종 X 윈도우 시스템 대신 사용된다. MIT의 X11은 종종 Vanilla X 로 불리워, 수많은 상업용 버전들과 구별된다.

X 클라이언트 는 프로그램 또는 application 이고 X 서버 는 화면과 윈도우를 제어하는 소프트웨어이다. 이 (좀 헷갈리는) 명명 관습은 종종 X 서버가 사용자의 로컬 시스템에서 돌아가고 클라이언트가 서버에서 돌아간다는 것을 의미한다! X 서버와 X 클라이언트는 X 프로토콜 을 통해 통신한다. X 프로토콜은 로컬 시스템에서만 운영될 수 있다 (클라이언트와 서버가 로컬일때), 또는 네트웍을 가로질러 운영될 수 있다 ( 클라이언트와 서버가 위와 같이 분리되었을 때). X 터미널 은 화면, 키보드, 마우스에다, X 터미널이 X클라이언트에게 사용 가능하도록 만드는, 통제 X 서버 소프트웨어가 같이 있는 것이다.

많은 클라이언트들이 하나의 서버 상에서 운영될 수 있다. 이 클라이언트들은 네트웍 상의 모든 시스템으로부터 온다. 클라이언트간 통신과 접근 통제 (어떤 클라이언트가 어떤 서버에서 시작할 수 있는가) 가 제어되어야 한다. 한 클라이언트가 다른 클라이언트에게 정보를 보낼 수 있다면, 다른 클라이언트에게로 가는 정보를 획득할 수 있다면, 또는 다른 클라이언트로 가는 정보를 속일(spoof) 수 있다면 보안이 침해될 수 있다.
전형적인 클라이언트간 통신에는 다음이 포함된다:

악의적인 클라이언트들은 그러한 통신을 삭제/변경 또는 대체하려고 할 수 있다.

일반적인 권고사항

xhost

각 X 서버는 접근이 허용되는 호스트 목록을 유지하고 있다: 즉 이 호스트들로부터의 클라이언트들은 X 서버를 이용하여 윈도우를 디스플레이/조작할 수 있다. xhost 명령어는 향후 모든 연결에 대한 호스트 접근 통제 목록 (ACL) 을 관리하는데 사용된다 . 기존 연결은 영향을 받지 않는다. 몇가지 예를 들면:

xhost + 모든 호스트로부터의 연결을 허용 (권장하지 않음!). ACL 이 있긴 있지만 아무 효과도 없다.
xhost +host1 로컬 도메인에 있는 host1을 ACL에 추가한다.
xhost +host1.mydomain (DNS) 도메인 mydomain 에 있는 host1을 ACL에 추가.
xhost -host1 ACL 에서 host1 제거.
xhost 현재 ACL 을 표시.
xhost - 현재 ACL에 접근을 제한. xhost + 가 그전에 먼저 사용되지 않았으면 이것은 아무 효과도 없다. xhost + 가 먼저 실행된 후라면, xhost + 명령 전의 ACL 이 복원된다. 중요 : xhost - 는 어떤 호스트도 접근할 수 없다는 뜻이 아니다!

어떤 사용자가 인가되지 않은 호스트로부터 서버에 연결하려고 시도한다면 (이 예제에서는 SERVER_NAME 이라고 함), 다음 에러 메시지가 발행된다:

Xlib: connection to "SERVER_NAME:0.0" refused by server.
Xlib: Client is not authorised to connect to server.

xhost 메카니즘은 순전히 호스트 기반이다, 즉 어떤 호스트가 접근을 허가받았다면, 그 호스트의 모든 사용자들은 접근이 허가된다. 호스트당 사용자 하나의 워크스테이션 환경에서는 이것이 그리 문제가 되지 않지만, 다중 사용자 서버에서는 워크스테이션으로의 접근이 허용된다면 중대한 보안 위험을 드러내는 것이다.

xauth

토큰 기반 인증에서는, 사용자의 X11 세션에 토큰 (이 경우에는 난수)이 부여된다. X11서버에 연결하고자 하는 모든 클라이언트는 이 토큰을 가지고 있어야 한다. 이 토큰은 보통 X 세션을 소유하고 있는 사용자만이 가질 수 있으므로, 이 토큰이 사용자 기반의 접근통제 메카니즘을 제공한다고 할 수 있다. 이 토큰을 X11 용어로 매직 쿠키 라고 한다. 하나의 시스템에만 로그온 한 사용자에게는, 더이상의 보안은 투명하다.
매직 쿠키는 사용자 홈 디렉토리의 .Xauthority 에 저장된다. xauth 프로그램을 사용하여 이 쿠키를 추가하고 읽고 삭제한다. 쿠키를 나열하려면, xauth list 를 쓰고, 인증 상태를 보려면 xauth info 를 사용한다. xauth 만 치면 프롬프트가 뜨는데, 여기서 ? 나 help 를 입력하여 명령어 목록을 본다.

쿠키 생성:
이것은 쿠키를 만드는 표준 메카니즘이 아니다! Sun의 OpenWindows 와 XDM (아래참조)은 시작할 때 자동으로 매직 쿠키를 만들어 내지만, 다른 X11 시스템들에서는 수작업으로 쿠키를 생성해야 한다. 몇가지 다른 방법들이 가능한데, $HOST가 로컬 화면의 이름을 담고 있다면, xinit 에 다음을 사용할 수 있다:

  1. korn shell 난수 발생기 사용:

    2. xauth add ${HOST}:0.´ksh -c 'echo $(( $RANDOM*RANDOM*2 ))'´
  2. Clock 사용:

xauth add ${HOST}:0.´date +"%y%m%d%H%M%S"´

난수에다 위의 TCP/IP 이름 외에도 유닉스 PC이름도 추가한다:

xauth add ${HOST}/unix:0 . RAND_NUM

쿠키 배포:
사용자가 원격 호스트에서 클라이언트를 시작하고자 한다면, 자기 로컬 디스플레이로의 접근을 어떻게 허용할 것인가? 두가지 가능성을 생각해 볼 수 있다:

  1. 원격과 로컬 호스트가 이 사용자에 대해 같은 홈 디렉토리를 마운트하여, 사용자가 양쪽 호스트에서 동일한 .Xauthority 파일에 접근, 접근 통제가 자동으로 된다. (확인 요망!)
  2. 홈 디렉토리가 공유되지 않는다. 이 경우에는 원격 시스템에 있는 .Xauthority 파일이 동기화되어야 한다. .rhosts 파일이 존재한다면, 다음을 사용할 수 있다.

auth extract - $DISPLAY | rsh REM_HOST xauth merge -

또는, X11R5 contrib 클라이언트인 xrsh 를 사용할 수 있으면, 원격 클라이언트는 직접 시작될 수 있다:

xrsh -auth xauth REM_HOST xload

권고사항:

Sun OpenWindows

Common Desktop Environment (CDE)

이것은 유닉스 데스크탑을 위한 새로운 표준 윈도우 관리자로, 주요 벤더들에 의해 지원된다. 기본적으로 HP OpenView 의 모양과 Sun의 OpenLook Tooltalk 엔진 및 데스크탑 유틸리티들을 가지는 Motif 이다. 하부의 윈도우 시스템은 X11R5 나 R6 이다.

X Display Manager (XDM)

XDM은 GUI 로그인 시스템으로 서로 다른 X 서버들로의 로그인을 가능하게 한다.

DisplayManager*authorize: true

XDM 은 시작할 때 자동으로 매직 쿠키를 생성하여 .Xauthority 에 복사한다.

TBD: xdm 유형의 로그인에 대한 인증 (-broadcast, -query, -indirect). 질의 방법 권고.

Xterm

가장 잘 알려진 X 클라이언트는 아마 표준 터미널 에뮬레이션인 xterm 이다. 이 도구는 보안 영역에서 몇가지 강점 & 약점이 있다. 먼저, 다음 옵션을 resource 파일에서 설정해야 한다:

xterm*allowSendEvents: False

이것은 인위적인 이벤트들 (즉 마우스나 키보드에서 발생되지 않은) 을 무시하도록 해준다. 이는 spoofing을 방지하는 데 도움이 된다.

이제는 X 서버에 의해 운영중인 모든 X 클라이언트들 간에 키보드가 공유된다. X 클라이언트가 중요한 정보를 읽고 있다면 (e.g. 패스워드), 다른 X 클라이언트들이 키입력을 읽을 수 없도록 확신하고 싶을 것이다. 키보드를 완전히 통제하기 위해 (다른 클라이언트가 입력을 받을 수 없게), xterm 은 "Secure Keyboard" 옵션을 제공하며, 메뉴에 있다 (CTRL + 왼쪽 마우스 버튼). 이 옵션은 다시 다른 윈도우에서 작업하려면 꺼져야 한다. 이때문에, 이것은 그다지 실용적이지는 않다.

패치:

작업 플로우 관리자 (Workflow Managers)

Staffware V5

일반

Staffware 는 복잡한 관리적 루틴들이 자동화될 수 있게 해주는 작업 플로우 관리자이다.

중요한 이슈:
* Oracle 과의 상호작용
* OLTP 연결 세부사항, Staffware 서버들간의 RPC 통신
* 트랜잭션 무결성?

책임추적성

사용자 식별 / 인가
감사 증적

Staffware 운영에 대한 상세한 감사 증적이 가능하다.

접근 통제

객체 재사용
N/A

안전한 데이타 교환

Oracle 과의 통신:
Staffware 는 데이타를 Oracle 테이블에 저장하고 SQL을 통해 Oracle과 통신한다.

Staffware 다중 노드 구성:
Staffware 서버들은 서버들간의 작업 플로우를 조정하기 위해 서로 서로 대등하게 통신할 수 있다.

통신 상대방 인증
무결성

데이타 전송의 무결성은 TCP/IP와 RPC 또는 이메일 전송에 의해 보장된다.

기밀성

패스워드는 clear text 로 네트웍을 통해 전송된다.

송/수신 부인 방지

전자 서명은 지원되지 않는다.

가용성

백업
중복성 (Redundancy)

없다?

EDI

Electronic Data Interchange (전자 문서 교환) 은 송장, 주문서 등을 전자적으로 교환하는 업무의 한 방법이다. 여러가지 표준들이 많이 있다. 보안 이슈들에 대한 상세한 논의는 Swisscom 의 기술 잡지 "Telecom PTT Technische Mitteilungen 2-1994" 에 있는 Orla Greevy (mailto:greevy_o@vptt.ch)의 "Security and EDI"를 참고하기 바란다.

안전한 어플리케이션 개발

일반적인 지침

유닉스 어플리케이션 개발

[unix1] 과 유닉스 장 도 참고한다.

New: http://www.sunworld.com/swol-08-1998/swol-08-security.html?080198a 도 참고한다. (위의 것과 비교하지는 않았지만, 좋은 소스로부터 가져왔다..) Local 사본.

개발 언어

C보다는 자바 (또는 Ada) 와 같이 보안을 의식한 언어를 사용한다. 마찬가지로 perl 보다는 tainted perl 을 사용한다. 프로그램에서 대부분의 실제 보안 취약점은 a) 잘못된 설계 (패스워드를 clear text 로 보낸다든지) 또는 b) 잘못된 프로그래밍이다. (e.g. string/stack/array overflows, wild pointers, race conditions)

자바 권고사항:
C++:
C 권고사항:
Perl 권고사항:

Note: 이것은 name@domain 과 맞아야 하며 name 과 domain 은 문자, 단어, 밑줄, 점 또는 하이픈을 가질 수 있다.

이 예제는 0-9를 제외한 모든 문자를 제거한다:

$value =~ tr/0-9//cd;

아래 코드는 쉘 문자를 완전히 없애지만, 어떤 경우에는 너무 많은 문자들을 없앨 수도 있다 (e.g. 쉼표와 물음표가 있는 사용자 텍스트):

$value =~ s/'\"|*?~<>^()[]{}$\n\r";,//g;

CGI 프로그래밍

이전 절의 모든 규칙을 따르고, 이에 덧붙여:

클라이언트/서버 통신

RPC
Sun RPC: 18.6.6.2 를 본다. Sun의 RPC (ONC RPC 라고도 함) 는 동기 및 비동기 호출을 허용한다. 대부분의 현 어플리케이션들은 이 RPC를 표준으로 사용한다. 그러나 이것은 어떤 보안 옵션도 제공하지 않는다 (이들은 어플리케이션 레벨에서 구현되어야 한다).

가능하면 "일반" Sun RPC 보다는 Secure RPC 사용을 고려한다 (e.g. Secure NFS). RPC는 방화벽에서 걸러내기 어렵다.

NT RPC: MS 가 사용하는 DCE RPC 부분. NT 서비스에서 널리 사용.

소켓
소켓은 현재 클라이언트 서버 어플리케이션을 위한 사실상의 표준이다. 불행히도, 소켓 프로토콜 (BSD UNIX 에서 유래) 은 본질적으로 안전한 통신 지원이 없는 통신 방법이다. 어플리케이션 자체적으로 보안을 구현해야 한다.

비표준 소켓 번호의 사용: 이것은 소켓기반의 서버들에 대한 공격을 좀더 어렵게 한다. 그러나 이것은 "모호함을 통한 보안" 이며 소켓 번호가 프로그램에 할당되도록 조정하는 것이 바람직하다. 저자의 의견으로는, 이로인해 얻어지는 보안이 비표준 번호를 관리하는 법석을 떨 만한 가치가 없다.

ActiveX 프로그래밍

 

ASP (Active Server Pages) 프로그래밍

Jerry Connolly 의 논문 "Active Server Pages 에서의 입력 확인을 위한 최선의 지침" (Best practices for input validation with Active Server Pages) 에서 입력 확인 방법을 설명한다. http://heap.nologin.net/aspsec.html

 

코드 검사를 위한 도구

참고자료

이 문서에 대한 변경

----------------2001 ----------
05.jan'01 어플리케이션 (ActiveX 에 대한 업데이트)
----------------2000 ----------
31.Dec'00 어플리케이션 (cgi 프로그래밍: Xato ref. 추가)
15.Dec'00 어플리케이션 (코드 검사 도구)
26.Oct'00 업데이트: 자바 보안 링크. 신규: 코드 검사를 위한 도구
15.Feb'01 Perl & Win2k 프로그래밍 참고, 자바 1.1.에서의 비밀키 노출
23.Feb'01 원격 자바 조사 도구

[java1] 1996 IEEE 보안과 프라이버시에 대한 심포지움, "자바 보안: HotJava 에서 Netscape 까지 그리고 그 이상", 프린스턴 대학
[2] 버클리 대학의 두 학생이 이것을 발견. 1995년 11월.
[3] 보안 토큰은 SIMPORT.EXE 명령줄 유틸리티를 통해 한 그룹의 사용자들에게 en masse 집단으로 생성될 수 있다.
[4] Solaris 2.5 는 V8 기반이다.
[5] WordBasic 으로 쓰여진 최초? 바이러스는 1995년 8월에 인터넷에 퍼졌다. '97년 2월에는, 함부르크 대학에서 205 개의 (대부분 윈워드) 매크로 바이러스들을 보고했다. VisbualBasic 스크립트는 2000년 상황을 더욱 악화시켰다.
[activeX] "ActiveX 에서의 보안 워크샵 결과" www.CERT.org 또는로컬 사본

previous  next  Title  Contents  Index     IT Security Cookbook, 15 December, 2000