KR20090031350A - 게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법 - Google Patents

게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법 Download PDF

Info

Publication number
KR20090031350A
KR20090031350A KR1020087029166A KR20087029166A KR20090031350A KR 20090031350 A KR20090031350 A KR 20090031350A KR 1020087029166 A KR1020087029166 A KR 1020087029166A KR 20087029166 A KR20087029166 A KR 20087029166A KR 20090031350 A KR20090031350 A KR 20090031350A
Authority
KR
South Korea
Prior art keywords
request
application
gateway
network
client
Prior art date
Application number
KR1020087029166A
Other languages
English (en)
Other versions
KR101265920B1 (ko
Inventor
라지브 미라니
스탠리 행 웡
아브히섹 차우핸
Original Assignee
사이트릭스 시스템스, 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 사이트릭스 시스템스, 인크. filed Critical 사이트릭스 시스템스, 인크.
Publication of KR20090031350A publication Critical patent/KR20090031350A/ko
Application granted granted Critical
Publication of KR101265920B1 publication Critical patent/KR101265920B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G06F15/161—Computing infrastructure, e.g. computer clusters, blade chassis or hardware partitioning
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/029—Firewall traversal, e.g. tunnelling or, creating pinholes

Abstract

캐릭터 세트에 따라 요구를 디코딩하도록 게이트웨이(105)에 의한 요구 제출 인터셉트의 캐릭터 세트 인코딩을 결정하는 시스템 및 방법을 개시한다. 게이트웨이(105)는 URL 인코딩 요구와 같이 인코딩된 콘텐트를 포함하는 요구를 클라이언트(101a‥‥101n)로부터 수신한다. 게이트웨이(105)는 요구에 결합되거나 요구를 생성하는 애플리케이션(110A‥‥liON)을 결정한다. 결정된 애플리케이션에 기초하여, 게이트웨이는 그 애플리케이션에 결합되거나 그 애플리케이션을 위해 사용될 캐릭터 인코딩 스킴을 식별한다. 이어서, 게이트웨이(105)는, 식별한 캐릭터 인코딩 스킴을 이용하여 요구의 일부분을 디코딩하고 임의의 규칙이나 정책을 요구에 적용한다. 일부 실시 예들에서, 게이트웨이는, 각 애플리케이션에 결합된 인코딩된 스킴에 따라 디코딩할 수 있는 정책을 인코딩된 애플리케이션 네트워크 트래픽에 적용하는 보안 제어 시스템 또는 애플리케이션 방화벽으로서 동작한다.
게이트웨이, 캐릭터 세트 엔진, 캐릭터 인코딩

Description

게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법{SYSTEMS AND METHODS FOR DETERMINING THE CHARSET ENCODING FOR DECODING A REQUEST SUBMISSION IN A GATEWAY}
본 발명은 일반적으로 애플리케이션의 요구에 대한 차터 인코딩(charter encoding)의 결정에 관한 것이다. 보다 상세하게, 본 발명은 게이트웨이를 통해 제출된 애플리케이션의 요구를 디코딩하도록 캐릭터 인코딩 세트("charset"; 이하 캐릭터 세트라 함) 인코딩을 결정하는 시스템 및 방법에 관한 것이다.
인터넷으로 알려져 있는 세계 전역의 컴퓨터 네트워크 상의 사용자들로부터 정보를 얻는 흔히 알려져 있는 방식은, 브라우저의 사용자가 채울 수 있도록 하나 이상의 필드를 제공하는 페이지인 폼(form)으로 알려져 있는 기술이다. 그러나, 폼을 통해 제출될 수 있는 캐릭터에 대한 서로 다른 많은 인코딩이 존재하며, 요구에는 그 요구를 위해 어떤 캐릭터 세트를 이용해야 하는지를 표시하는 방식이 없을 수 있다. 폼 제출을 준비하는 데 사용되는 폼 제출과는 상이한 폼 제출(form submission)을 디코딩하는 데 캐릭터 세트를 사용함으로써 서버에 의해 폼의 거절 또는 오역이 발생할 수 있다. 이러한 문제점은 서버와 클라이언트 사이에 배치된 애플리케이션 방화벽과 같은 중간 네트워크 장치에서 심화되며, 그 이유는 폼의 생 성과 처리를 담당하는 애플리케이션 로직에 대한 액세스를 네트워크 장치가 갖지 않기 때문이다.
이러한 캐릭터 세트 문제점을 해결하려는 한 가지 기술은, 폼을 생성하여 클라이언트에게 전송하는 데 사용되는 캐릭터 세트를 기록하는 네트워크 장치에 의존한다. 그러나, 이 기술은 폼이 예를 들어 Javascript를 이용하는 클라이언트 상에서 전적으로 생성되는 경우 효과를 발휘하지 못한다. 네트워크 장치는 모든 폼 요구가 "utf-8"로서 알려져 있는 인코딩을 이용한다고 가정함으로써 이러한 문제점의 해결을 시도할 수도 있다. 이러한 방안에는 명백하게 단점이 존재한다.
본 발명의 시스템 및 방법은, 클라이언트 브라우저 또는 서버 애플리케이션이 기록될 필요 없이 서로 다르게 인코딩된 콘텐트나 미식별 캐릭터 세트로 인코딩된 콘텐트를 포함할 수 있는 애플리케이션으로부터의 요구를 효율적이면서 강건하게 다루고, 디코딩하며, 분석하는 해결책을 제공한다. 설명한 기술은, 서로 다른 상황들에 대하여 서로 다른 캐릭터 세트들을 사용하기 위해 정책이 요구에 적용될 수 있도록, 확장될 수도 있다. 그 결과, 서버와 클라이언트 사이의 폼 제출 및 기타 요구는, 어떠한 악성 요구도 최소한의 개수의 거짓 양성(false positive)으로 서버 애플리케이션에 도달하지 않도록, 검사될 수 있다.
일 양태에 있어서, 본 발명은 요구를 디코딩하는 데 사용되는 캐릭터 인코딩을 결정하는 방법에 관한 것이다. 이 방법은, 요구를 수신하는 단계와, 요구가 복수의 애플리케이션 프로그램 중 어떤 애플리케이션 프로그램에 대응하는지를 결정하는 단계를 포함한다. 이 방법은, 결정된 애플리케이션 프로그램에 결합된 캐릭터 인코딩을 식별하고, 식별한 캐릭터 인코딩을 이용하여 요구를 검사한다.
일 실시예에서, 이 방법은 요구의 속성으로부터 이 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정한다. 몇몇 실시예들에서, 요구의 속성은, 1) 소스 식별자, 2) 대상(destination) 식별자, 3) 포트 식별자, 4) 프로토콜 식별자, 5) 헤더 정보, 6) 유니폼 리소스 로케이터(URL) 어드레스를 포함한다. 다른 일 실시예에서, 이 방법은 수신한 요구 내에 포함된 쿠키를 이용하여 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정한다.
다른 실시예들에서, 이 방법은 캐릭터 인코딩과 애플리케이션 사이의 결합(association)을 포함하는 파일을 이용하여, 결정된 애플리케이션 프로그램에 결합된 캐릭터 인코딩을 식별한다. 몇몇 실시예들에서, 이 방법은 캐릭터 인코딩과 애플리케이션 사이의 결합을 포함하는 데이터베이스를 이용하여, 결정된 애플리케이션 프로그램에 결합된 캐릭터 인코딩을 식별한다.
일 실시예에서, 이 방법은 제2 요구를 수신하는 단계와, 제2 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계와, 결정된 제2 애플리케이션 프로그램에 결합된 제2 캐릭터 인코딩을 식별하는 단계를 포함한다. 다른 일 실시예에서, 이 방법은 클라이언트에 의해 생성된 요구를 수신하는 단계를 포함한다. 이 방법은 클라이언트의 속성을 이용하여 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정할 수 있다. 또 다른 일 실시예에서, 이 방법은 캐싱된 폼 페이지(cached form page)에 기초하여 요구를 수신하는 단계를 포함한다.
다른 양태에 있어서, 본 발명은 요구를 디코딩하는 데 사용되도록 캐릭터 인코딩을 결정할 수 있는 게이트웨이에 관한 것이다. 시스템은 네트워크를 통해 클라이언트와 통신하고 클라이언트로부터 요구를 수신하는 수신기를 포함한다. 또한, 시스템은 수신기와 통신하는 캐릭터 세트 엔진을 포함한다. 캐릭터 세트 엔진은, 요구가 지향하고 있는 애플리케이션에 응답하여 수신한 요구에 결합된 캐릭터 인코딩을 식별하고, 식별한 캐릭터 세트를 이용하여 요구를 검사한다.
일 실시예에서, 게이트웨이는, 복수의 클라이언트와 통신한다. 몇몇 실시예들에서, 게이트웨이는, 요구에 포함된 1) 소스 식별자, 2) 대상 식별자, 3) 포트 식별자, 4) 프로토콜 식별자, 5) 헤더 정보, 6) 유니폼 리소스 로케이터 어드레스 중 하나를 이용하여, 요구가 지향하고 있는 애플리케이션 프로그램을 결정한다. 다른 일 실시예에서, 캐릭터 세트 엔진은 캐릭터 인코딩과 애플리케이션을 결합하는 데이터베이스를 포함한다. 다른 실시예들에서, 캐릭터 세트 엔진은 캐릭터 인코딩과 애플리케이션을 결합하는 파일을 포함한다.
또 다른 양태에 있어서, 본 발명은 인코딩된 부분을 갖는 클라이언트 요구를 게이트웨이에 의해 검사하는 방법에 관한 것이다. 이 방법은, 클라이언트 상의 애플리케이션 프로그램으로부터의 요구를 게이트웨이에 의해 수신하는 단계를 포함한다. 또한, 이 방법은, 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 게이트웨이에 의해 결정하는 단계와, 결정된 애플리케이션 프로그램에 결합된 캐릭터 인코딩을 식별하는 단계를 포함한다. 이 방법은 식별한 캐릭터 인코딩을 이용하여 요구의 일부분을 게이트웨이에 의해 디코딩하는 단계와, 요구의 디코딩한 일부분을 검사하거나 분석하는 단계를 더 포함한다.
이 방법의 일 실시예에서, 게이트웨이는 요구의 속성을 이용하여 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정한다. 다른 일 실시예에서, 게이트웨이는 클라이언트의 속성을 이용하여 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정한다. 또 다른 일 실시예에서, 게이트웨이는 요구의 디코딩한 일부분의 검사에 기초하여 요구에 정책을 적용한다.
몇몇 실시예들에서, 방법은, 클라이언트와 제2 클라이언트 중 하나 상의 제2 애플리케이션 프로그램으로부터의 제2 요구를 게이트웨이에 의해 수신하는 단계를 포함한다. 게이트웨이는, 제2 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하고, 결정된 애플리케이션 프로그램에 결합된 제2 캐릭터 인코딩을 식별한다. 게이트웨이는 식별한 제2 캐릭터 인코딩을 이용하여 제2 요구의 일부분을 디코딩한다. 몇몇 실시예들에서, 게이트웨이는 제2 요구의 디코딩한 일부분을 검사하거나 분석한다. 다른 일 실시예에서, 방법은 제2 요구의 디코딩한 일부분의 검사에 기초하여 제2 요구에 정책을 게이트웨이에 의해 적용하는 단계를 포함한다.
본 발명의 다양한 실시예의 상세는 첨부 도면과 이하에서 설명한다.
본 발명의 전술한 그리고 다른 목적, 양태, 특징, 이점은 보다 명백해질 것이며 첨부 도면과 함께 다음에 따르는 설명을 참조함으로써 잘 이해될 수 있다.
도 1A는 애플리케이션의 캐릭터 세트 인코딩을 결정하는 시스템을 갖는 게이트웨이를 배치하는 네트워크 환경의 일 예의 블록도이다.
도 1B는 클라이언트 및/또는 서버상에 애플리케이션을 위한 캐릭터 세트 인코딩을 결정하는 시스템을 배치하는 다른 네트워크 환경의 블록도이다.
도 1C 및 도 1D는 본 발명의 시스템의 예시적인 일 실시예를 실시하기 위한 컴퓨팅 장치의 실시예의 블록도이다.
도 2는 클라이언트로부터의 요구를 디코딩하고 분석하는 데 사용하도록 애플리케이션을 위한 캐릭터 세트 인코딩을 결정하는 시스템의 블록도이다.
도 3은 클라이언트로부터의 요구를 디코딩하고 분석하는 데 사용하도록 애플리케이션을 위한 캐릭터 세트 인코딩을 결정하는 기술의 일 실시예를 실시하는 데 수행되는 단계들의 흐름도이다.
본 발명의 특징 및 이점은, 도면 전체에 걸쳐 유사 참조 문자들이 대응 요소들을 식별하는 첨부 도면과 함께 후술하는 상세한 설명으로부터 보다 명백해질 것이다. 도면에서, 유사 참조 번호는 일반적으로 동일한 요소, 기능적으로 유사한 요소, 및/또는 구조적으로 유사한 요소를 가리킨다.
이하, 본 발명의 예시적인 소정의 실시예을 설명한다. 그러나, 본 발명이 이러한 실시예로 한정되지 않으며 오히려 본 발명에서 명확하게 설명되는 부가 및 수정이 본 발명의 범위 내에 포함된다는 점에 주목하기 바란다. 게다가, 여기서 설명하는 다양한 실시예의 특징들은 본 발명의 사상 및 범위로부터 벗어나지 않고 서, 상호 배타적이지 않으며 조합이나 순열이 본 명세서에서 명확하게 되어 있지 않더라도 그러한 조합과 순열로 다양하게 존재할 수 있다는 점을 이해하기 바란다.
도 1A는 애플리케이션 캐릭터 세트 인코딩 및 검사 시스템(120)을 배치하는 게이트웨이를 갖는 네트워크 환경의 블록도를 도시한다. 도 1A에 도시한 바와 같이, 네트워크 환경의 예는 복수의 클라이언트(101a-101n)와, 복수의 서버(106a-106n)와, 어플라이언스, 게이트웨이 어플라이언스, 게이트웨이 서버 또는 게이트웨이 장치라고도 칭할 수 있는 게이트웨이(105)를 포함한다. 서버(106a-106n)는 애플리케이션, 데이터베이스, 요구한 콘텐트를 클라이언트(101a-101n)에게 제공하는 기타 정보 시스템을 관리한다. 클라이언트(101a-101n)와 서버(106a-106n)의 각각은, 도 1C 및 도 1D를 참조하여 더 상세히 설명하는 컴퓨팅 장치(100)와 같은 컴퓨팅 장치의 임의의 유형 및 폼(fom)일 수 있다. 예를 들어, 클라이언트(101a-101n) 중 임의의 클라이언트는, 예를 들어, 셀폰이나 PDA인 원격통신 장치와 같은 이동 컴퓨팅 장치, 또는 임의의 유형의 데스크탑 컴퓨터에 더하여 랩탑이나 노트북 컴퓨터일 수도 있다.
클라이언트(101a-101n)의 각각은 네트워크(104)를 통해 게이트웨이(105)에 통신가능하게 결합되어 있는 한편, 게이트웨이(105)는 네트워크(104')를 통해 서버(106a-106n)에 통신가능하게 결합되어 있다. 일 실시예에서, 네트워크(104)는 인터넷을 포함하고, 네트워크(104')는 법인이나 기업 네트워크와 같은 개인 데이터 통신 네트워크를 포함한다. 네트워크(104, 104')들은 네트워크, 공중, 개인, 또는 기타 네트워크의 임의의 유형 및 폼일 수 있으며, 일부 경우에서는, 동일한 네트워 크일 수 있다.
도 1에서는 클라이언트(101a-101n)와 서버(106a-106n) 사이에 네트워크(104)와 네트워크(104')를 도시하고 있지만, 클라이언트(101a-101n)와 서버(106a-106n)는 동일한 네트워크(104 또는 104') 상에 있을 수 있다. 네트워크(104, 104')들은 동일한 유형의 네트워크 또는 서로 다른 유형의 네트워크일 수 있다. 네트워크(104, 104')들은 회사 인트라넷과 같은 LAN, MAN, 또는 인터넷이나 WWW(World Wide Web)와 같은 WAN 일 수 있다. 네트워크(104, 104')들은, 네트워크의 임의의 유형 및/또는 폼일 수 있으며, 점대점 네트워크, 브로드캐스트 네트워크, WAN, LAN, 원격통신 네트워크, 데이터 통신 네트워크, 컴퓨터 네트워크, ATM(비동기 전송 모드) 네트워크, SONET(동기 광 네트워크) 네트워크, SDH(동기 디지털 계층) 네트워크, 무선 네트워크, 유선 네트워크 중 임의의 것을 포함할 수 있다. 네트워크(104, 104')들의 토폴로지는 버스, 스타, 또는 링 네트워크 토폴로지일 수 있다. 네트워크(104, 104')들 및 네트워크 토폴로지는, 본 명세서에서 설명하는 동작을 지원할 수 있는 당업자에게 알려져 있는 바와 같이 임의의 네트워크 또는 네트워크 토폴로지일 수 있다.
도 1A에 도시한 바와 같이, 게이트웨이(105)는 공중 데이터 통신 네트워크와 같은 제1 네트워크(104)와 개인 데이터 통신 네트워크와 같은 제2 네트워크(104') 사이에 배치되어 있다. 다른 실시예들에서, 게이트웨이(105)는 제1 네트워크(104) 상에 또는 제2 네트워크(104') 상에 위치할 수 있다. 다른 실시예들에서, 게이트웨이(105)는, 클라이언트(102a-102n)와 같거나 다른 네트워크(104) 상에서의 임의 의 개별적인 클라이언트(101a-101n)나 임의의 개별적인 서버(106a-106n)의 구성 부분일 수 있다. 이처럼, 게이트웨이(105)는 네트워크 내의 또는 클라이언트(101a-101n)와 서버(106a-106n) 사이의 네트워크 통신 경로 내의 임의의 점에 위치할 수 있다.
클라이언트(101a-101n)의 각각은, 일반적으로 본 명세서에서 애플리케이션 또는 애플리케이션(110)이라 칭하는 애플리케이션(110A-110N)을 실행, 동작, 또는 제공할 수 있다. 애플리케이션(110)은 소프트웨어, 프로그램의 임의의 유형 및/또는 폼, 또는 웹 브라우저, 웹 기반 클라이언트, 클라이언트-서버 애플리케이션, 신(thin) 클라이언트 컴퓨팅 클라이언트, ActiveX 제어나 Java 애플렛의 임의의 유형 및/또는 폼과 같은 실행가능 명령어, 또는 클라이언트(101a-101n) 상에서 실행될 수 있는 실행가능 명령어의 다른 임의의 유형 및/또는 폼일 수 있다. 몇몇 실시예들에서, 애플리케이션(110a-110n)은 서버(106a-106n) 상에서 클라이언트(101a-101n)를 대표하여 실행되는 서버 기반 애플리케이션 또는 원격 기반 애플리케이션일 수 있다. 일 실시예에서, 서버(106a-106n)는, 미국 플로리다주 Fort Lauderdale에 소재하는 Citrix Systems, Inc.에서 제조한 독립적 컴퓨팅 아키텍처(ICA) 프로토콜이나 미국 와싱턴주 Redmond에 소재하는 Microsoft Corporation 사가 제조한 프로토콜과 같은 원격 디스플레이 프로토콜 또는 임의의 신 클라이언트를 이용하여 클라이언트(101a-101n)에게 출력을 표시할 수 있다.
몇몇 실시예들에서, 서버(106a-106n) 또는 서버 팜(farm)은, 신 클라이언트 컴퓨팅 또는 원격 디스플레이 프리젠테이션 애플리케이션을 제공하는 애플리케이션 과 같은 하나 이상의 애플리케이션(110)을 실행하고 있을 수 있다. 일 실시예에서, 서버(106a-106n) 또는 서버 팜은, Microsoft Corporation가 제조한 Microsoft
Figure 112008082148106-PCT00001
Windows Terminal Services의 임의의 것, 및/또는 MetaFrame 또는 Citrix Presentation ServerTM와 같이 Citrix Systems, Inc.가 제조한 Citrix Access SuiteTM의 임의의 부분을, 애플리케이션(110)으로서, 실행한다. 일 실시예에서, 애플리케이션(110)은 미국 플로리다주 Fort Lauderdale에 소재하는 Citrix Systems, Inc.가 개발한 ICA 클라이언트이다. 다른 실시예들에서, 애플리케이션(110)은 미국 와싱턴주 Redmond에 소재하는 Microsoft Corporation가 개발한 원격 데스크탑(RDP) 클라이언트를 포함한다. 다른 실시예들에서, 서버(106a-106n)는 클라이언트(101a-101n)에게 애플리케이션(110)을 스트리밍할 수 있다. 또한, 서버(106a-106n)는, 예를 들어, 미국 와싱턴주 Redmond에 소재하는 Microsoft Corporation가 제조한 Microsoft Exchange와 같은 이메일 서비스를 제공하는 애플리케이션 서버, 웹, 또는 인터넷 서버, 혹은 데스크탑 공유 서버, 또는 공동(collaboration) 서버일 수 있는 애플리케이션(230)을 실행할 수 있다. 몇몇 실시예들에서, 애플리케이션(110)들 중 임의의 것은, 미국 캘리포니아주 Santa Barbara에 소재하는 Citrix Online Division, Inc.가 제조한 GoToMeetingTM, 미국 캘리포니아주 Santa Clara에 소재하는 WebEx, Inc.가 제조한 WebExTM, 또는 미국 와싱턴주 Redmond에 소재하는 Microsoft Corporation가 제조한 Microsoft Office Live Meeting과 같은 임의의 유형의 호스팅 서비스 또는 제품을 포함할 수 있다.
일 실시예에 따르면, 게이트웨이(105)는 애플리케이션 캐릭터 세트 인코딩 및 검사 시스템(120)을 포함한다. 상세히 후술하는 바와 같이, 이 시스템(120)은 인코딩된 콘텐트를 포함하는 요구를 클라이언트(101a-101n)로부터 수신한다. 예를 들어, 클라이언트(101)는 URL 인코딩된 부분처럼 인코딩된 콘텐트를 갖는 요구 또는 HTTP 폼을 제출할 수 있다. 일 예로, 인코딩 스킴(scheme)의 유형은 요구로부터 알려져 있지 않을 수 있다. 시스템(120)은 요구에 결합된 애플리케이션 또는 요구를 생성하는 애플리케이션을 결정한다. 예를 들어, 시스템(120)은 애플리케이션에 결합된 인터넷 프로토콜 어드레스 및/또는 포트를 그 요구로부터 식별할 수 있다. 결정된 애플리케이션에 기초하여, 시스템(120)은 애플리케이션에 결합되거나 그 애플리케이션을 위해 사용될 캐릭터 인코딩 스킴을 식별한다. 예를 들어, 시스템(120)은 데이터베이스, 구성 정보를 위한 인코딩 스킴을 룩업(lookup)하거나 정책 엔진으로부터 그 인코딩 스킴을 룩업할 수 있다. 이어서, 시스템(120)은 식별한 캐릭터 인코딩 스킴을 이용하여 요구의 일부분을 디코딩하고 임의의 규칙이나 정책을 그 요구에 적용한다. 몇몇 실시예들에서, 시스템(120)은, 각 애플리케이션에 결합된 인코딩 스킴에 따라 디코딩할 수 있는 인코딩된 애플리케이션 네트워크 트래픽에 정책을 적용하는 애플리케이션 방화벽 또는 보안 제어 시스템으로서 동작한다.
일반적으로 게이트웨이(105)로서 설명하고 있지만, 게이트웨이는 어플라이언스, 네트워크 장치, 또는 서버처럼, 후술하는 바와 같이 컴퓨팅 장치(100)의 임의 의 유형 및 폼일 수 있다. 몇몇 실시예들에서, 게이트웨이(105)는 제1 네트워크(104)와 제2 네트워크(104') 사이에 가상 개인 네트워크 연결을 확립하거나 제공한다. 일 실시예에서, 게이트웨이(105)는 네트워크(104, 104')들 사이에 보안 소켓층(Secure Socket Layer; SSL) VPN 연결을 확립한다. 다른 일 실시예에서, 게이트웨이(105)는 클라이언트(101a-101n)와 게이트웨이(105) 사이에 TCP 연결과 같은 제1 전송층 연결을 확립하고, 게이트웨이(105)와 서버(106a-106n) 사이에 제2 전송층 연결을 확립한다. 또 다른 일 실시예에서, 또한, 게이트웨이(105)는 클라이언트(101a-101n)와 서버(106a-106n) 사이에 암호화된 세션을 확립하거나 제공한다. 일 실시예에서, 게이트웨이(105)는 전송층이나 애플리케이션층에서 임의의 풀링 및/또는 멀티플렉싱 연결 기술을 이용하여 전송층 연결을 통해 클라이언트(101a-101n)로의 애플리케이션의 전달을 가속화할 수도 있다. 다른 일 실시예에서, 게이트웨이(105)는 클라이언트(101a-101n)와 서버(106a-106n) 사이에서 하나 이상의 네트워크 통신, 또는 이 통신의 일부들을 압축한다. 다른 실시예들에서, 게이트웨이(105)는 클라이언트(101a-101n)와 서버(106a-106n) 사이에서 임의의 하나 이상의 네트워크 통신, 또는 이 통신을 위한 부분들을 캐싱하기 위한 캐시를 포함할 수도 있다.
일반적으로 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)이 도 1A에서와 같이 게이트웨이(105) 내에 배치된 것으로 도시되어 있지만, 이 시스템(120)은 임의의 컴퓨팅 장치(100) 내에 배치될 수도 있다. 이제 도 1B를 참조해 보면, 예를 들어, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은 클라이언트(101a) 처럼 클라이언트(101a-101n) 중 임의의 하나 이상에 배치될 수 있다. 일 실시예에서, 게이트웨이(105)를 통해 네트워크(104)에 액세스하려는 클라이언트(101)의 요구에 따라, 게이트웨이는 클라이언트(101) 상에 설치되도록 시스템(120)을 제공할 수 있다. 몇몇 실시예들에서, 시스템(120)은 게이트웨이(105)로부터의 수신시 클라이언트(101)에 의해 자동 설치된다. 다른 일 실시예에서, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은 서버(106b)와 같이 임의의 서버(106a-106n)에 배치될 수 있다. 또 다른 일 실시예에서, 시스템(120)은, 분산될 수 있으며, 클라이언트(101), 게이트웨이(105), 및/또는 서버(106) 상에서 실행되는 임의의 하나 이상의 부분들을 가질 수 있다. 일 실시예에서, 시스템(120)의 복수의 인스턴스는 클라이언트(101), 게이트웨이(105), 및/또는 서버(106)의 임의의 조합을 실행할 수 있다.
도 1C 및 도 1D는 컴퓨팅 장치(100)의 블록도를 도시하며, 몇몇 실시예들에서는 이 컴퓨팅 장치를, 본 명세서에서 설명하는 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)의 일 실시예를 실시하는 데 유용한 네트워크 장치, 네트워크 어플라이언스 또는 어플라이언스(100)라고도 칭한다. 도 1C 및 도 1D에 도시한 바와 같이, 각 컴퓨팅 장치(100)는 중앙 처리 유닛(102)과, 메인 메모리 유닛(122)을 포함한다. 도 1C에 도시한 바와 같이, 통상적인 컴퓨팅 장치(100)는 비주얼 디스플레이 장치(124), 키보드(126) 및/또는 마우스와 같은 포인팅 장치(127)를 포함할 수 있다. 각 컴퓨팅 장치(100)는, 중앙 처리 유닛(102)과 통신하는, (일반적으로 참조 번호 130인) 하나 이상의 입력/출력 장치(130a-130b), 캐시 메모리(140)와 같 이 선택 사항인 추가 요소들을 포함할 수도 있다.
중앙 처리 유닛(102)은 메인 메모리 유닛(122)으로부터 페치(fetch)된 명령어에 응답하고 이 명령어를 처리하는 임의의 로직 회로부이다. 많은 실시예에서, 중앙 처리 유닛은, 미국 캘리포니아주 Mountain View에 소재하는 Intel Corporation이 제조한 마이크로프로세서 유닛, 미국 일리노이즈주 Schaumburg에 소재하는 Motorola Corporation이 제조한 마이크로프로세서 유닛, 미국 캘리포니아주 Santa Clara에 소재하는 Transmeta Corporation이 제조한 마이크로프로세서 유닛, 미국 뉴욕주 White Plains에 소재하는 International Business Machines가 제조한 마이크로프로세서 유닛, 또는 미국 캘리포니아주 Sunnyvale에 소재하는 Advanced Micro Devices가 제조한 마이크로프로세서 유닛과 같은 마이크로프로세서 유닛에 의해 제공된다. 컴퓨팅 장치(100)는, 이러한 프로세서들 중 임의의 것에 기초하거나 본 명세서에서 설명하는 바와 같이 동작할 수 있는 다른 임의의 프로세서에 기초할 수 있다.
메인 메모리 유닛(122)은, 데이터를 저장할 수 있고, SRAM, BSRAM, DRAM, FPM DRAM, EDRAM, EDO RAM, EDO DRAM, BEDO DRAM, EDRAM, SDRAM, JEDEC SRAM, PClOO SDRAM, DDR SDRAM, ESDRAM, SLDRAM, DRDRAM, 또는 FRAM과 같은 마이크로프로세서(102)에 의해 임의의 저장 위치가 직접 액세스될 수 있는 하나 이상의 메모리 칩일 수 있다. 메인 메모리 유닛(122)은, 전술한 메모리 칩들 중 임의의 것, 또는 본 명세서에서 설명하는 바와 같이 동작할 수 있는 다른 임의의 이용가능한 메모리 칩들에 기초할 수 있다. 도 1C에 도시한 실시예에서, 프로세서(102)는 (상세히 후 술되는) 시스템 버스(150)를 통해 메인 메모리(122)와 통신한다. 도 1C는 프로세서가 메모리 포트(103)를 통해 메인 메모리(122)와 직접 통신하는 컴퓨팅 장치(100)의 일 실시예를 도시한다. 예를 들어, 도 1D에서, 메인 메모리(122)는 DRDRAM일 수 있다.
도 1D는 메인 프로세서(102)가 때때로 백사이드 버스(backside bus)라고 칭하는 제2 버스를 통해 캐시 메모리(140)와 직접 통신하는 일 실시예를 도시한다. 다른 실시예들에서, 메인 프로세서(1020는 시스템 버스(150)를 이용하여 캐시 메모리(140)와 통신한다. 캐시 메모리(140)는 통상적으로 메인 메모리(122)보다 빠른 응답 시간을 갖고 통상적으로 SRAM, BSRAM 또는 EDRAM에 의해 제공된다.
도 1C에 도시한 실시예에서, 프로세서(102)는 로컬 시스템 버스(150)를 통해 다양한 I/O 장치(130)들과 통신한다. VESA VL 버스, ISA 버스, EISA 버스, MCA 버스, PCI 버스, PCI-X 버스, 또는 PCI-Express 버스, 또는 NuBus를 비롯한 다양한 버스들은 중앙 처리 유닛(102)을 I/O 장치(130)들 중 임의의 것에 연결하는 데 사용될 수 있다. I/O 장치가 비디오 디스플레이(124)인 실시예에서, 프로세서(102)는 디스플레이(124)와의 통신에 AGP(Advanced Graphics Port)를 이용할 수 있다. 도 1D는 메인 프로세서(102)가 HyperTransport, Rapid I/O, 또는 InfiniBand를 통해 I/O 장치(130b)와 직접 통신하는 컴퓨터(100)의 일 실시예를 도시한다. 또한, 도 1D는 로컬 버스 및 직접 통신이 혼합되어 있는 일 실시예를 도시하며, 여기서 프로세서(102)는 I/O 장치(130b)와 직접 통신하는 동안 로컬 배선 버스(local interconnected bus)를 이용하여 I/O 장치(130a)와 통신한다.
컴퓨팅 장치(100)는, 3.5인치 디스크, 5.25인치 디스크 또는 ZIP 디스크와 같은 플로피 디스크를 수용하는 플로피 디스크 드라이브, CD-ROM 드라이브, CD-R/RW 드라이브, DVD-ROM 드라이브, 다양한 포맷의 테이프 드라이브, USB 장치, 하드 드라이브 또는 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)에 관한 임의의 소프트웨어(120)와 같은 소프트웨어와 프로그램, 또는 그 일부를 설치하는 데 적절한 다른 임의의 장치와 같은 임의의 적절한 설치 장치(116)를 지원할 수 있다. 컴퓨팅 장치(100)는, 운영 체제 및 기타 관련 소프트웨어를 저장하고 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)에 관한 임의의 프로그램과 같은 애플리케이션 소프트웨어 프로그램을 저장하기 위한, 하나 이상의 하드 디스크 드라이브 또는 독립적 디스크들의 중복 어레이와 같은 저장 장치(128)를 더 포함할 수 있다. 선택 사항으로, 설치 장치(116)들 중 임의의 것을 저장 장치(128)로서 이용할 수도 있다.
게다가, 컴퓨팅 장치(100)는, 표준 전화선, LAN 또는 WAN 링크(예를 들어, 802.11, Tl, T3, 56kb, X.25), 브로드밴드 연결 (예를 들어, ISDN, Frame Relay, ATM), 무선 연결, 또는 이들의 전부 또는 임의의 것의 소정의 조합을 포함하는 다양한 연결을 통해 LAN, WAN 또는 인터넷에 인터페이싱하는 네트워크 인터페이스(118)를 포함할 수 있지만, 이러한 예로 한정되지는 않는다. 네트워크 인터페이스(118)는, 내장 네트워크 아답터, 네트워크 인터페이스 카드, PCMCIA 네트워크 카드, 카드 버스 네트워크 아답터, 무선 네트워크 아답터, USB 네트워크 아답터, 모뎀 또는 컴퓨팅 장치(100)를 통신할 수 있으며 본 명세서에서 설명하는 동작을 수 행할 수 있는 임의의 유형의 네트워크에 인터페이싱하는 데 적절한 다른 임의의 장치를 포함할 수 있다.
다양한 I/O 장치(130a0-130n)들이 컴퓨팅 장치(100)에 존재할 수 있다. 입력 장치는 키보드, 마우스, 트랙 패드, 트랙볼, 마이크로폰, 드로잉 태블릿을 포함한다. 출력 장치는 비디오 디스플레이, 스피커, 잉크젯 프린터, 레이저 프린터, 염료 승화(dye-sublimation) 프린터를 포함한다. I/O 장치는 도 1C에 도시한 바와 같이 I/O 컨트롤러(123)에 의해 제어될 수 있다. I/O 컨트롤러는 키보드(126) 및 포인팅 장치(127), 예를 들어 마우스나 광학 펜과 같은 하나 이상의 I/O 장치를 제어할 수 있다. 게다가, I/O 장치는 컴퓨팅 장치(100)에게 저장 장치(128) 및/또는 설치 매체(116)를 제공할 수도 있다. 다른 실시예들에서, 컴퓨팅 장치(100)는 미국 캘리포니아주 Los Alamitos에 소재하는 Twintech Industry가 제조한 USB 플래시 드라이브(USB Flash Drive) 선과 같이 핸드헬드 USB 저장 장치를 수용하는 USB 연결부를 제공할 수 있다.
다른 실시예들에서, I/O 장치(130)는, USB 버스, Apple Desktop 버스, RS-232 직렬 연결부, SCSI 버스, Fire Wire 버스, Fire Wire 800 버스, 이더넷 버스, AppleTalk 버스, Gigabit Ethernet 버스, 비동기 전달 모드(Asynchronous Transfer Mode) 버스, HIPPI 버스, 수퍼 HIPPI 버스, SerialPlus 버스, SCI/LAMP 버스, FibreChannel 버스, 또는 Serial Attached 소형 컴퓨터 시스템 인터페이스 버스와 같은 외부 통신 버스와 시스템 버스(150) 사이의 브리지(170)일 수 있다.
도 1C 및 도 1D에 도시한 종류의 컴퓨팅 장치(100)는 통상적으로 시스템 자 원에 대한 액세스와 작업의 스케쥴링을 제어하는 운영 체제의 제어 하에 동작한다. 컴퓨팅 장치(100)는, Microsoft
Figure 112008082148106-PCT00002
Windows 운영 체제의 버전들, Unix 및 Linux 운영 체제들 중 서로 다른 출시품들, 맥킨토시 컴퓨터를 위한 Mac OS
Figure 112008082148106-PCT00003
의 임의의 버전, 임의의 임베디드 운영 체제, 임의의 네트워크 운영 체제, 임의의 실시간 운영 체제, 임의의 오픈 소스 운영 체제, 임의의 사유 운영 체제, 이동 컴퓨팅 장치나 네트워크 장치를 위한 임의의 운영 체제, 컴퓨팅 장치상에서 실행될 수 있고 본 명세서에서 설명하는 동작을 수행할 수 있는 임의의 기타운영 체제 중 임의의 운영 체제를 실행할 수 있다. 통상적인 운영 체제는, WINDOWS 3.x, WINDOWS 95, WINDOWS 98, WINDOWS 2000, WINDOWS NT 3.51, WINDOWS NT 4.0, WINDOWS CE, WINDOWS XP - 이들 모두는 미국 와싱턴주 Redmond에 소재하는 Microsoft Corporation가 제조한 것임 -, 미국 캘리포니아주 Cupertino에 소재하는 Apple Computer가 제조한 MacOS, 미국 뉴욕주 Armonk에 소재하는 International Business Machines가 제조한 OS/2, 미국 유타주 Salt Lake City에 소재하는 Caldera Corp.가 배포한 자유롭게 이용가능한 운영 체제인 Linux, 또는 특히 Unix 운영 체제의 임의의 유형 및/또는 폼을 포함한다.
다른 실시예들에서, 컴퓨팅 장치(100)는 서로 다른 프로세서들, 운영 체제들, 컴퓨팅 장치와 일관성이 있는 입력 장치들을 구비할 수 있다. 컴퓨팅 장치(100)는 임의의 워크스테이션, 데스크탑 컴퓨터, 랩탑이나 노트북 컴퓨터, 서버, 핸드헬드 컴퓨터, 이동 전화나 기타 휴대용 원격통신 장치, 미디어 재생 장치, 조합 장치, 특수 목적 장치, 특별한 장치, 맞춤형 장치나 사유 장치, 또는 통신할 수 있고 본 명세서에서 설명하는 동작을 수행하도록 충분한 프로세서 파워와 메모리 용량을 갖고 있는 컴퓨팅이나 원격통신 장치의 다른 임의의 유형 및/또는 폼일 수 있다.
이제 도 2를 참조해 보면, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)의 일 실시예가 도시되어 있다. 이 시스템(120)은, 네트워크 장치, 어플라이언스, 게이트웨이, 클라이언트 또는 서버 장치와 같은 컴퓨팅 장치(100)의 임의의 유형 및/또는 폼 상에서 상주하며 그리고/또는 동작할 수 있다. 간략히 살펴보면, 시스템(120)은 수신기(215), 송신기(220), 캐릭터 세트 엔진(225), 규칙이나 정책 엔진(250)을 포함한다. 수신기(215)와 송신기(220)는 네트워크(104)를 통해 또는 네트워크(104, 104')들 사이에 통신을 수신하고 송신하는 데 사용될 수 있다. 캐릭터 세트 엔진(225)은, 네트워크 통신에 결합된 애플리케이션을 위해 사용될 인코딩의 유형 및/또는 폼을 결정하도록 요구와 같은 네트워크 통신을 처리하는 데 사용된다. 규칙/정책 엔진(250)은 시스템(120)에 의해 처리되는 네트워크 통신에 하나 이상의 규칙이나 정책을 적용한다. 예를 들어, 캐릭터 세트 엔진(225)에 의해 애플리케이션에 결합되도록 결정된 인코딩의 유형에 기초하여, 정책 엔진(250)은 네트워크 통신이 송신기(220)에 의해 송신되는 것을 제어하고, 제한하거나 방지할 수 있다. 일 실시예에서, 정책 엔진(250)은 시스템(120)이 방화벽 또는 보안 제어 장치로서 동작하거나 기능을 할 수 있게 한다. 또한, 정책 엔진(250)은, 디코딩된 콘텐트를 담당하는 액션 및 사용되는 인코딩을 결정하고 제어하도록 정책을 제공할 수 있다.
수신기(215)는, 네트워크(104)에 대한 장치(100)의 연결부의 매체를 통해 신호를 수신하도록 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 임의의 조합을 포함할 수 있다. 마찬가지로, 송신기(220)는, 네트워크(104)에 대한 장치(100)의 연결부의 매체를 통해 신호를 송신하도록 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 임의의 조합을 포함할 수 있다. 네트워크(104) 및 네트워크 연결부는, 전선. 케이블링, 광섬유, 전자기 방사와 같이 컴퓨팅 장치(100a-100n)들 사이에 송신 매체의 임의의 유형을 포함할 수 있고, 또는 본 명세서에서 설명하는 동작을 지원할 수 있는 송신 매체의 다른 임의의 폼을 가질 수 있다. 일 실시예에서, 수신기(215)는 제1 유형의 매체를 통해 하나 이상의 신호를 수신한다. 몇몇 실시예들에서, 송신기(220)는 제2 유형의 매체를 통해 하나 이상의 신호를 송신한다. 다른 실시예들에서, 수신기(215)와 송신기(220)는 동일한 유형의 매체 상에서 신호를 수신하고 송신한다. 또 다른 실시예에서, 송수신기는 매체를 통해 신호를 수신하고 송신하는 수신기(215)와 송신기(220)를 포함한다.
장치(100) 및/또는 시스템(120)은 네트워크 스택(210)을 포함한다. 몇몇 실시예들에서, 수신기(215) 및/또는 송신기(220)는 네트워크 스택(210)을 포함할 수 있다. 다른 실시예들에서, 수신기(215) 및/또는 송신기(220)는 복수의 네트워크 스택을 포함할 수 있다. 또 다른 실시예에서, 수신기(215) 및/또는 송신기(220)는 하나 이상의 네트워크 스택(210)을 인터페이싱하고, 통합하며, 또는 통신한다. 네트워크 스택(210)은, 네트워크와 연결 및 통신을 제공하도록 소프트웨어, 하드웨어, 또는 이들의 임의의 조합의 임의의 유형 및 폼을 포함할 수 있다. 일 실시예 에서, 네트워크 스택(210)은 네트워크 프로토콜 스위트(suite)를 위한 소프트웨어 구현예를 포함한다. 네트워크 스택(210)은, 당업자가 인식하고 이해하고 있듯이 OSI(Open Systems Interconnection) 통신 모델의 임의의 네트워크층과 같은 하나 이상의 네트워크층을 포함할 수 있다. 이처럼, 네트워크 스택(210)은, OSI 모델의 1) 물리 링크층, 2) 데이터 링크층, 3) 네트워크층, 4) 전송층, 5) 세션층, 6) 프리젠테이션층, 7) 애플리케이션층 중 임의의 것을 위한 프로토콜의 임의의 유형 및/또는 폼을 포함할 수 있다. 일 실시예에서, 네트워크 스택(210)은 인터넷 프로토콜(IP)의 네트워크층 프로토콜에 대한 전송 제어 프로토콜(TCP)을 포함할 수 있으며, 이는 일반적으로 TCP/IP라 칭한다. 몇몇 실시예들에서, TCP/IP 프로토콜은 이더넷 프로토콜 위에서 전달될 수 있으며, 이는 IEEE 802.3에 의해 커버되는 프로토콜들과 같이 IEEE WAN 또는 LAN 프로토콜들의 군(family) 중 임의의 것을 포함할 수 있다. 몇몇 실시예들에서, 네트워크 스택(210)은 IEEE 802.11 및/또는 이동 인터넷 프로토콜과 같은 무선 프로토콜의 임의의 유형 및 폼을 포함한다.
TCP/IP 기반 네트워크(104)의 실시예를 고려해 볼 때, 일 실시예에서, MAPI (Messaging Application Programming Interface)(이메일), FTP (File Transfer Protocol), HTTP (HyperText Transfer Protocol), CIFS (Common Internet File System) 프로토콜(파일 전달), ICA (Independent Computing Architecture) 프로토콜, RDP (Remote Desktop Protocol), WAP (Wireless Application Protocol), 이동 IP 프로토콜, VoIP (Voice Over IP) 프로토콜을 비롯한 임의의 TCP/IP 기반 프로토콜을 사용할 수 있다. 다른 일 실시예에서, 네트워크 스택(210)은, 예를 들어, T/TCP (Transaction TCP), TCP-SACK (TCP with selection acknowledgements), TCP-LW (TCP with large windows)와 같이 수정된 전송 제어 프로토콜과 같은 전송 제어 프로토콜, TCP-Vegas 프로토콜과 같은 혼잡 예측 프로토콜(congestion prediction protocol), TCP 스푸핑 프로토콜의 임의의 유형 및/또는 폼을 포함한다. 다른 실시예들에서, IP에 대한 UDP(user datagram protocol)와 같은 UDP의 임의의 유형 및 폼은, 예를 들어, 음성 통신이나 실시간 데이터 통신을 위해 네트워크 스택(210)에 의해 사용될 수 있다.
게다가, 네트워크 스택(210)은, TCP 드라이버 또는 네트워크층 드라이버와 같이 하나 이상의 층을 지원하는 하나 이상의 네트워크 드라이버를 포함할 수 있다. 네트워크 드라이버는, 컴퓨팅 장치(100)의 운영 체제의 일부로서 또는 임의의 네트워크 인터페이스 카드나 컴퓨팅 장치(100)의 기타 네트워크 액세스 컴포넌트의 일부로서 포함될 수 있다. 몇몇 실시예들에서, 네트워크 스택(2100의 네트워크 드라이버들 중 임의의 것은, 본 명세서에서 설명하는 본 발명의 기술들 중 임의의 것을 지원하여 네트워크 스택(210)의 맞춤형 또는 수정된 부분을 제공하도록 맞춤화되고, 수정되고 또는 적응될 수 있다. 다른 실시예들에서, 시스템(120)은 장치(100)의 운영 체제에 의해 설치되거나 제공된 네트워크 스택(210)과 함께 작업하거나 동작하도록 설계되고 구축된다.
도 2를 참조해 보면, 캐릭터 세트 엔진(225)은, 애플리케이션에 결합되는 캐릭터 세트 인코딩을 결정하도록 로직, 기능, 동작의 임의의 유형 및 폼을 포함한다. 캐릭터 세트 엔진(225)과 이 엔진의 임의의 일부는, 소프트웨어, 하드웨어, 또는 소프트웨어와 하드웨어의 임의의 조합을 포함할 수 있다. 간략히 살펴 보면, 캐릭터 세트 엔진(225)은 파서(230; parser), 애플리케이션 결정 메카니즘(235), 분석기(240)를 포함한다. 몇몇 실시예들에서, 캐릭터 세트 엔진(225)은 도 1A 및 도 1B에 도시한 바와 같이 애플리케이션(110a-110b)과 같은 애플리케이션으로의 또는 애플리케이션으로부터의 네트워크 통신을 수신하거나 인터셉트한다. 예를 들어, 클라이언트(100a) 상의 애플리케이션(110a)은 네트워크(104)를 통한 서버(110d)로의 요구를 포함할 수 있다. 일 실시예에서, 캐릭터 세트 엔진(225)은, 수신기(215), 송신기(220), 및/또는 네트워크 스택(210)에 인터페이싱되거나 이들과 통신한다.
몇몇 실시예들에서, 캐릭터 세트 엔진의 파서(230)는, 장치(100)에 의해 수신되거나 인터셉트된 임의의 네트워크 통신을 파싱(parsing)하는 로직, 기능, 또는 동작을 포함한다. 일 실시예에서, 파서(230)는 네트워크 통신의 임의의 부분을 식별하고, 파싱하고, 추출하고, 및/또는 해석한다. 일 실시예에서, 파서(230)는, HTTP (HyperText Transfer Protocol), XML (Extensible Markup Language) 프로토콜, 또는 SMTP (Simple Mail Transfer protocol)와 같은 임의의 애플리케이션층 프로토콜 통신을 파싱한다. 예를 들어, 파서(230)는, 클라이언트(100a)로부터 서버(100d)로의 HTTP 폼 제출과 같이 폼을 통해 제출된 하나 이상의 필드를 식별하고, 파싱하며, 또는 추출할 수 있다. 다른 예에서, 파서(230)는, HTTP 폼 제출과 같이 임의의 속성, 쿠키, 네임밸류(name-value) 쌍, URL, 데이터 스트링, 오브젝트, 또는 요구의 임의의 부분을 식별하고, 파싱하며, 또는 추출할 수 있다.
일 실시예에서, 파서(230)는, 요구에서, 텍스트, 이미지, 혼합된 데이터 유형들 등과 같은 콘텐트의 유형을 식별하는 속성, 헤더, 필드, 또는 데이터 요소를 식별한다. 예를 들어, HTTP 프로토콜의 일 실시예에서, 콘텐트 유형 헤더는, 메시지의 바디(body) 내의 매체 유형 및 데이터의 서브유형(subtype)을 특정하고 이러한 데이터의 네이티브 프리젠테이션을 특정하는 데 사용된다. 몇몇 실시예들에서, 파서(230)는 요구의 일부분이 인코딩되어 있음을 식별한다. 예를 들어, HTTP 프로토콜의 일 실시예에서, 콘텐트 유형 헤더는 URL 요구의 일부분이 인코딩되어 있음을 식별할 수 있다. 다른 일 실시예에서, 파서(230)는, 요구에서, 요구의 콘텐트의 일부분을 인코딩 또는 디코딩하는 데 사용할 캐릭터 세트를 식별하는 속성을 식별한다.
일 실시예에서, 파서(230)는 TCP 또는 UDP 패킷과 같은 전송층 프로토콜 패킷의 임의의 부분을 파싱한다. 몇몇 실시예들에서, 파서(230)는, 전송층 네트워크 패킷으로부터, 1) 소스 인터넷 프로토콜 어드레스, 2) 대상 인터넷 프로토콜 어드레스, 3) 소스 포트, 4) 대상 포트, 5) 프로토콜 또는 복수의 프로토콜을 식별하는 패킷의 헤더 및/또는 페이로드의 임의의 데이터, 6) 패킷 헤더의 임의의 필드 중 임의의 것을 식별하고 파싱한다. 다른 일 실시예에서, 파서(230)는, 네트워크 통신의 식별된 요소들이나 파싱된 네트워크 통신을 위해, 오브젝트 모델 프리젠테이션, 오브젝트 기반 애플리케이션 프로그래밍 인터페이스를 생성하거나 제공한다.
애플리케이션 결정 메카니즘(235)은 메시지나 요구와 같이 네트워크 통신에 결합된 애플리케이션을 결정하는 임의의 로직, 기능, 및/또는 동작을 포함한다. 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 파서(230)와 통신하거나 이 파서에 인터페이싱되며 네트워크 통신으로부터 하나 이상의 파싱된 정보를 얻는다. 몇몇 실시예들에서, 애플리케이션 결정 메카니즘(235)은, 요구로부터, 요구로부터의 임의의 정보 또는 이 요구를 나타내는 임의의 정보, 유형, 이름, 또는, 요구에 결합된 애플리케이션의 식별을 결정한다. 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 애플리케이션 및/또는 요구에 대한 인코딩의 유형을 식별한다. 인코딩 정보는, 요구를 디코딩하고, 검사하며, 분석하고, 또는 처리하는 데 사용될 수 있다.
몇몇 실시예들에서, 애플리케이션 결정 메카니즘(235)은, 애플리케이션의 이름, 유형, 또는 식별자를, 소스 인터넷 프로토콜 어드레스 및/또는 포트, 또는 대상 인터넷 프로토콜 어드레스 및/또는 대상 포트와 같은 네트워크 통신의 하나 이상의 데이터 요소와 결합하도록 구성된다. 예를 들어, 특정 클라이언트로부터의 네트워크 통신은 애플리케이션에 결합될 수 있다. 다른 예에서, 시스템(120)은 인터넷 프로토콜 범위 내에서 또는 포트나 포트 범위를 이용하여 네트워크 통신을 하나 이상의 서버에 결합할 수 있다. 다른 실시예들에서, 애플리케이션 결정 메카니즘(235)은, 인코딩 스킴, 캐릭터 인코딩 세트, 또는 인코딩 메커니즘의 이름, 유형, 식별자를, 파서(230)에 의해 제공되는 임의의 파싱된 필드와 같은 네트워크 통신의 하나 이상의 데이터 요소와 결합하도록 구성된다. 또 다른 실시예에서, 애플리케이션 결정 메카니즘(235)은, 네트워크 패킷의 페이로드에 의해 전달되는 정보에 의해서와 같이 네트워크 통신의 파싱을 통해 애플리케이션 및/또는 인코딩 스킴 의 유형, 이름, 또는 식별을 결정한다.
몇몇 실시예들에서, 애플리케이션 결정 메카니즘(235)은, 데이터베이스, 파일, 오브젝트, 데이터 구조, 또는 기타 정보 저장 매체를 이용하여, 네트워크 통신, 또는 이 통신의 임의의 일부를 애플리케이션 및/또는 인코딩 스킴에 결합하는 구성 정보를 저장한다. 예를 들어, 애플리케이션은 하나 이상의 인터넷 프로토콜 어드레스 및/또는 포트에 매핑될 수 있다. 다른 예에서, 애플리케이션 결정 메카니즘(235)은, 룩업 테이블의 임의의 네트워크 통신에서 식별된 하나 이상의 데이터 요소에 결합된 또는 이 하나 이상의 데이터 요소에 기초하여 애플리케이션을 룩업할 수 있다. 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 커맨드 라인 인터페이스 또는 그래픽 유저 인터페이스와 같은 인터페이스의 임의의 유형 및 폼을 통해 하나 이상의 사용자에 의해 구성가능하다. 다른 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 다른 프로그램, 스크립트, 애플리케이션 또는 시스템에 의해 애플리케이션 프로그래밍 인터페이스를 통해 구성된다.
요구와 같은 네트워크 통신에 결합된 애플리케이션의 결정시, 시스템(120)은, 네트워크 통신의 임의의 인코딩된 부분을 디코딩하는 데 사용되는 인코딩 유형을 결정하고, 식별하며, 또는 얻는다. 일 실시예에서, 애플리케이션 결정 메카니즘(235) 및/또는 분석기(240)와 같은 시스템(120)은, 네트워크 통신 자체의 데이터 요소 또는 임의의 부분으로부터 인코딩 유형을 식별한다. 예를 들어, 시스템(120)은, 네트워크 패킷의 페이로드 내의 데이터와 같은 네트워크 통신의 임의의 파싱된 요소들로부터 인코딩 유형을 식별할 수 있다. 다른 일 실시예에서, 시스템(120) 은, 예를 들어, 애플리케이션 프로그래밍 인터페이스를 통해 질의(query) 또는 룩업으로부터 테이블, 데이터베이스, 파일, 오브젝트, 데이터 구조, 또는 기타 저장 매체나 이러한 정보를 갖는 구성 메커니즘으로의 애플리케이션에 대한 인코딩된 유형을 식별하거나 얻는다.
또 다른 일 실시예에서, 시스템(120)은 규칙/정책 엔진(250)으로부터 애플리케이션에 대한 인코딩 스킴을 식별하거나 얻는다. 예를 들어, 애플리케이션 결정 메카니즘(235) 및/또는 분석기(240)는 소정의 애플리케이션에 대한 인코딩 유형을 얻도록 정책 엔진(250)에 질의할 수 있다. 몇몇 실시예들에서, 애플리케이션은 시간 정보, 클라이언트 정보, 사용자 정보, 장치 정보, 네트워크의 상태, 임의의 시스템의 상태, 이력 정보, 및/또는 통계적 정보에 기초하여 자신에게 결합된 복수의 인코딩 유형을 가질 수 있다. 일 실시예에서, 시스템(120)은 전술한 정보 중 하나 이상에 기초하여 규칙/정책 엔진(250)으로부터 애플리케이션에 대한 인코딩 유형을 요구한다. 예를 들어, 제1 애플리케이션은 주(week)의 제1 일(day)이나 시간에서의 제1 인코딩 유형 및 그 주의 제2 일이나 시간에서의 제2 인코딩 유형을 사용하거나 사용하도록 허용될 수 있다. 일 예로, 시스템(120)은, 애플리케이션의 네트워크 통신을 처리하는 데 사용될 인코딩 유형을 결정하도록, 식별한 애플리케이션 및 시간 정보에 대하여 정책 엔진(250)에 질의할 수 있다.
분석기(240)는, 네트워크 통신 또는 네트워크 통신의 임의의 부분을 분석하는 임의의 로직, 기능, 및/또는 동작을 포함한다. 일 실시예에서, 분석기(240)는 캐릭터 세트에서 인코딩된 요구와 같이 네트워크 통신의 그 부분을 디코딩한다. 몇몇 실시예들에서, 분석기(240)는, 파서(230) 또는 애플리케이션 결정 메카니즘(235)과 같이 캐릭터 세트 엔진(225)의 임의의 다른 부분으로부터 애플리케이션을 위해 사용할 인코딩 스킴을 얻을 수 있다. 다른 실시예들에서, 분석기(240)는 규칙/정책 엔진(250)으로부터 애플리케이션에 대한 인코딩 스킴을 얻는다. 일 실시예에서, 파서(230) 또는 애플리케이션 결정 메카니즘(235)은, 애플리케이션에 대한 인코딩 유형을 이용하여 디코딩된 네트워크 통신의 인코딩된 부분을 갖는 분석기(240)에 네트워크 통신을 제공한다.
일 실시예에서, 분석기(240)는 결합된 인코딩 유형 및/또는 애플리케이션의 식별을 이용하여, 네트워크 통신의 콘텐트를 검사하거나 분석한다. 몇몇 실시예들에서, 분석기(240)는 시스템(120)에 의해 수신된 네트워크 트래픽의 스트림에 대하여 단방향 분석 및 양방향 분석을 수행한다. 예를 들어, 분석기(240)는 네트워크 패킷들의 각각에 대하여 디프 스트림 검사(deep stream inspection)를 수행할 수 있다. 다른 실시예들에서, 분석기(240)는 HTTP 및 HTML 헤더 및 페이로드를 검사하고 분석한다. 일 실시예에서, 시스템(120)은 예를 들어 파서(230)를 통해 풀 HTML 파싱(full HMTL parsing)을 수행할 수 있고, 분석기(240)는 HTML 통신의 임의의 부분을 검사하고 분석할 수 있다. 다른 일 실시예에서, 분석기(240)는, 시스템(120)에 의해 수신되고 처리된 네트워크 트래픽의 세션 및 세션의 상태를 식별하고, 유지하며, 추적한다.
도 2를 참조해 보면, 시스템(120)은, 네트워크 통신의 검사, 필터링, 또는 분석에 기초하여 하나 이상의 정책들의 세트를 적용하기 위한 규칙/정책 엔진(250) 을 포함할 수도 있다. 일 실시예에서, 정책 엔진(250)은, 애플리케이션이 네트워크(204)에 액세스할 수 있게 하는 날짜, 시간, 또는 스케쥴에 관한 정책을 포함한다. 다른 일 실시예에서, 정책 엔진(250)은, 식별된 컴퓨팅 장치(100)나 식별된 사용자에 의해 애플리케이션이 사용될 수 있게 하는 날짜, 시간, 또는 스케쥴에 관한 정책을 포함한다. 또 다른 일 실시예에서, 정책 엔진(250)은, 애플리케이션을 위해 인코딩 스킴이 사용되거나 사용될 수 있게 하는 날짜, 시간, 또는 스케쥴에 관한 정책을 포함한다. 예를 들어, 사용자는, 주의 제1 일 동안 또는 제1 특정 시간 범위 동안 제1 애플리케이션이 제1 인코딩 스킴을 사용할 수 있고 그 주의 제2 일 동안 또는 제2 특정 시간 범위 동안 제2 인코딩 스킴을 사용할 수 있도록 시스템(120)의 규칙 또는 정책을 구성할 수 있다.
일 실시예에서, 시스템(120)은 엔드 포인트 검출 및 스캐닝 메커니즘을 포함하고, 이것은 클라이언트의 하나 이상의 속성이나 특징을 식별하고 결정한다. 예를 들어, 시스템(120)은, 1) 운영 체제 및/또는 운영 체제의 버전, 2) 운영 체제의 서비스 팩, 3) 실행중인 서비스, 4) 실행중인 프로세스, 5) 파일과 같은 클라이언트측 속성들 중 임의의 하나 이상을 식별하고 결정할 수 있다. 또한, 시스템(120)은, 클라이언트 상에 있는, 1) 안티바이러스 소프트웨어, 2) 개인 방화벽 소프트웨어, 3) 안티스팸 소프트웨어, 4) 인터넷 보안 소프트웨어 중 임의의 하나 이상의 존재 또는 버전을 식별하고 결정할 수 있다. 정책 엔진(250)은 클라이언트 속성들 또는 클라이언트의 속성들이나 특징들 중 임의의 하나 이상에 기초하여 하나 이상의 정책을 가질 수 있다. 몇몇 실시예들에서, 정책 엔진(250)은, 임의의 클라이언 트 속성에 기초하여 애플리케이션에 결합된 인코딩 스킴의 유형, 또는 애플리케이션을 위해 사용할 디코딩의 유형을 특정할 수 있다. 예를 들어, 정책 엔진(250)은, 클라이언트 상에서 실행중인 애플리케이션으로부터의 인코딩된 요구를 디코딩하도록 특정 언어에 결합된 인코딩 스킴이 사용되는 운영 체제의 그 특정 언어 버전을 그 클라이언트가 실행하고 있다면, 정책을 포함할 수 있다.
몇몇 실시예들에서, 규칙/정책 엔진(240)은, 1) 버퍼 오버플로우, 2) CGI-BIN 파라미터 조작, 3) 폼/히든 필드 조작, 4) 강제 브라우징, 5) 쿠키 또는 세션 포이즈닝(poisoning), 6) 손상된 액세스 제어 리스트(ACL) 또는 취약한 패스워드, 7) 크로스 사이트 스크립팅(XSS), 8) 커맨드 주입, 9) SQL 주입, 10) 에러 트리거링 민감 정보 누출, 11) 암호화의 불안정 사용, 12) 서버 오구성(misconfiguration), 13) 백 도어 및 디버그 옵션, 14) 웹사이트 손상(defacement), 15) 플랫폼 운영 체제 취약성, 16) 제로 데이 침해(zero-day exploit) 중 하나 이상과 같은 웹이나 인터넷 기반 취약성의 다양한 클래스 및 유형으로부터 보호를 제공하기 위한 하나 이상의 애플리케이션 방화벽 또는 보안 제어 정책을 포함한다. 일 실시예에서, 시스템(120)은, 1) 필요 필드가 리턴됨, 2) 허용된 추가 필드가 없음, 3) 판독 전용 및 히든 필드 실행, 4) 드랍다운 리스트 및 무선 버튼 필드 일치, 5) 폼 필드 최대 길이 실행 중 하나 이상에 대하여 네트워크 통신을 검사하거나 분석하는 형태로 HTML 폼 필드 보호를 제공한다. 몇몇 실시예들에서, 시스템(120)은 쿠키가 수정되지 않는 것을 보장한다. 다른 실시예들에서, 시스템(120)은 합법 URL을 실행함으로써 강제 브라우징으로부터 보호를 제공 한다.
또 다른 실시예들에서, 시스템(120)은 네트워크 통신 내에 포함된 임의의 기밀 정보를 보호한다. 시스템(120)은, 네트워크 패킷의 임의의 필드 내의 임의의 기밀 정보를 식별하도록 엔진(250)의 규칙이나 정책에 따라 임의의 네트워크 통신을 검사하거나 분석할 수 있다. 몇몇 실시예들에서, 시스템(120)은 네트워크 통신 내의 신용 카드 번호, 패스워드, 사회 보장 번호, 이름, 환자 코드, 연락 정보, 나이의 하나 이상의 발생(occurrence)을 식별한다. 네트워크 통신의 인코딩된 부분은 이러한 발생이나 기밀 정보를 포함할 수 있다. 이러한 발생에 기초하여, 일 실시예에서, 시스템(120)은 네트워크 통신의 송신을 방지하는 것처럼 네트워크 통신에 대하여 정책 액션을 취할 수 있다. 다른 실시예들에서, 시스템(120)은, 이러한 식별된 발생이나 기밀 정보를 재기입, 제거, 또는 마스킹할 수 있다.
애플리케이션 별로 시스템(120)의 인코딩 식별 및 디코딩 기능성을 이용함으로써, 분석기(240)와 정책 엔진(250)은 복수의 애플리케이션의 인코딩된 네트워크 통신에 애플리케이션 방화벽 및 보안 제어를 적용할 수 있고, 여기서 복수의 애플리케이션의 각각은 하나 이상의 서로 다른 인코딩 유형을 동시에 또는 후속하여 사용한다. 이처럼, 규칙/정책 엔진(250)에서 구성된 규칙과 정책은, 애플리케이션의 유형, 이름, 또는 인스턴스의 세분화(granularity) 및 본 명세서에서 설명하는 시스템의 동작에 따라 결정된 바와 같이 이러한 애플리케이션에 결합된 인코딩 스킴 둘 다에 적용될 수 있다. 게다가, 시스템(120)은, 인코딩 스킴을 알지 않고선 디코딩, 검사, 분석이 될 수 없는 네트워크 통신의 인코딩된 부분들의 분석을 허용한 다. 이렇게 함으로써, 시스템(120)은, 애플리케이션 별로 그리고/또는 인코딩 스킴 별로, 애플리케이션 방화벽 및 보안 정책과 같은 정책을, URL 인코딩된 콘텐트를 갖는 요구와 같은 네트워크 통신의 인코딩된 부분들에 적용할 수 있다.
파서(230), 애플리케이션 결정 메카니즘(235), 분석기(240)를 도 2에서 캐릭터 세트 엔진(225) 내에 포함된 것으로서 도시하고 있지만, 파서(230), 애플리케이션 결정 메카니즘(235), 분석기(240) 중 임의의 것, 또는 이들의 임의의 부분은, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120) 또는 장치(100)의 임의의 부분 내에 상주하고, 동작하고, 또는 실행할 수 있다. 또한, 하나의 논리적 엔티티 또는 컴포넌트로서 도시되어 있지만, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은, 제1 부분이 클라이언트와 같은 제1 장치(100a) 상에서 실행되고 제2 부분이 서버나 게이트웨이와 같은 제2 장치(100b) 상에서 실행되는 것처럼 분산 방식으로 동작할 수도 있다. 다른 예에서, 복수의 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(예를 들어, 120, 120')은, 하나 이상의 애플리케이션, 게이트웨이, 클라이언트, 또는 서버를 위해 본 명세서에서 설명하는 기능성과 기술을 제공하도록 서로 협동하여 또는 함께 동작할 수 있다.
애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)의 동작은 인코딩 스킴이나 캐릭터 인코딩 세트(charset)의 임의의 유형 및 폼을 지원할 수 있다. 몇몇 실시예들에서, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은, 예를 들어, UTF-7, UTF-8, CESU-8, UTF-16/UCS-2, UTF-32/UCS-4, UTF-EBCDIC, SCSU, Punycode, GB 18030을 포함하는 유니코드 스킴의 임의의 유형 및 폼으로 동작한다. 유니코 드(Unicode)는, 현재 사용중인 언어 및 사용되지 않는 언어들인, 서유럽어, 동유럽어, 키릴어, 그리스어, 아랍어, 히브리어, 중국어, 일본어, 한국어, 태국어, 우르두어, 힌디(Hindi)어, 및 기타 세계의 모든 주요 언어로부터의 캐릭터가 하나의 캐릭터 세트 내에 인코딩될 수 있게 하는 인코딩 스킴 또는 세트이다. 일 실시예에서, 캐릭터 세트는 16비트이다. 인코딩 스킴의 다른 실시예들에서, 캐릭터 세트는 6, 7, 8, 10, 12, 20, 24, 32, 또는 64비트이거나 다른 임의의 개수의 비트일 수 있다. 유니코드 명세는 전세계 현장 지원(worldwide locale support)을 위해 필요한 넓은 범위의 조판 정보 및 표준 압축 스킴도 포함한다. 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은, 유니버설 캐릭터 세트를 위한 여러 캐릭터 인코딩 폼을 정의하는 ISO 10646 표준 군을 이용하여 동작한다. 몇몇 실시예들에서, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은 ASCII 인코딩 스킴을 이용한다. 다른 실시예들에서, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은, 넌-ASCII 인코딩된 요구, 또는 그 일부에 대하여 동작한다. 또 다른 실시예에서, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은 ANSI나 WGL4 캐릭터 세트를 이용하여 요구에 대하여 자신의 동작을 수행한다.
몇몇 실시예들에서, 애플리케이션 캐릭터 세트 인코딩/디코딩 시스템(120)은, 임의의 방언들과 그 방언들의 차이를 비롯한 일본어, 한국어, 러시아어, 중국어와 같은 언어의 임의의 유형 및 폼을 지원하거나 이러한 유형 및 폼을 나타내는 데 사용되는 인코딩 스킴, 캐릭터 인코딩 세트 또는 캐릭터 세트, 그리고 이를 위해 사용되는 임의의 하나 또는 복수의 인코딩 스킴으로 동작한다. 예를 들어, 러 시아어에 있어서, 시스템(120)은, 1) 키릴어(CP1251), 2) KOI8r, KOI-8 대안, 통합된 KOI-8, 또는 KOI-8RU, 3) 유니코드 또는 UTF-8, 4) DosCyrillicRussian (CP866), 5) ISO.8859-5, 6) ECMA-키릴어(ISO-IR-111)와 같은 인코딩 스킴들 또는 캐릭터 세트들의 유형들로 동작할 수 있으나, 이러한 예로 제한하거나 배제하려는 의도는 없다.
예를 들어, 일본어에 있어서, 시스템(120)은 1) utf-8, 2) JIS (Japanese Industry Standard), 3) shift_jis (SJIS, X-SJIS 또는 MS Kanji로도 알려져 있음), 4) EUC/EUC-JP (확장된 유닉스 코드), 5) EBDIC, 6) ISO2022/ISO2022-JP, 7) ANSI Z39.64, 8) CCCII, 9)DEC Kanji, 10) GTcode, 11) IBM DBCS, 12) JEF (일본 확장 특징), 13) CCCII, 14) ISO-8850, 15) JIS X 0201 (JISROMAN), 16) JIS X 0208 (JIS C 6226), 17) JIS X 0212, JIS X 0213, 또는 JIS X 0221, 18) Mojikyo 와 같은 인코딩 스킴, 캐릭터 인코딩 세트(charset)로 동작할 수 있으나, 이러한 예로 제한하거나 배제하려는 의도는 없다. 예를 들어, 한국어에 있어서, 시스템(120)은 1) utf-8, 2) EUC, 또는 EUC-KR, 3) KEIS, 4) ANSI Z39.64, 5) ISO-2022, or ISO-2022- KR ,6) CCCII, 7) 통합된 한글 코드(CP949), 8) GB 12052, 7) IBM DBCS, 8) JOHAB, 9) KS C 5601, 10) KS C 5636 (KS ROMAN), 11) KS C 5657, 12) KS C 5700, and 13) Mojikyo 와 같은 인코딩 스킴이나 캐릭터 세트로 동작할 수 있으나, 이러한 예로 제한하거나 배제하려는 의도는 없다.
예를 들어, 중국어에 있어서, 시스템(120)은 1) utf-8, 2) ANSI Z39.64, 3) Big5, Big5+, Big5ETen, 또는 Big5- HKSCS 4) CCCII, 5) CNS 11643, 6) GBK (CP936), 7) CP90, 8) EUC/EUC- CN/EUC-TW, 9) GB 12050/12052, 10) GB13000-1, 11) GB13134, 12) GB16959, 13) GB18030, 14) GB1988, 15) GB2312, 16) GB7589, 17) GB7590, 18) GB8045, 19) GB/T 12345, GB/T 13131, 또는 GBT/13132, 20) HZ 21) ISO2022/2002-CN/CN- EXT, and 22) Mojikyo 와 같은 인코딩 스킴이나 캐릭터 세트로 동작할 수 있으나, 이러한 예로 제한하거나 배제하려는 의도는 없다.
시스템(120)은 어느 때라도 복수의 언어 및 복수의 인코딩 스킴을 서로 후속하게 이용하거나 동시에 이용하여 동작할 수 있다. 몇몇 실시예들에서, 시스템(120)은, 일본어, 한국어, 중국어에 대하여 동일한 인코딩을 이용하는 것처럼, 복수의 언어에 대하여 동일한 인코딩 스킴을 이용하여, 또는 일본어, 한국어, 중국어의 각각에 대한 서로 다른 인코딩 스킴들과 같이 복수의 언어의 각각에 대하여 서로 다른 인코딩 스킴들을 이용하여 동작할 수 있다.
이제 도 3을 참조해 보면, 애플리케이션에 결합된 인코딩 유형을 결정하거나 시스템(120)의 기술을 적용하기 위한 방법의 일 실시예가 도시되어 있다. 방법(300)을 간략히 살펴 보면, 단계 310에서, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은 요구를 수신한다. 단계 315에서, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은 요구가 복수의 애플리케이션 중 어떤 애플리케이션에 대응하는지를 결정한다. 단계 320에서, 애플리케이션 캐릭터 세트 인코딩/검사 시스템(120)은 결정된 애플리케이션에 결합된 인코딩 스킴을 식별한다. 단계 325에서, 시스템(120)은 식별한 인코딩 스킴을 이용하여 그 요구를 디코딩하고, 검사하고, 그리고/또는 분석한다. 요구를 디코딩하고 분석함에 따라, 단계 330에서, 애플리 케이션 캐릭터 세트 인코딩/검사 시스템(120)은 하나 이상의 정책을 요구에 적용할 수 있다.
구체적으로, 단계 310에서, 시스템(120)은 임의의 수단 및/또는 메커니즘에 의해 요구와 같은 네트워크 통신을 수신하거나 인터셉트할 수 있다. 일 실시예에서, 수신기(210)는 클라이언트(101)로부터 요구를 수신한다. 다른 일 실시예에서, 수신기(210)는 요구가 서버(106)와 통신할 때 네트워크 스택(210)으로부터 그 요구를 인터셉트한다. 몇몇 실시예들에서, 수신기(210)와 같은 시스템(120)은, 네트워크 드라이버, 네트워크 스택(210)에서 요구를 인터셉트하기 위한 필터 또는 후킹 메커니즘을 포함한다. 몇몇 실시예들에서, 시스템(120)을 배치하는 게이트웨이(105)는 요구를 수신하거나 인터셉트한다. 다른 실시예들에서, 클라이언트(101)는, 클라이언트(101)를 위한 프록시로서 기능하는 게이트웨이(105)에 요구를 송신하도록 구성된다. 다른 실시예들에서, 시스템(120)을 배치하는 서버(106) 또는 클라이언트(101)는 클라이언트(101)로부터의 요구를 수신하거나 인터셉트한다. 몇몇 실시예들에서, 시스템(120)은 캐싱된 폼 페이지를 수신한다. 다른 일 실시예에서, 시스템(120)은, 게이트웨이(105)와 같이 시스템(120)을 구현하는 장치 또는 시스템(120)의 캐시에 저장되어 있는 캐싱된 폼 페이지를 이용한다.
몇몇 실시예들에서, 시스템(120)은 요구에 의해 사용되는 인코딩 스킴의 사전 지식을 갖지 않는다. 일 실시예에서, 요구 자체는 요구의 인코딩된 부분을 위해 사용되는 인코딩 스킴을 식별하지 못한다. 예를 들어, 일 실시예에서, 요구는 폼-URL-인코딩된 콘텐트 유형을 이용하여 HTML 폼과 같은 폼의 제출을 포함한다. 다른 일 실시예에서, 요구는 캐릭터 인코딩을 식별하는 태그를 제공하지 않는다. 또 다른 실시예에서, 요구는 인코딩 시스템의 식별을 포함한다. 다른 일 실시예에서, 시스템(120)은 발견적(heuristic) 규칙이나 로직을 이용하여 인코딩된 유형을 추측함으로써 요구에 대한 인코딩 스킴을 이해한다. 몇몇 실시예들에서, 시스템(120)은 애플리케이션 또는 클라이언트의 거동(behavior)에 기초하여 인코딩 스킴을 결정할 수 있다. 일 실시예에서, 시스템은, 시스템(120), 게이트웨이(105), 서버(106), 및/또는 클라이언트(101) 사이에 알려져 있는 인코딩 스킴을 이용하는 것에 기초하여 인코딩 스킴을 결정한다.
단계 315에서, 시스템(120)은 요구가 복수의 애플리케이션 중 어느 하나에 대응하는지를 결정한다. 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 파서(230)에 의해서와 같이 요구로부터 파싱된 그리고/또는 식별된 하나 이상의 데이터 요소로부터 애플리케이션을 결정한다. 몇몇 실시예들에서, 애플리케이션 결정 메카니즘(235)은, 인터넷 프로토콜 어드레스 및/또는 포트를 데이터베이스, 테이블, 파일, 오브젝트, 데이터 구조나 기타 저장 매체로부터의 대응 애플리케이션의 룩업에 매핑함으로써 요구에 결합되거나 요구를 생성하는 애플리케이션을 결정한다. 일 실시예에서, 애플리케이션 결정 메카니즘(235)은 애플리케이션을 이름, 유형, 또는 인스턴스에 의해 식별하는 요구의 페이로드 내의 데이터 요소로부터 그 애플리케이션을 결정한다.
단계 320에서, 캐릭터 세트 엔진(225)과 같은 시스템(120)은 단계 315에서 결정된 애플리케이션을 위한 인코딩 스킴 또는 캐릭터 세트를 식별한다. 일 실시 예에서, 애플리케이션 결정 메카니즘(235)이나 분석기(240)를 통해서처럼 캐릭터 세트 엔진(225)은, 애플리케이션을 하나 이상의 인코딩 스킴에 매핑하는 데이터베이스, 파일, 테이블, 오브젝트, 데이터 구조, 또는 기타 저장 매체로부터 그 애플리케이션을 위한 인코딩 스킴의 룩업을 질의하거나 수행한다. 다른 일 실시예에서, 캐릭터 세트 엔진(225)은 요구의 임의의 부분으로부터 애플리케이션을 위한 인코딩 스킴을 결정한다. 일 실시에에서, 캐릭터 세트 엔진(225)은 파서(230)에 의해 파싱되거나 식별된 하나 이상의 데이터 요소를 위한 인코딩 스킴을 식별한다. 몇몇 실시예들에서, 캐릭터 세트 엔진(225)은 애플리케이션에 결합된 인코딩 스킴을 저장하는 캐시, 메모리, 또는 저장 요소로부터 그 애플리케이션을 위한 인코딩 스킴을 식별한다. 예를 들어, 일 실시예에서, 캐릭터 세트 엔진(225)은 애플리케이션을 위한 이전에 사용된 인코딩 스킴을 추적한다. 다른 일 실시예에서, 캐릭터 세트 엔진(225)은, 캐릭터 세트를 식별하는 정보를 갖는, 클라이언트 요구에 대한 응답과 같은 네트워크 통신으로부터, 애플리케이션을 위한 인코딩 스킴을 식별한다. 예를 들어, 일 실시예에서, 시스템(120)은 서버의 네트워크 통신으로부터 이러한 정보를 식별하고 파싱한다.
몇몇 실시예들에서, 캐릭터 세트 엔진(225)은, 애플리케이션 결정 메카니즘(235)이나 분석기(240)를 통해서, 규칙/정책 엔진(250)으로부터 애플리케이션을 위해 사용할 인코딩 스킴을 얻는다. 예를 들어, 정책 엔진(250)은 날짜와 시간처럼 요구에 관한 임의의 시간 정보에 기초하여 애플리케이션을 위해 사용할 인코딩 스킴을 특정할 수 있다. 다른 예에서, 정책 엔진(250)은 요구를 통신하는 클라이 언트의 속성이나 임의의 시스템 정보에 기초하여 애플리케이션을 위해 사용할 인코딩 스킴을 특정할 수 있다. 일 실시예에서, 시스템(120)은 엔드 포인트 검출 및 클라이언트의 스캔을 수행하고 그 클라이언트의 하나 이상의 속성이나 특징을 결정한다. 정책 엔진(250)은 클라이언트의 임의의 속성에 기초하여 하나 이상의 정책을 요구에 또는 그 요구의 인코딩된 부분의 디코딩에 적용할 수 있다. 예를 들어, 정책 엔진(250)은 클라이언트가 소정의 유형의 운영 체제를 실행하고 있다면 애플리케이션을 위한 제1 유형의 인코딩 스킴을 특정할 수 있다.
단계 325에서, 시스템(120)은 인코딩 스킴의 식별을 이용하여 요구의 인코딩 부분을 디코딩한다. 일 실시예에서, 캐릭터 세트 엔진(225)은, 파서(230), 애플리케이션 결정 메카니즘(235), 및/또는 분석기(240)를 통해, 식별한 인코딩 스킴을 요구의 인코딩된 부분에 적용한다. 이처럼, 분석기(240)는, 인코딩된 부분을 분석기(240)에 의해 검사되거나 분석될 수 있는 데이터 요소, 텍스트, 또는 스트링으로 디코딩한다. 예를 들어, 일 실시예에서, 요구의 디코딩된 부분은 서버(106) 상에서 실행될 SQL 또는 다른 유형의 커맨드를 형성할 수 있다. 몇몇 실시예들에서, 분석기(240)는 디코딩된 콘텐트를 포함하는 요구를 검사하거나 분석하여, 요구가 규칙/정책 엔진(250)을 통해 구성된 규칙 및/또는 정책을 충족하는지 위반하는지를 결정한다. 도 2와 함께 전술한 바와 같이, 분석기(240)는 양방향 분석, 디프 스트림 검사, HTML 검사, 세션 상태 관리, HTML 폼 필드 보호, 쿠키 포이즈닝 보호, 강제 브라우저 보호, 웹 취약성 보호와 같은 임의의 로직, 기능, 동작을 수행할 수 있다.
단계 330에서, 시스템(120)은 디코딩된 요구의 분석에 기초하여 하나 이상의 규칙이나 정책을 요구에 적용한다. 일 실시예에서, 요구가 네트워크(104) 상에서의 송신(또는 네트워크(104)상에서의 추가 전송)을 위해 정책 엔진(250)의 정책을 만족하지 않으면, 게이트웨이(105) 내에 배치된 시스템(120)과 같은 시스템(120)은 요구를 거절하거나 드롭(drop)할 수 있다. 다른 일 실시예에서, 시스템(120)은 요구가 정책에 실패하면 애플리케이션 또는 그 애플리케이션의 사용자를 고립시킬 수 있다. 또 다른 일 실시예에서, 시스템(120)은 요구가 정책에 실패하면 애플리케이션의 네트워크 액세스를 다운그레이드하거나 제한할 수 있다. 다른 실시예들에서, 시스템(120)은 클라이언트의 SSL VPN 연결을 해제하는 것처럼 클라이언트의 네트워크(104)와의 연결을 해제할 수 있다. 몇몇 실시예들에서, 시스템(120)은 요구가 정책에 실패하거나 만족하지 못하면 애플리케이션 세션을 해제하거나 종료할 수 있다.
방법(300)의 기술을 일반적으로 애플리케이션으로부터의 요구의 문맥으로 설명하고 있지만, 방법(300)은 서로 후속하여 그리고/또는 동시에 복수의 애플리케이션을 위해 수행될 수 있다. 시스템(120)은 서로 다른 애플리케이션들로부터 단계 310에서의 복수의 요구를 수신하거나 인터셉트할 수 있고, 여기서 각 애플리케이션은 다른 애플리케이션과 동일하거나 다른 인코딩 스킴을 이용하여 인코딩된 부분을 갖는다. 예를 들어, 시스템(120)은 복수의 클라이언트와 애플리케이션에게 서비스를 제공하는 게이트웨이(105) 상에 배치될 수 있다. 복수의 요구의 각 요구에 대하여, 시스템(120)은, 단계 315에서 요구에 결합된 애플리케이션, 단계 320에서 애 플리케이션을 위해 사용될 캐릭터 세트 인코딩을 결정하고, 단계 325에서 요구의 인코딩된 부분을 디코딩하고 디코딩된 부분을 분석하며, 단계 330에서 임의의 결합된 정책을 요구에 적용한다. 이처럼, 몇몇 실시예들에서, 시스템(120)은 애플리케이션 별로 방법(300)의 기술을 수행하고, 결합된 인코딩 스킴을 요구 별로 적용한다. 일 실시예에서, 시스템(120)은 제1 요구에 대하여 애플리케이션을 위한 제1 인코딩 스킴을 이용할 수 있고, 제2 및 후속 요구에 대하여 동일한 애플리케이션을 위한 다른 제2 인코딩 스킴을 이용할 수 있다.
예
애플리케이션 인코딩/검사 시스템(120)은, 서로 다른 캐릭터 세트들이나 인코딩 스킴들을 이용하는 복수의 애플리케이션을 갖는 기업 네트워크(104)를 위한 네트워크 어플라이언스 또는 게이트웨이 내에 배치될 수 있다. 예를 들어, 게이트웨이(105)는 일본어 사용자를 갖는 법인 네트워크를 위한 애플리케이션 방화벽 및 보안 제어 장치로서 배치될 수 있다. 제1 클라이언트(101a) 상의 제1 애플리케이션(110a)은 UTF-8의 제1 캐릭터 세트를 이용할 수 있다. 제1 클라이언트(101a) 또는 제2 클라이언트(101b) 상의 제2 애플리케이션(110b)은 JIS의 제2 캐릭터 세트를 이용할 수 있다. 제1 클라이언트(101a) 또는 제2 클라이언트(101b), 혹은 제3 클라이언트(101c) 상의 제3 애플리케이션(110c)은 MS Kanji의 제3 캐릭터 세트를 이용할 수 있다.
제1 애플리케이션(110a), 제2 애플리케이션(110b), 제3 애플리케이션(110c)의 각각은 게이트웨이(105)를 통해 하나 이상의 요구를 하나 이상의 서버(106a- 106n)에 제출한다. 애플리케이션(110a-110c)은 웹 서버(106a-106n)에 HTTP5 HTML 및/또는 XML 요구를 제출하는 웹 브라우저를 포함할 수 있다. 이러한 요구 중 임의의 하나 이상은, 캐릭터 세트의 식별이 제출된 데이터의 일부가 아닌 폼-URL-인코딩된 제출을 포함할 수 있다. 이 요구들 중 일부는, Javascript 또는 브라우저 상의 기타 스크립트로부터 전적으로 또는 다른 방식으로 생성될 수 있다. 또한, 이 요구들 중 하나 이상은, AJAX (또는 Asynchronous JavaScript 및 XML) 기반 기술을 이용하여 생성될 수 있다. 이처럼, 이러한 하나 이상의 요구에 대하여, 게이트웨이(105)는 요구의 일부분을 인코딩하는 데 사용되는 캐릭터 세트의 사전 지식을 갖지 않을 수 있다.
전술한 시스템(120)의 구조, 기능, 동작을 참조해 보면, 게이트웨이(105)는 요구의 인코딩된 부분에 애플리케이션 방화벽 및 보안 제어 정책을 적용할 수 있다. 수신한 요구 각각에 대하여, 게이트웨이(105)는 요구에 결합된 애플리케이션 및 애플리케이션에 결합된 인코딩 스킴을 결정한다. 이 예에서, 게이트웨이(105)는 제1 요구가 제1 애플리케이션(110a)으로부터 수신된 것임을 결정하고, UTF-8 인코딩 스킴을 제1 애플리케이션(110a)에 결합된 것으로서 식별한다. 게이트웨이(105)는 제1 요구를 UTF-8의 인코딩 스킴으로 디코딩하고, 디코딩한 요구를 분석하며, 임의의 정책을 그 요구에 적용한다. 게이트웨이(105)는 제2 요구가 제2 애플리케이션(110b)으로부터 수신된 것임을 결정하고, JIS 인코딩 스킴을 제2 애플리케이션(110b)에 결합된 것으로서 식별한다. 게이트웨이(105)는 식별한 인코딩 스킴으로 제1 요구를 디코딩하고, 디코딩한 요구를 분석하며, 임의의 정책을 그 요구 에 적용한다. 마찬가지로, 게이트웨이(105)는 제3 요구가 제3 애플리케이션(110c)으로부터 수신된 것임을 결정하고, MS Kanji 인코딩 스킴을 제3 애플리케이션(110c)에 결합된 것으로서 식별한다. 게이트웨이(105)는 제3 요구를 MS Kanji의 식별한 인코딩 스킴으로 디코딩하고, 디코딩한 요구를 분석하며, 임의의 정책을 그 요구에 적용한다.
몇몇 경우에, 애플리케이션(110a)은, 예를 들어, 다른 시간 주기나 다른 일 동안 다른 인스턴스의 시작시 다른 인코딩 스킴으로 스위칭하거나 이 다른 인코딩 스킴을 이용할 수 있다. 예를 들어, 제1 애플리케이션(110a)은 이 제2 인스턴스 동안 UTF-8 대신에 JIS 캐릭터 세트를 이용할 수 있다. 이러한 경우, 게이트웨이(105)는, 제1 애플리케이션(110a)으로부터 후속 요구가 수신되는 것을 결정하며, UTF-8 인코딩 스킴을 제1 애플리케이션(110a)에 결합된 것으로서 식별한다. 예를 들어, 정책 엔진(250)은, 특정한 시간 주기 동안 UTF-8 인코딩 스킴이 제1 애플리케이션(110a)을 위해 이용되어야 함을 식별할 수 있다. 이어서, 게이트웨이(105)는 이 후속 요구를 UTF-8의 식별된 인코딩 스킴으로 디코딩하고, 디코딩한 요구를 분석하며, 임의의 정책을 그 요구에 적용한다.
본 명세서에서 설명한 게이트웨이(105)를 이용하면, 게이트웨이는, 서로 다른 인코딩 스킴들을 이용하여 정책을 디코딩하고, 분석하며, 복수의 애플리케이션으로부터의 요구에 적용할 수 있다. 게이트웨이(105)는, 일본어, 한국어, 러시아어, 또는 중국어로 애플리케이션의 사용자에게 배치된 네트워크 환경에서 찾을 수 있는 듯이 정책을 복수의 서로 다른 캐릭터 세트 인코딩된 애플리케이션을 배치하 는 환경에 적용하기 위해, 애플리케이션 별로 그리고 요구 별로 디코딩 메커니즘을 제공한다는 점에서 상당한 유연성을 제공한다. 게이트웨이(105)는, 네트워크 환경을 인코딩된 콘텐트에서 발견될 수 있는 취약성 및 보안 우려로부터 보호하기 위해 애플리케이션 방화벽 및 보안 제어 장치를 서로 다르게 인코딩된 네트워크 통신들에 적용할 수 있게 한다.
당업자라면 본 발명의 사상 및 범위로부터 벗어나지 않고서 많은 변경 및 수정을 행할 수 있다. 따라서, 예시한 실시예은 단지 예를 든 것이며 다음에 따르는 청구범위에 의해 정의되는 본 발명을 한정하는 것으로 해석하지 않아야 함을 분명히 이해하기 바란다. 이러한 청구범위는, 글자 그대로 설명하는 바 및 상술한 예에서 도시하고 설명한 것에 대하여 다른 면에서 동일하지 않더라도 거의 같은 등가 요소들을 포함하는 것으로서 읽어야 한다.

Claims (22)

  1. 요구를 디코딩하는 데 사용되는 캐릭터 인코딩을 결정하는 방법으로서,
    (a) 요구를 수신하는 단계와,
    (b) 상기 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계와,
    (c) 결정된 애플리케이션 프로그램에 결합(associate)된 캐릭터 인코딩을 식별하는 단계와,
    (d) 식별한 상기 캐릭터 인코딩을 이용하여 상기 요구를 검사하는 단계
    를 포함하는 캐릭터 인코딩 결정 방법.
  2. 제 1 항에 있어서,
    상기 (b) 단계는, 상기 요구의 속성으로부터 상기 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  3. 제 2 항에 있어서,
    상기 속성은, 소스 식별자, 대상(destination) 식별자, 포트 식별자, 프로토콜 식별자, 헤더 정보, 유니폼 리소스 로케이터(URL) 어드레스 중 하나를 포함하는 캐릭터 인코딩 결정 방법.
  4. 제 1 항에 있어서,
    상기 (b) 단계는, 수신한 상기 요구 내에 포함된 쿠키(cookie)를 이용하여 상기 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  5. 제 1 항에 있어서,
    상기 (c) 단계는, 캐릭터 인코딩과 애플리케이션 사이의 결합을 포함하는 파일을 이용하여 상기 결정된 애플리케이션 프로그램에 결합된 상기 캐릭터 인코딩을 식별하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  6. 제 1 항에 있어서,
    상기 (c) 단계는, 캐릭터 인코딩과 애플리케이션 사이의 결합을 포함하는 데이터베이스를 이용하여 상기 결정된 애플리케이션 프로그램에 결합된 상기 캐릭터 인코딩을 식별하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  7. 제 1 항에 있어서,
    (a) 제2 요구를 수신하는 단계와,
    (b) 상기 복수의 애플리케이션 프로그램 중 상기 제2 요구에 대응하는 제2 애플리케이션 프로그램을 결정하는 단계와,
    (c) 결정된 상기 제2 애플리케이션 프로그램에 결합된 제2 캐릭터 인코딩을 식별하는 단계
    를 더 포함하는 캐릭터 인코딩 결정 방법.
  8. 제 1 항에 있어서,
    상기 (a) 단계는 클라이언트에 의해 생성된 요구를 수신하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  9. 제 8 항에 있어서,
    상기 (b) 단계는, 상기 클라이언트의 속성을 이용하여 상기 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  10. 제 1 항에 있어서,
    상기 (a) 단계는 캐싱된 폼 페이지(cached form page)에 기초하여 요구를 수신하는 단계를 포함하는 캐릭터 인코딩 결정 방법.
  11. 요구를 디코딩하는 데 사용되는 캐릭터 인코딩을 결정할 수 있는 게이트웨이로서,
    네트워크를 통해 클라이언트와 통신하고 상기 클라이언트로부터 요구를 수신 하는 수신기와,
    상기 수신기와 통신하며, 상기 요구가 지향하고 있는 애플리케이션에 응답하여 수신한 요구에 결합된 캐릭터 인코딩을 식별하고 식별한 상기 캐릭터 인코딩을 이용하여 상기 요구를 검사하는 캐릭터 세트 엔진(character set engine)
    을 포함하는 게이트웨이.
  12. 제 11 항에 있어서,
    상기 수신기는 복수의 클라이언트와 통신하는 게이트웨이.
  13. 제 11 항에 있어서,
    상기 요구 내에 포함된 소스 식별자, 대상 식별자, 포트 식별자, 프로토콜 식별자, 헤더 정보, 유니폼 리소스 로케이터 어드레스 중 하나를 이용하여, 상기 요구가 지향하고 있는 애플리케이션 프로그램을 결정하는 게이트웨이.
  14. 제 11 항에 있어서,
    상기 캐릭터 세트 엔진은 캐릭터 인코딩과 애플리케이션을 결합하는 데이터베이스를 포함하는 게이트웨이.
  15. 제 11 항에 있어서,
    상기 캐릭터 세트 엔진은 캐릭터 인코딩과 애플리케이션을 결합하는 파일을 포함하는 게이트웨이.
  16. 클라이언트로부터 수신한, 인코딩된 부분을 갖는 요구를, 게이트웨이에 의해 검사하는 방법으로서,
    (a) 게이트웨이에 의해, 클라이언트 상의 애플리케이션 프로그램으로부터 요구를 수신하는 단계와,
    (b) 상기 게이트웨이에 의해, 상기 요구가 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계와,
    (c) 상기 게이트웨이에 의해, 결정된 상기 애플리케이션 프로그램에 결합된 캐릭터 인코딩을 식별하는 단계와,
    (d) 상기 게이트웨이에 의해, 식별한 상기 캐릭터 인코딩을 이용하여 상기 요구의 일부분을 디코딩하는 단계와,
    (e) 상기 게이트웨이에 의해, 상기 요구의 디코딩한 일부분을 검사하는 단계
    를 포함하는 검사 방법.
  17. 제 16 항에 있어서,
    상기 게이트웨이에 의해, 상기 요구의 속성을 이응하여 상기 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계를 포함하는 검사 방법.
  18. 제 16 항에 있어서,
    상기 게이트웨이에 의해, 상기 클라이언트의 속성을 이용하여 상기 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계를 포함하는 검사 방법.
  19. 제 16 항에 있어서,
    상기 게이트웨이에 의해, 상기 요구의 디코딩한 일부분의 검사에 기초하여 상기 요구에 정책을 적용하는 단계를 포함하는 검사 방법.
  20. 제 16 항에 있어서,
    (f) 상기 게이트웨이에 의해, 상기 클라이언트 및 제2 클라이언트 중 하나 상의 제2 애플리케이션 프로그램으로부터 제2 요구를 수신하는 단계와,
    (g) 상기 게이트웨이에 의해, 상기 제2 요구가 상기 복수의 애플리케이션 프로그램 중 어느 하나에 대응하는지를 결정하는 단계와,
    (h) 상기 게이트웨이에 의해, 결정된 애플리케이션 프로그램에 결합된 제2 캐릭터 인코딩을 식별하는 단계와,
    (i) 상기 게이트웨이에 의해, 식별한 상기 제2 캐릭터 인코딩을 이응하여 상기 제2 요구의 일부분을 디코딩하는 단계
    를 포함하는 검사 방법.
  21. 제 20 항에 있어서,
    상기 게이트웨이에 의해, 상기 제2 요구의 디코딩한 일부분을 검사하는 단계를 포함하는 검사 방법.
  22. 제 21 항에 있어서,
    상기 게이트웨이에 의해, 상기 제2 요구의 디코딩한 일부분의 검사에 기초하여 정책을 상기 제2 요구에 적용하는 단계를 포함하는 검사 방법.
KR1020087029166A 2006-05-31 2008-11-28 게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법 KR101265920B1 (ko)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2006/021067 WO2007139552A1 (en) 2006-05-31 2006-05-31 Systems and methods for determining the charset encoding for decoding a request submission in a gateway

Publications (2)

Publication Number Publication Date
KR20090031350A true KR20090031350A (ko) 2009-03-25
KR101265920B1 KR101265920B1 (ko) 2013-05-20

Family

ID=37708569

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020087029166A KR101265920B1 (ko) 2006-05-31 2008-11-28 게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법

Country Status (5)

Country Link
JP (1) JP4862079B2 (ko)
KR (1) KR101265920B1 (ko)
CN (1) CN101449553B (ko)
HK (1) HK1133964A1 (ko)
WO (1) WO2007139552A1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160070902A (ko) * 2014-12-10 2016-06-21 한국전자통신연구원 데이터 암호화 장치 및 방법

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8234379B2 (en) 2006-09-14 2012-07-31 Afilias Limited System and method for facilitating distribution of limited resources
US8254381B2 (en) * 2008-01-28 2012-08-28 Microsoft Corporation Message processing engine with a virtual network interface
WO2009111870A1 (en) * 2008-03-10 2009-09-17 Afilias Limited Alternate e-mail address configuration
CN102750185B (zh) * 2011-04-18 2018-05-22 腾讯科技（深圳）有限公司 一种数据自适应输出方法及系统
CN102395057B (zh) * 2011-06-30 2017-10-13 中兴通讯股份有限公司 一种端口定位格式的配置方法及装置
US9779066B2 (en) 2015-05-21 2017-10-03 Umm Al-Qura University Method and system for converting punycode text to ASCII/unicode text

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3203544B2 (ja) * 1996-01-31 2001-08-27 日本電信電話株式会社 テキスト最尤復号方法及び最尤復号装置と、データ通信ネットワーク装置
JPH09319545A (ja) * 1996-05-30 1997-12-12 Mitsubishi Electric Corp 文字入力装置
JPH1020989A (ja) * 1996-07-08 1998-01-23 Hitachi Ltd 文字入力装置
JP2000132449A (ja) * 1998-10-27 2000-05-12 Nippon Telegr & Teleph Corp <Ntt> 代理アクセス方法、装置、および代理アクセスプログラムを記録した記録媒体
JP2000132480A (ja) * 1998-10-27 2000-05-12 Nippon Telegr & Teleph Corp <Ntt> インターネット閲覧方法、装置、およびインターネット閲覧プログラムを記録した記録媒体
JP3278406B2 (ja) * 1998-12-10 2002-04-30 富士通株式会社 ドキュメント検索仲介装置、ドキュメント検索システム、および、ドキュメント検索仲介プログラムを記録した記録媒体
US6751654B2 (en) * 1999-03-31 2004-06-15 International Business Machines Corporation Simulating web cookies for non-cookie capable browsers
WO2001033752A1 (en) * 1999-11-03 2001-05-10 Measurecast, Inc. Direct tracking of viewers of selected content in audio and video programming provided over a computer network
US6944760B2 (en) * 2001-05-24 2005-09-13 Openwave Systems Inc. Method and apparatus for protecting identities of mobile devices on a wireless network
JP2003203032A (ja) * 2002-01-08 2003-07-18 Fujitsu Ltd ウェブサーバ仲介装置、方法および対話型ウェブサーバ仲介ポータルサーバ
US20040073811A1 (en) * 2002-10-15 2004-04-15 Aleksey Sanin Web service security filter
JP4378342B2 (ja) * 2003-05-17 2009-12-02 マイクロソフト コーポレーション マルチパートファイルに変換を適用する機構
US7716726B2 (en) * 2004-02-13 2010-05-11 Microsoft Corporation System and method for protecting a computing device from computer exploits delivered over a networked environment in a secured communication

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160070902A (ko) * 2014-12-10 2016-06-21 한국전자통신연구원 데이터 암호화 장치 및 방법

Also Published As

Publication number Publication date
JP2009539176A (ja) 2009-11-12
WO2007139552A1 (en) 2007-12-06
KR101265920B1 (ko) 2013-05-20
CN101449553A (zh) 2009-06-03
CN101449553B (zh) 2013-04-17
JP4862079B2 (ja) 2012-01-25
HK1133964A1 (en) 2010-04-09

Similar Documents

Publication Publication Date Title
US7873994B1 (en) Management of session timeouts in an SSL VPN gateway
US8326923B1 (en) Smart prefetching of data over a network
JP4912400B2 (ja) Ｈｔｍｌブラウザおよび拡張機能の既知の脆弱性からの免疫付与
KR101265920B1 (ko) 게이트웨이에서 요구 제출을 디코딩하도록 캐릭터 세트 인코딩을 결정하는 시스템 및 방법
US7840707B2 (en) Reverse proxy portlet with rule-based, instance level configuration
US8904475B2 (en) Method and system for authorizing a level of access of a client to a virtual private network connection, based on a client-side attribute
EP2241082B1 (en) Systems and methods for configuration and fine grain policy driven web content detection and rewrite
US8464311B2 (en) Method and system for implementing privacy notice, consent, and preference with a privacy proxy
CN101523865B (zh) 用于使用http-察觉的客户端代理的系统和方法
US8613045B1 (en) Generating secure roaming user profiles over a network
US11265295B2 (en) Object property getter and setter for clientless VPN
US20060206589A1 (en) Method and systems for providing access to dynamic content via static pages
US20190116186A1 (en) Enterprise cloud access control and network access control policy using risk based blocking
CN115315926A (zh) 用于实现基于应用层和基于传输层的安全规则的反向代理服务器
US11520852B2 (en) Encoding-free javascript stringify for clientless VPN
US20120215887A1 (en) Secure delivery of flash content over networks
JP5039053B2 (ja) マクロ・サポートによりｈｔｔｐセキュリティ・メッセージ処理を外部化するための方法およびシステム
US20210073297A1 (en) Browser storage for clientless vpn
US8959216B2 (en) Channel manager for accessing elements for a secure web page through a non-secure channel
Adamczyk et al. Non-compliant and proud: A case study of HTTP compliance
Kizza et al. Scripting and Security in Computer Networks and Web Browsers

Legal Events

Date Code Title Description
A201 Request for examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160419

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20170420

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20180427

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20190425

Year of fee payment: 7