KR101201003B1 - 데이터의 출처 추적 및 데이터 전송 제어 - Google Patents

Abstract

데이터의 출처들(origins)을 추적하고 그 데이터의 전송을 제어하기 위한 방법, 장치 및 컴퓨터 프로그램이 제공된다. 일 실시예에서, 스크립트 동작들에 의한 민감한 데이터의 전송은, 그 민감한 데이터의 소스로의 전송을 제외하고는 다른 네트워크 위치로 전송하는 것을 방지하기 위해, 그 데이터 내에 배치된 출처 태그들에 응답하는 HTTP 클라이언트의 스크립팅 엔진 내의 새로운 기능에 의해, 제한된다. 데이터 입력들과 연관되는 출처 태그들은 어떤 출력 데이터 항목들로 전파되어, 파생된(derived) 정보의 전송이 또한 제어될 수 있다.

Description

데이터의 출처 추적 및 데이터 전송 제어{TRACKING THE ORIGINS OF DATA AND CONTROLLING DATA TRANSMISSION}

본 발명은 웹 브라우저와 같은 스크립트가능한(scriptable) 클라이언트들에 대해, 데이터의 출처(origins)를 추적(tracking)하고 민감한(sensitive) 데이터의 전송을 제어하기 위한 방법, 데이터 처리 장치 및 컴퓨터 프로그램을 제공한다.

웹 브라우저들은 사용자의 데이터 처리 장치 상에서 실행되고 WWW(World Wide Web) 상의 정보에 대한 접근 - 웹 페이지들을 검색하고 서핑하거나 웹 페이지 콘텐츠들과 인터랙트(interact)하기 위해 HTTP(HyperText Transfer Protocol)를 사용하여 웹 서버 컴퓨터들로 요청들을 보내는 것 - 을 제공한다. 일부 웹 브라우저들 및 유사 HTTP 클라이언트들은 스크립트 언어들(script languages)을 인터프리트(interpret)할 수 있다. 비록 VBScript(Visual Basic Scripting Edition)가 일부 웹 브라우즈들에 의해 인터프리트되고 그 메커니즘이 다른 언어들로 확장가능하지만, 일반적으로는 JavaScript^TM 가 사용된다. 페이지의 텍스트에 스크립팅 언어 명령들(scripting-language instructions)을 포함함에 의해, 제작자들(authors)은, 그 페이지가 적절하게 기능하는 브라우저(suitably-capable browser)를 가지고 보여질 경우, 임의의 복잡한 동작을 보이도록 할 수 있고, 및/또는 정적인 문서(static document)로 보여지도록 할 수 있다. 그러한 명령들은 직접적으로 포함될 수 있거나, 혹은 그 명령들이 포함된 별개의(separate) 파일을 참조함으로써 포함될 수 있다.

웹 페이지에 내포된(embedded) 스크립트 명령들은 브라우저 내의 "스크립팅 엔진(scripting engine)" 또는 서브시스템(subsystem)에 의해 인터프리트된다. 이 엔진 자체는 프로그래밍 언어, 일반적으로는 C++ 또는 Java^TM과 같은 더 구조화된 언어(structured language)로 쓰여진다. 상기 엔진은 다수의 동작들을 수행할 수 있고, 각각의 스크립팅 언어 명령은 글자 그대로 상기 엔진의 이용가능한 동작들 중 특정한 하나를 수행하기 위한 상기 엔진으로의 명령이다.

상기 스크립팅 엔진은 또한 브라우저 내에서 웹 페이지 자체를 표현하는 데이터 구조들에 접근한다. 상기 엔진에 의해 수행될 수 있는 특정 동작들은 이들 데이터 구조들로부터 읽는 것 또는 이들 데이터 구조들에 쓰는 것, 브라우저에 보여진 페이지를 효과적으로 편집하는 것을 포함한다. 스크립팅 동작들에 사용될 수 있는 데이터의 다른 소스들은 스크립트 변수들(script variables)(이 스크립트 변수들은 초기값으로 설정되거나 다른 어떤 소스로부터 채워질 수 있음), 및 "XMLHttpRequest"로 알려진 기술을 사용하여 개별적으로 다운로드된 다른 데이터를 포함한다.

상기 스크립팅 엔진 내에서 엄격하게 정보를 처리할 뿐만 아니라 웹 페이지의 내부 표현(internal representation)으로써 정보를 교환할 때, 브라우저로 하여금 그것의 네트워크 연결을 통해 다른 시스템들과 인터랙트(interact)하도록 하거나 인간 사용자에 의해 정상적으로 명령된 다른 동작들을 수행하도록 하는 스크립트 명령들의 클래스(class)가 존재한다. 이러한 세트에서 이용가능한 명령들의 선택은, 악성 스크립트(malicious script)가 미칠 수 있는 영향을 감소시키기 위해 일반적으로 제한된다.

스크립트들이 웹 페이지의 일부로서 도착하기 때문에, 그리고 스크립트들 자신들이 이후에 하나의 페이지 내에 삽입될 수 있는 정보를 포함할 수 있기 때문에, 스크립트들 자신들은 데이터의 형태이고 본 발명에서 "데이터 엘리먼트들"에 관한 모든 고려사항들(considerations)은 스크립트를 구성한 명령들의 리스트에 동일하게 적용될 것임을 특히 주목하자.

상기 기술들(facilities)이 어떻게 사용될 수 있는지에 관한 일 예로서, AJAX(Asynchronous JavaScript and XML) 기술을 사용하여 웹 페이지의 형태로 배포된 웹 기반의 문서 편집 어플리케이션을 고려하자. 그래피컬(graphical) 웹 브라우저는 처음에 하나의 페이지 - 이는 다양한 디스플레이 엘리먼트들(예를 들어, 룰러들(rulers), 버턴들, 및 텍스트 편집을 위한 영역)을 가지며(carrying), 또한 스크립팅 명령들의 파일을 참조함 - 를 다운로드한다. 이들 명령들은 사용자의 동작들에 어떻게 응답할지를 스크립팅 엔진에게 지시할 수 있다. 예를 들어, 만약 사용자가 "볼드(bold)" 버턴을 활성화한다면, 스크립팅 엔진은 상기 사용자가 텍스트 영역에서 어떤 단어들을 선택했는지를 결정하기 위해 그 페이지를 먼저 읽도록 지시받을 수 있다. 이 정보는, 그 텍스트를 볼드(bold)로 표시(mark)하는 것과 같은 그러한 방법으로 그 페이지 데이터 구조들을 변경(modify)하는 또 다른 명령에 의해 사용될 것이다. 마지막으로, "렌더링 엔진(rendering engine)"으로 알려진 브라우저의 또 다른 부분은 그러한 표시들을 읽을 것이고, 그 결과 그 표시된 단어들이 그 페이지 상에서 볼드체(bold-face)로 보이도록 할 것이다.

스크립트가능한 HTTP 클라이언트들(예를 들어, JavaScript를 지원하는 웹 브라우저들)은 전통적으로 한 번에 단 하나의 소스 위치로부터 데이터를 로드해 왔다. 그러나, 웹 서버 환경에서는 하나의 스크립팅 환경(scripting environment)의 각각의 소스 위치들로부터의 스크립트들 및 데이터를 결합할 수 있는 것이 바람직하다. 웹 기반의 문서 편집 어플리케이션의 예로 돌아가서, 현재로서는 사용자들이 그들의 문서들을 상기 어플리케이션의 제공자들에게 노출하고 맡기는 것(예를 들어, 상기 제공자의 서버에 문서들을 업로드(upload)함으로써)이 필요하다.

비록 현재 매우 많은 어플리케이션 프로그램들이 웹 서비스들(이 웹 서비스들은 웹 브라우저 내에서 실행중인 스크립트들을 이용하고 웹 서버들과 통신함)의 형태로 WWW를 통해 이용가능하게 되고 있지만, 많은 조직들 및 개인들은 그들의 비밀 문서들의 내재된 노출(inherent exposure)을 받아들이기를 꺼려한다. 이러한 점이 이용가능한 어플리케이션들의 사용을 제한한다.

클라이언트 내에 스크립팅 언어로 쓰여진 이러한 종류의 어플리케이션들은, 하나 또는 그 이상의 다른 위치들로부터 획득된 데이터에 대해 실행되는 것이 가능하다. 그러나, 일단 스크립트들 및 데이터가 스크립팅 환경 내에 로드되면, 악성으로 또는 스펠링 확인(spell checking)과 같은 기능을 제공하는 동안에, 스크립트들이 그들 자신의 서버들로 다시(back) 상기 데이터를 전송하지 않도록 보장하기 위한 어떠한 적절한 메커니즘이 현재로서는 없다. 알려진 해결책들은 승인되지 않은 스크립트들(unauthorized scripts)이 특정 파일들 및 객체들(objects)에 접근하는 것을 방지하는 것을 포함하지만, 이것은 너무 제한적일 수 있다.

예를 들어, US 특허번호 6,986,062는 스크립트들의 출처(origin) 및 한정된 승인들(defined permissions)에 기초하여 객체들에 접근하기 위해 스크립트들의 기능을 제어하는 것을 기술하고 있다. 클라이언트의 접근 제어 데이터 구조의 엔트리들은 객체와 연관된 승인 식별자 필드(permission identifier field) 및 소스 식별자 필드(source identifier field)를 포함한다. 여기서, 스크립트의 출처는 기록되고 계속해서 확인되며, 승인되지 않은 스크립트들은 특정 객체들에 접근하는 것이 방지된다.

US 특허번호 6,505,300은 신뢰할 수 없는 콘텐츠(예를 들어, 스크립트들)에 대해 실행 상황(execution context)을 제한하는 것을 기술하고 있다. 하나의 프로세스가 리소스(resource)에 접근하려고 시도할 경우, 그 프로세스와 연관된 토큰(token)은 그 접근이 허용되는지를 결정하기 위해 그 리소스에 대한 보안 정보(security information)에 비교된다. 스크립트의 소스는 그것이 얼마나 신뢰될 수 있는지, 그리고 특정 리소스들에 대해 어떤 프로세스들이 수행될 수 있는지를 결정할 수 있다.

US 특허출원번호 2006/0230452는 외부 위치로부터 하나의 파일을 획득하고 그 획득된 파일의 출처에 관한 태그 정보(tagging information)를 부가하는 것을 개시한다. 그 획득된 파일의 출처는 이후의 보안 폴리시 결정들(security policy decisions)(예를 들어, 콘텐츠의 실행 또는 렌더링(rendering)을 허용할 것인지 차단할 것인지의 결정)을 위해 사용될 수 있다.

본 발명의 제1 측면은 민감한 데이터(sensitive data)의 전송을 제어하기 위한 방법을 제공한다. 상기 방법은, 스크립팅 환경 내에서 수행되는 다음의 단계들, 즉, 출처(origin)의 표시(indication)를 제1 데이터 엘리먼트와 연관(associate)시키는 단계; 출처의 표시들을 상기 제1 데이터 엘리먼트로부터 발생된 데이터 엘리먼트에 전파(propagate)하는 단계; 및 상기 제1 데이터 엘리먼트 및 상기 발생된 데이터 엘리먼트의 전송들을 허가된 목적지들(permitted destinations) - 이 허가된 목적지들은 출처의 상기 표시들을 참조하여 식별됨 - 만으로 제한하는 단계를 포함한다.

상기 제1 데이터 엘리먼트는 데이터 엘리먼트들의 세트의 일부(part of a set of data elements)를 포함할 수 있고, 잠재적으로는(potentially) 데이터의 매우 큰 세트를 포함할 수 있는데, 출처의 상기 표시는 이러한 데이터 세트와 연관된다. 상기 발생된 데이터 엘리먼트는 또한 발생된 데이터 엘리먼트들의 세트 중 하나일 수 있다.

발명의 일 실시예에서, 상기 제1 데이터 엘리먼트 및 상기 제1 데이터 엘리먼트로부터 발생된 데이터 엘리먼트들은 상기 제1 데이터 엘리먼트의 출처 이외의 다른 출처로 전송되는 것이 방지된다. 이 방법은 스크립팅 동작들(scripting operations)이 네트워크를 통해 상기 데이터의 소스 이외의 다른 네트워크 노드로 민감한 데이터를 전송하는 것을 방지할 수 있는 한편, 데이터 전송을 제한하는 규칙들의 제약들(constraints) 내에서 스크립트들이 협력(collaborate)하도록 허용한다.

일 실시예에서, 만약 새로운 데이터 엘리먼트들이 상기 스크립팅 환경 내에서 다수의 데이터 엘리먼트들 - 이 데이터 엘리먼트들 각각은 출처의 연관된 표시들을 가짐 - 로부터 발생된다면, 상기 새로운 데이터 엘리먼트들은 상기 다수의 데이터 엘리먼트들로부터 파생된(derived) 출처의 연관된 표시들을 가질 것이다. 만약 다수의 민감한 입력 데이터 엘리먼트들이 서로 다른 출처들을 갖는다면, 전송을 제한하는 단계는 어떤 목적지로의 출력 데이터의 전송을 방지할 수 있는 반면, 공통의 출처를 갖는 다수의 입력 데이터 엘리먼트들로부터 파생된 출력은 상기 공통의 출처로 다시 전송될 수 있으나, 다른 목적지로 전송되는 것은 방지될 수 있다.

전송을 제한하는 단계는 '신뢰할 수 없는(untrusted)' 스크립트들을 실행하고 있는 스크립팅 환경 내에서는 유리하다. 이 맥락에서 '신뢰할 수 없는' 스크립트는, 그 스크립트의 보안 제어들(security controls) 또는 신뢰성(trustworthiness) 또는 스크립트 제공자가 검증(verify)되지 않은 스크립트이다(따라서, '신뢰할 수 없는' 이라는 이 용어는 스크립트 또는 스크립트 제공자가 어떤 해의(malicious intent)를 갖는 것으로 인식되는 것을 의미하지는 않는다).

본 발명은, 상기 데이터가 하나의 스크립트에 의해 작동될 때, 그 스크립트의 신뢰성 또는 그것의 제공자를 검증(verify)할 필요없이, 그 스크립트가 벌써(already) 그 정보를 갖지 않는 어떤 서버로 그 데이터를 보내지 않을 것을 보장하여, 민감한 데이터를 위한 보호를 제공한다. 출처의 표시를 연관시키는 단계 및 전파하는 단계는 웹 브라우저 내의 스크립팅 엔진에 의해 구현될 수 있는데, 상기 스크립팅 엔진은 어떤 스크립트가 그 데이터의 소스 위치 이외의 위치로 그 태그된 데이터를 보내는 것을 방지하기 위해 데이터 내의 보안 태그들(security tags)에 응답한다. 상기 태그들은 데이터의 출처 위치(origin location)를 나타낸다. 본 발명의 일 실시예에 따른 "스크립팅 엔진"은 스크립트 인터프리터(script interpreter), 태그 발생기(tag generator) 및 태그 전파기(tag propagator)를 포함한다.

발명의 제2 측면은 데이터 처리 시스템을 제공하는데, 이 데이터 처리 시스템은, 적어도 하나의 데이터 처리 유닛(data processing unit); 적어도 하나의 데이터 스토리지 유닛(data storage unit); 스크립트 인터프리터; 출처의 표시를 제1 데이터 엘리먼트와 연관시키기 위한 수단; 출처의 상기 표시를 상기 제1 데이터 엘리먼트로부터 발생된 새로운 데이터 엘리먼트에 전파하기 위한 수단; 및 상기 데이터 처리 시스템으로부터 상기 제1 데이터 엘리먼트 및 상기 발생된 데이터 엘리먼트의 전송들을 허가된 목적지들 - 이 허가된 목적지들은 상기 표시들을 참조하여 식별됨 - 만으로 제한하기 위한 수단을 포함한다.

이러한 제2 측면의 일 실시예에서, 상기 스크립트 인터프리터, 상기 연관시키기 위한 수단, 상기 전파하기 위한 수단 및 전송을 제한하기 위한 수단은 모두 웹 브라우저와 같은 스크립트가능한 HTTP 클라이언트 컴퓨터 프로그램 내에서 구현된다. 일 실시예에서, 상기 연관시키기 위한 수단 및 전파하기 위한 수단은 HTTP 클라이언트 프로그램 내에서 개선된 스크립팅 엔진의 특징들(features)로 제공되는데, 이 HTTP 클라이언트 프로그램은 기록 매체 상에서 컴퓨터 판독가능 프로그램 코드(computer-readable program code)를 포함하는 프로그램 제품으로 이용가능하게 될 수 있다.

발명의 실시예들은 첨부되는 도면들을 참조하여 이하에서 더 상세히 기술될 것이다. 그러나, 도면들 및 설명은 단지 예로서 제공되는 것일 뿐이다.
도 1은 본 발명이 구현될 수 있는 네트워크의 개략적인 표현이다.
도 2는 본 발명이 구현될 수 있는 클라이언트 데이터 처리 시스템의 일 예를 보여준다.
도 3은 본 발명의 일 실시예에 따른 스크립팅 엔진의 컴포넌트들을 보여준다.
도 4는 출처 태그들이, 새로운 데이터 엘리먼트들로 전파되기 전에, 발생되고 저장되는, 그리고 그런 다음 데이터의 출처 이외의 목적지들로의 민감한 데이터의 전송을 방지하기 위해 사용되는, 본 발명의 일 실시예에 따른 클라이언트와 서버 사이의 인터랙션의 동작들의 시퀀스를 보여준다.
도 5는 본 발명의 일 실시예에 따른 주석(annotations)을 전파하기 위한 동작들의 시퀀스를 보여준다.

1. 네트워크 환경 및 클라이언트 시스템 예

도 1에서 개략적으로 도시된 분산된 데이터 처리 네트워크(distributed data processing network)는 임의 개수의 클라이언트 데이터 처리 시스템들(10, 20, 30) 및 서버 데이터 처리 시스템들(40, 50, 60)(이것들은 HTTP를 통해 서로 간에 통신함)을 포함한다. 비록 본 발명은 시스템 하드웨어 또는 운영 체계 환경에 의해 특정 타입의 데이터 처리 시스템으로 한정되지는 않으나, 도 2에서 개략적으로 도시된 전형적인 클라이언트 시스템(10)은 랩탑(laptop) 또는 데스크탑(desktop) 데이터 처리 시스템을 포함하는데, 이것들은 적어도 하나의 데이터 처리 유닛(100), 적어도 하나의 데이터 스토리지 유닛(전형적으로는 휘발성 시스템 메모리(110), 디스크 스토리지와 같은 비휘발성 스토리지 컴포넌트(120)), 내부 통신 버스(130), 입력/출력 컴포넌트들(이것들은 디바이스 드라이버들(140), 및 마우스(160), 키보드(170) 및 모니터(180)를 포함함), 및 네트워크 인터페이스(190)를 포함한다. 본 발명의 구현에 사용되는 전형적인 클라이언트 시스템은 시스템 상에 인스톨된 복수의 프로그램 코드 컴포넌트들을 갖는데, 이러한 복수의 프로그램 코드 컴포넌트들은 운영 체계 소프트웨어(200), 웹 브라우저(210) 및 복수의 응용 어플리케이션들(220, 230)을 포함한다. 웹 브라우저(210)는 요청 응답 HTTP 모델(request-response HTTP model)을 사용하여 네트워크 통신을 통해 원격 웹 서버들과 인터랙션(interaction)하는 것이 가능하다. 웹 서버들(40, 50, 60) 각각은 하나 또는 그 이상의 HTTP 서버들(70) 및 하나 또는 그 이상의 어플리케이션 서버들(80, 90) - 이것들은 하나의 서버 데이터 처리 시스템 또는 높은 이용률(availability) 및 처리율(throughput)을 제공하기 위해 협력하는 일단의(a cluster of) 서버들 상에서 실행되고 있음 - 을 포함할 수 있다. 그러나, 본 발명은 어떤 특정 웹 서버 아키텍쳐(Web server architecture)를 요구하는 것은 아니다.

본 발명에 사용할 클라이언트 시스템에서, 웹 브라우저(210)는 다운로드된 웹 페이지들 내에서 스크립트들의 실행을 가능하게 하는 스크립트 인터프리터를 포함하는데, 이 스크립트 인터프리터는 스크립팅 엔진(240)의 주요 컴포넌트를 포함한다. 본 발명의 다양한 컴포넌트들 및 특징들은 이하에서 도 3 내지 도 5를 참조하여 기술되며, 본 발명의 실시예의 맥락에서 몇몇 컴포넌트들은 새로운 스크립팅 엔진의 프로그램 코드 컴포넌트들로 구현된다. 도 3에 보여지는 바와 같이, 스크립팅 엔진(240)은 스크립트 인터프리터(250), 출처 태그 발생기(260) 및 태그 전파기(270)를 포함한다. 당해 기술 분야에서 숙련된 자라면 본 발명의 다양한 컴포넌트들(예를 들어, 이하에 기술되는 전송을 방지하기 위한 수단들)은 ASIC(application-specific integrated circuit)와 같은 하드웨어 컴포넌트로서 동일하게 구현될 수 있다는 것을 이해할 것이다.

이하에서 기술되는 바와 같이, 발생되고 전파되는 태그들은 민감한 데이터 엘리먼트들의 전송을 제어하기 위해 웹 브라우저 또는 다른 HTTP 클라이언트에 의해 사용된다.

2. 출처를 표시하는 태그들의 발생 및 저장

앞서 기술된 바와 같이, 스크립팅 엔진 동작들에서 사용될 수 있는 많은 종류의 데이터 엘리먼트가 존재한다. 이러한 모든 엘리먼트들은 스크립팅 엔진(240) 자신과 연관되거나 웹 브라우저(210)와 연관된 데이터 구조들(또는, 다른 구현들에서는 스크립팅 엔진이 일부인 또 다른 프로그램과 연관됨)에 저장된다. 스크립팅 동작들은 이들 데이터 구조들 내에서 그들의 내부 작업들의 일부로서 이들 데이터 구조들 내에서 데이터를 읽고 변경할 것이나, 스크립트가 자신의 목적들을 위해 그 데이터 구조들 자체를 조사 또는 변경할 수 있는 어떠한 스크립팅 동작들도 존재하지 않는다.

기존의 스크립팅 엔진들에서, 이들 데이터 구조들은 일반적으로 데이터 엘리먼트의 현재 값과 스크립팅 엔진의 사용을 위한 추가 정보 둘 다를 포함한다. 그러한 정보의 일 예는 자동 쓰레기 수집(automatic garbage collection)에 관한 정보이다. 본 발명은 출처(origin)의 표시들(indications)을 데이터 엘리먼트들과 연관시키는 것을 포함하며, 본 발명을 구현하는 것과 관련되는 데이터 엘리먼트에 대한 "주석들(annotations)"은 스크립팅 엔진의 사용을 위해 제공되는 다른 정보와 동일한 방법으로 스크립팅 엔진의 데이터 구조들에 저장될 수 있다. 이는 본 발명을 구현하기 위해 현재의 웹 브라우저들 및 다른 스크립트가능한 HTTP 클라이언트 프로그램들에게 단지 작은 변화들만이 요구된다는 것을 의미하고, 그래서 그것은 스크립트들이 그들 자신의 주석들을 방해하도록 이용할 수 있는 어떠한 메커니즘도 없다는 것을 보장한다.

도 4는 데이터 엘리먼트들의 세트에 대한 "주석들" 또는 출처 표시 태그들(origin-indicating tags)의 초기 발생과 관련되는 단계들의 시퀀스를 보여준다. 민감한 것으로 여겨지는 모든 데이터는 그것이 스크립트 동작에서 먼저 사용되기 전에 출처 태그(origin tag)가 할당(assign)되어야 한다. 현대의 웹 브라우저 내에 데이터를 가져올 수 있는 여러 방법들이 있지만, 그 방법들 대다수는 HTTP 프로토콜(W3C Network Working Group's Request For Comments 2616의 "Hypertext Transfer Protocol - HTTP/1.1"(1999. 06)에 규정됨)과 관련된다. 그러한 방법들에서, 본 발명을 구현하는 것이 가능한 웹 브라우저 또는 다른 HTTP 클라이언트는 요청시 특정 HTTP 헤더를 사용하고, 응답시 또 다른 특정 HTTP 헤더를 사용할 수 있다. HTTP 규정은 추가의(extra) 헤더들이 사용되도록 허용하고, 관련있는 기능을 구현하지 않는 시스템들은 그것과 관련된 헤더들을 무시할 것임을 주목하자.

따라서, 도 4에서 보여지는 바와 같이, 본 발명의 일 실시예에 따른 클라이언트-서버 인터랙션 시퀀스는 웹 브라우저와 같은 스크립트가능한 클라이언트가 웹 서버에 HTTP 요청을 보내는 것(300)으로 시작한다. 비록 모든 HTTP 클라이언트들이 본 발명을 구현할 것은 아니지만, 발명을 구현하는 클라이언트들은 전형적으로 그러한 사실(fact)을 나타내는 새로운 헤더(데이터에 대한 각각의 요청을 동반하는 많은 헤더들 중의)를 포함할 것이다.

현재 이용가능한 웹 브라우저들은 그것들이 지원하는 기능에 관한 많은 정보, 그리고 심지어 그것들의 사용자들이 요구하는 콘텐츠의 종류(예를 들어, 어떤 (인간의) 언어들이 수용가능한지)까지도 벌써(already) 보낸다. 예를 들어, 하나의 요청은 다음과 같다.

요청자가 "보안(secure)" 콘텐츠를 위해 보호를 제공할 수 있는지를 식별(identify)하기 위해 새로운 요청 헤더가 부가될 수 있다. 콘텐츠 타입 "보안"은 기존의 콘텐츠 카테고리들과 다르다(왜냐하면, 그것은 MIME 타입, 인간의 언어, 인코딩 또는 캐릭터 세트의 타입이 아니기 때문에). 제1 실시예에서, 상기 새로운 요청 헤더는 필드 이름 "Accept-Security" 를 가지나, 이는 단지 하나의 예일 뿐이다. 상기 필드 이름이 무엇이든 간에 상기 새로운 헤더 필드는 데이터 보호가 출처 태깅(origin tagging)을 사용하여 요청 클라이언트에 의해 제공되는지에 관한 하나의 간단한 표시일 수 있다.

요청 헤더 "Accept-Security:origin-tagging"은, 만약 서버가 보안 데이터(secure data)를 보내기를 원한다면 브라우저는 그 보안 데이터를 보호할 수 있으나 이것은 보안 데이터를 요구하지 않는다는 것을 의미한다. 추가 헤더는 매 HTTP 요청에 포함될 수 있으나, 이는 본질적인 것은 아니다. 그러한 새로운 헤더는 선택적으로 구현된 보안의 다른 종류들과의 장차 확장을 허용한다. 예를 들어, 'Accept-Security:' 요청 헤더 및 출처 태깅에 기초한 데이터 전송의 제한은 또 다른 보안 옵션과 함께 구현될 수 있다.

서버는 클라이언트에게 다운로드하기 위해 준비된 요청된 페이지에 접근한다(310). 그러나 웹 서버는 어떤 민감한 데이터를 전송하기 전에 새로운 요청 헤더의 존재에 대해 확인(check)하도록 구성될 수 있다. 상기 확인은 모든 HTTP 요청들에 대해 수행되거나, HTTP 요청에 응답할 때 데이터 민감성(data sensitivity)의 표시들을 탐지(detect)하기 위한 메커니즘이 웹 서버에 제공된다면, 그 접근된 페이지 내에서 웹 서버가 그 민감한 데이터를 식별하는 것에만 단지 응답하여 수행될 수 있다. 일 실시예에서, 데이터 민감성의 표시들은 하나의 콘텐츠 서버 상에 데이터를 생성하거나 저장할 때 삽입될 수 있다.

데이터 민감성에 대한 확인(check) 전 또는 후에 클라이언트 능력들(client capabilities)을 확인할 것인지에 관한 특정 순서는, 발명에서는 중요하지 않다. 만약 웹 서버가 요청된 페이지 내에서 민감한 정보를 식별한다면, 그래서 요청하는 클라이언트가 그 데이터를 보호하도록 하지 않았다는 것을 결정한다면(즉, 요청시 새로운 헤더를 포함하지 않음), 본 발명의 일 실시예에 따른 서버는 그 요청을 거부(decline)함에 의해 또는 그 민감한 데이터없이 그 요청된 페이지를 제공함에 의해, 클라이언트에게 응답한다(320).

웹 서버들은 다른 방식으로 동작하도록 프로그램 및 구성될 수 있다(그리고 일부 웹 서버들은 본 발명을 지원하기 위한 어떤 새로운 기능들을 구현하지 않을 수 있다). 그러나, 본 실시예에서 제공되는 새로운 요청 헤더는 서버들이 민감한 데이터를 제공할 것인지에 관해 통지된 결정을 하는 것을 가능하게 한다. 그런 다음, 서버는 민감한 데이터를 보호하기 위한 커미트먼트(commitment) 및 클라이언트의 능력(client's ability)을 각각의 서버에게 통지하지 않은 어떤 클라이언트에게 그것의 민감한 데이터를 제공하는 것을 거부할 수 있다.

위에서 기술된 발명의 실시예는 사실상 HTTP 클라이언트가 보호하지 않을 경우 그것이 민감한 데이터를 보호하도록 요구하는 것을 방지하기 위한 어떠한 메커니즘을 포함하지 않는다. 이러한 제1 실시예에서, HTTP 클라이언트는 인간 사용자의 하나의 에이전트(agent)로 여겨지며, 본 발명의 범위는 단지 사용자가 신뢰되는 데이터까지만 확장된다. 사용자 인증(user authentication)을 위한 알려진 해결책은 단지 권한을 부여받은 사용자들만이 민감한 데이터를 획득할 수 있도록 보증하기 위해 사용되어야 한다.

만약 웹 서버가 요청된 페이지의 민감한 데이터를 식별하고 요청 헤더 내의 필드들에 관한 확인이 그 요청하는 클라이언트가 민감한 데이터를 위한 보호를 제공한다고 결정하면, 웹 서버는 그 요청된 페이지 및 '민감한 데이터(sensitive data)' 플래그(flag)를 요청자 클라이언트(requestor client)에게 전송한다(330). 비록 본 발명에 대해서는 오쏘거널(orthogonal)하지만, 전송시(in transit) 민감한 데이터의 인터셉션(interception)을 방지하기 위해 보안 소켓 층(Secure Sockets Layer)과 같은 보안 메커니즘을 사용하여 보호되는 것이 민감한 데이터의 어떤 전송을 위해서는 일반적으로 바람직하다.

따라서, 본 실시예에서, 어느 데이터가 민감한지에 관한 결정이 그 데이터를 제공하는 서버에 의해 수행된다. HTTP 요청에 응답하여 민감한 데이터가 제공될 때(330), 그 응답은 그것의 콘텐츠들이 본 발명에 따라 민감한 데이터로 취급되어야 한다는 것을 나타내는 헤더를 가질(carry) 것이다. '민감한 데이터(sensitive data)' 헤더는 출처 태그에 포함하기 위한 특정 출처 정보에 관해 웹 서버로부터의 분명한 명령을 포함할 수 있고, 출처 태그 발생기(260)는 이 명령에 따라 행동(act)할 것이다. 만약 이 데이터를 클라이언트가 받는 것(340)이 스크립트가능하다면, 그래서 그 데이터가 스크립트 동작들에 접근가능한 메모리의 영역에 위치해야 한다면, 클라이언트는 그 데이터를 저장할 때 그리고 스크립트들을 실행하기 전에 그 데이터에 출처 데이터를 어태치(attach)해야 한다(350). 그 후, 출처 태그들은 그 받은 데이터 엘리먼트들(이하에서 기술되는 바와 같은)로부터 클라이언트 내에서 생성된 어떤 새로운 데이터 엘리먼트들에 전파되고(360), 그 출처 태그들은 태그된 데이터 엘리먼트들(이 또한 이하에서 기술됨)의 전송을 제어하기 위해 사용된다(370).

출처가 태그에서 기술되어야 하는 정확성(precision)의 정도는 서버에 의해 결정될 수 있다. 예를 들어, 작은 회사는 브라우저들이 그 데이터에 "company.com"의 출처 태그를 적용하도록 하는 헤더를 갖는 회사의 인트라넷 상의 모든 문서들에 대해 서비스를 제공할 수 있지만, 회사 밖에서는 어디에도 서비스를 제공하지 않는다. 더 큰 회사는, 아마도 브라우저들이 "secretdocstore.r-and-d.company.com" 또는 "webapps.finance.company.com"으로써 그것을 태그하도록 하는 헤더들로써 그것의 데이터의 몇몇을 더 엄격하게 제한할 수 있다. 공유된 서버(shared server) 상의 웹 어플리케이션(이는 또한 거기에 존재할 수 있는 다른 어플리케이션들을 신뢰할 수 없음)은, "apps.sharedhostingcompany.com" 뿐만 아니라, "8080"의 포트 번호 및 "/customers/account42/secretdocs"의 도메인으로써 그것이 태그되도록, 데이터에 서비스를 제공할 수 있다. 이것은, 배타적으로(exclusively) 특정 웹 어플리케이션의 제어하에 있는 위치 정보에 기초하여 출처의 표시를 제공하나, 반면에 동일 서버상의 다른 위치들은 덜 정확하게 규정될 수 있다. 그래서, 웹 어플리케이션의 배타적 제어(exclusive control) 하에 있는 위치는 다음과 같이 규정될 수 있다.

http://apps.sharedhostingcompany.com:8080/customers/account42/secretdocs/

따라서 위에서 기술된 태깅 기법(tagging scheme)은 공유된 서버들의 경우를 처리할 수 있는 충분한 정확성을 갖는 반면, 호스트 이름은 공유된 서버들을 다루지 않을 때에는 충분할 수 있다.

스크립트된 다이얼로그 박스들(scripted dialog boxes) 및 그 페이지 내의 텍스트 박스들 내에 타이핑된 정보, 및 로컬 파일들로부터 로드된 데이터는 민감성에 관한 질문(question)이 선정(delegate)될 수 있는 출처 서버를 갖지 않는다. 이 이슈는 사용자로부터 획득된 태깅 정보에 의해 해결될 수 있고, 또는 그렇지 않으면, 스크립팅 엔진이 실행 중인 컴퓨터로부터 획득되거나 그러한 컴퓨터 상에서 실행되며, 여기서 특정 출처 태그는 "로컬(LOCAL)"을 의미한다. 이 태그는 다른 출처 태그들과 대체로 유사하지만, 이하에서 기술되는 바와 같이 특정 처리가 제공될 수 있다.

대부분의 브라우저들은 또한 HTTP 이외의 프로토콜들을 통해 데이터에 접근할 수 있으며, 여기서 파일 전송 프로토콜(FTP, File Transfer Protocol)은 널리 사용되는 일 예이다. 어떤 경우들에 있어서는, 이들 프로토콜들은 또한 HTTP에 대해 위에서 기술된 바와 같은 추가 헤더들로써 확장될 수 있고, 반면에 다른 경우들에 있어서는 위에서 기술된 "로컬(LOCAL)" 출처 태그를 사용하여 로컬 파일들(예를 들어, 여기서는 브라우저들이 SMB 또는 NFS 공유 파일시스템 프로토콜들을 구현함)과 같은 방법으로 데이터를 처리하는 것이 더 적합하다. 그것들은 본 발명으로부터 혜택을 받을 웹 어플리케이션들의 종류에 사용될 것 같지 않으므로, 본 발명은 비록 어떤 이상한(esoteric) 프로토콜들이 출처 태깅 시스템없이 남아 있더라도 여전히 유용(useful)하고 유효(valid)하다.

발명의 일 실시예에서, 주석들을 발생시키고 저장하기 위해 위에서 설명된 기술들은 요구되는 스토리지 용량을 감소시키고 주석 전파의 더 빠른 구현을 허용하도록 향상된다. 전형적인 사용시, 어느 때나 사용되는 단지 작은 개수의 주석 값들(아마도 단 하나)이 있을 것이지만, 이들 값들은 매우 많은 각각의 데이터 엘리먼트들에 적용될 수 있다. 그러한 향상(enhancement)은 이 특성을 감안하고 출처 값들의 중심 테이블(central table)을 사용한다. 각각의 주석들은 값에 관한 그들 자신의 카피를 갖기(carry) 보다는 오히려 단지 그 테이블의 적절한 행(row)을 가리킬(point) 필요만 있다.

3. 태그들의 전파

데이터의 한 항목이 출처 태그를 갖는 경우, 그 태그는 그것으로부터 파생된 다른 어떤 데이터에 전파된다(360). 더 상세하게는, 입력 및 출력 둘 다를 갖는 모든 스크립트 동작들에 있어서, 전자의 데이터 구조들에서 존재하는 어떤 출처 태그들은, 스트립팅 엔진(240)의 태그 전파기 컴포넌트(270)에 의해 후자의 대응하는 데이터 구조들로 전송될 것이다. 예를 들어, JavaScript String.subString() 메소드(method)는 하나의 입력으로서 텍스트의 스트링을 받아들이고 하나의 출력으로서 텍스트의 더 짧은 스트링을 생성하는 동작이다. 만약 이 메소드가 "example.com"으로부터 안전하게 획득된 페이지에서 일부 텍스트를 추출하기 위해 본 발명에 따라 스크립팅 엔진(240)에 사용된다면, 그 추출된 텍스트는 또한 "example.com"의 출처를 가지고 태그될 것이다. 이 실시예에서, 하나의 객체에 관해 수행된 어떤 스크립팅 동작은 하나의 입력으로서 그 객체를 받아들이는 것으로 간주되어야 한다.

위의 배경기술 부분에서 기술된 바와 같이, 스크립팅 엔진들은 전형적으로 구조화된 언어들로 쓰여지고 특정 동작들을 제공한다. 그러한 동작들은 그러한 구조화된 언어에 쓰여진 프로그램 코드에 의해 정의된다. 본 실시예에서, 이 섹션에서 기술된 추가 동작(behaviour)은 태그 전파 기능(tag propagation function)을 스크립팅 엔진 내의 프로그램 코드에 부가함으로써 구현된다. 스크립트는 본 발명을 구현하지 않는 스크립팅 엔진에서 있는 것과 같이 정확하게 일련의 동작들을 계속해서 요구할 것이지만, 출처 태그들은 생성되고(350) 그런 다음 사용자 및 스크립트-프로그래머에게 분명하게(transparently) 전파된다(360).

스크립트 동작이 입력의 한 항목(item) 이상에 대해 동작하고 입력 항목들 중 적어도 두 개 모두가 동일한 출처로부터가 아닌 출처 태그들을 가질 경우, 출력 데이터는 특별한 태그를 획득한다. 태그된 데이터는 그것의 출처를 제외하고는 어디에도 보내질 수 없기 때문에, 그리고 새로운 데이터의 소스는 다수의 출처들을 포함(encompass)하기 때문에, 그것이 허용된 전송을 위한 규칙들 내에 보내질 수 있는 어떠한 위치도 존재하지 않는다. 따라서, 그 특별한 태그는 "노웨어(nowhere)"를 표시하고, 그래서 이러한 방법으로 태그된 데이터는 스크립팅 환경을 남기지 않을 수 있다.

이 특정 실시예에서, 위에서 기술된 전파는 네 개의 점차적인(increasingly) 제한적 출처 태그 타입(restrictive origin-tag-types)을 사용한다.

논(NONE) : 상기 항목은 어떠한 출처 태그도 갖지 않는다. 왜냐하면 HTTP 세션(session) 또는 그것이 획득된 다른 수단은 보안으로 지정(designate)되지 않았기 때문이다.

로컬(LOCAL) : 상기 항목은 사용자에 의해 입력되거나, 로컬 파일로부터 로드된다.

출처(ORIGIN) : 데이터가 획득된 위치를 표시하는 표준 출처 태그(standard origin tag). 스크립팅 환경에서 동시에 사용되는 다수의 다른 출처들이 있을 수 있다.

노웨어(NOWHERE) : 이 데이터 항목이 획득된 경로(path)는 하나 이상의 출처를 가지고 태그된 데이터를 수반한다.

태그들의 이러한 종류들이 두 개의 입력 스크립팅 동작의 경우에 인터랙트하는 방법은 표 1에 의해 설명된다.

두 개의 입력 동작에 대해서와 같이, 만약 가장 제한적인 타입이 "출처(ORIGIN)"이고 하나 이상의 출처 위치가 존재한다면 "노웨어(NOWHERE)"는 앞서 기술된 출력을 위해 사용될 것이라는 것은 제외하고, 세 개 또는 그 이상의 입력 엘리먼트들을 갖는 스크립팅 동작은 그것의 입력(들)에게 입력들 사이에서 발견되는 가장 제한적인 태그 타입을 할당(assign)한다. 하나의 입력 동작의 경우에, 모든 출력들은 입력 항목의 태그를 단순히 물려받는다(inherit).

스크립팅 동작들의 출력들과 연관될 태그들의 결정을 위한 단계들의 시퀀스는 도 5에 나타나 있다. 그러나, 도 5에 보여진 특정 동작적 시퀀스는 단지 본 발명의 하나의 예시적인 실시예와 관련될 뿐이다. 이 실시예에 따라, HTTP 클라이언트가 처리를 시작하기 위해 그것의 로컬 메모리로부터 입력 데이터(예를 들어, 검색된 웹 페이지)를 검색(retrieve)할 때, HTTP 클라이언트는 스크립트가 식별될 때까지 전통적인 방법으로 그 입력 데이터를 처리한다. 그런 다음, HTTP 클라이언트는 그것의 스크립트 인터프리터(250)를 호출한다. 각각의 스크립트 명령을 실행하기 전에, 스크립트 인터프리터는 입력 데이터 엘리먼트들과 연관된 태그들의 세트를 추출하여(410) 그것들을 태그 전파기(270)로 전달한다. 그런 다음 태그 전파기는 스크립팅 동작의 출력들을 위해 적절한 태그를 결정하기 위한 규칙들의 세트를 적용한다. 만약 입력 데이터에 관해 어떤 출처 태그들의 존재에 대한 확인 단계(420)에서 입력 데이터 엘리먼트들과 연관된 어떠한 태그들도 없다는 것이 결정된다면, 이 과정(process)의 단축(shortcutting)이 가능하다. 이 '단축(shortcut)'은 도 5의 단계 420과 단계 500 사이에서 화살표로 보여진다.

만약 단계 420에서 결정된 것과 같이 입력들이 어떠한 태그도 갖지 않는다면, 출력들은 또한 어떠한 연관된 태그도 갖지 않을 것이다. 그러나, 만약 새로운 데이터 엘리먼트들이 사용자에 의해 입력되거나 로컬 파일로부터 로드된다면, 이들 입력들은 태그 타입 로컬(LOCAL)을 갖는 것으로 취급될 것이고, 이 경우 스크립팅 엔진의 처리의 출력들은 또한 연관된 태그 타입 로컬(LOCAL)을 가질 것이다(또는, 만약 다른 태그된 입력들과 조합된다면, 더 제한적인 태그 타입을 가짐). 이는 이하에서 더 상세히 설명된다.

만약 단계 420에서의 결정이 "예"라면, 관련있는 입력 태그들이 존재하기 때문에, 본 실시예들에 따른 태그 전파 처리는 가장 제한적인 태그 타입으로 시작하는 시퀀스에서 구현된다. 즉, 태그 전파기(720)에 의해 수행된 제1 단계는, 어떤 입력들이 태그 타입 노웨어(NOWHERE)를 갖는지를 결정하는 것(430)을 포함한다. 만약 어떤 입력들이 태그 타입 노웨어(NOWHERE)를 갖는다면, 그 태그 타입 노웨어(NOWHERE)는 스크립팅 엔진의 출력 데이터 엘리먼트 또는 엘리먼트들과 연관된다(440).

태그들이 테이터 전송을 제어하기 위해 사용되는 방법은, 예시적인 전파 시퀀스의 설명에 이어지는 '데이터 전송을 제어하기 위한 출처의 표시들의 사용' 이라는 제목하에서 이하에서 더 상세히 기술된다. 그러나, 이 제어의 일 예는 여기서는 설명을 위해서 제공되는 것이다. 데이터 엘리먼트가 연관된 태그 타입 노웨어(NOWHERE)를 가질 때, 이들 스크립트 명령들에 응답한 HTTP 클라이언트의 동작들은 그 연관된 태그 노웨어(NOWHERE)에 의해 부과된 제한들(limitations)을 받을 것임을 제외하고는, 스크립트 인터프리터는 스크립트 명령들을 실행할 수 있을 것이다(500). 특히, 노웨어(NOWHERE) 태그를 갖는 데이터 엘리먼트들은 스크립팅 환경 외부에 전송되는 것이 방지될 것이다.

도 5의 전파 시퀀스로 돌아가서, 만약 어떠한 입력 데이터 엘리먼트들도 태그 타입 노웨어(NOWHERE)를 갖지 않는다면, 전파기(propagator)는 복수의 다른 출처(ORIGIN) 태그들을 갖는 특정 스크립트 명령에 대한 복수의 입력들이 있는지를 결정한다(450). 만약 그렇다면, 태그 타입 노웨어(NOWHERE)는 출력 데이터 엘리먼트 또는 엘리먼트들과 연관된다(440).

만약 단계 450에서의 결정이 '아니오' 라면, 전파기는 현 스크립트 동작에 대한 입력 데이터 엘리먼트들이 하나의 출처(ORIGIN) 타입 태그를 갖는지(즉, 단지 하나의 민감한 데이터 엘리먼트만이 있는지, 또는 모든 민감한 데이터 엘리먼트들이 동일한 출처를 갖는지)를 결정한다(460). 만약 하나의 출처(ORIGIN) 타입 태그를 갖는다면, 관련있는 출처(ORIGIN) 타입 태그는 스크립트 명령의 출력 데이터 엘리먼트들과 연관된다(470).

만약 단계 460에서의 결정이 '아니오'라면, 전파기는 현재의 스크립트 명령에 대한 어떤 입력이 연관된 로컬(LOCAL) 타입 태그(사용자에 의해 입력되거나 로컬 파일로부터 로드된 데이터를 포함함, 이는 로컬(LOCAL) 태그를 갖는 것으로 여겨짐(위에서 보여지는 바와 같이))를 갖는지를 결정한다(480). 만약 로컬(LOCAL) 태그를 갖는다면, 그 로컬(LOCAL) 태그는 스크립트 동작의 출력 데이터 엘리먼트들과 연관된다(490).

스크립팅 동작의 출력들과 연관될 태그들을 결정한 경우, HTTP 클라이언트 내의 스크립팅 엔진은 그것의 처리(500)를 수행하고, 이하에서 기술되는 태그들에 의해 부과된 데이터 전송에 관한 제한들을 받는다. 단계들 410 내지 500은 하나의 스크립트 내에서 각각의 스크립트 명령에 대해 반복적으로 수행되고, 스크립팅 엔진은 그것이 실행함에 따라 태그들을 전파한다.

스크립팅 동작들에 부가하여, 스크립트들의 도메인(domain)에 대해 영향을 미치면서 실제로 자신들은 스크립트 동작들이 아닌 다른 동작들이 있을 수 있다. 예를 들어, 텍스트 박스에서의 사용자 타이핑(user typing)은 로컬(LOCAL) 데이터를 생성하고 있지만, 사용자는 이 로컬 데이터를 출처 데이터와 결합하고 있을 수 있다. 그러한 경우, 결과 데이터를 위한 적절한 태그를 결정하기 위해 규칙들을 적용하는 것이 태그 전파기 컴포넌트(또는 다른 HTTP 클라이언트에서 실행 중인 균등한 컴포넌트)에게는 바람직하다. 본 실시예에서, HTTP 클라이언트는 태그된 데이터의 어떤 그러한 결합에 대해 적절한 태그를 결정하기 위해 태그 전파기를 호출한다. 다른 실시예들에서, 태그 전파기는 스크립팅 엔진으로부터 분리된 컴포넌트로서 구현될 수 있다. 텍스트 박스 내의 사용자 타이핑의 예에서, 스크립팅 엔진은 전형적으로 모든 키프레스(keypress)에 대해 호출(invoke)될 수 있고, 그래서 그것은 변경들에 관해 통지되도록 등록되는 스크립트의 어떤 부분을 활성화할 수 있고, 그래서 스크립팅 엔진의 태그 전파기 컴포넌트는 새로운 데이터에 대한 적절한 태그들을 결정하기 위해 쉽게 호출된다.

4. 데이터 전송을 제어하기 위한 출처의 표시들의 사용

특정 스크립트 동작들은 네트워크 상에서 어디서나 웹 브라우저로부터 서버들로의 데이터의 전송을 포함한다. 예를 들어, HTML 폼(RFC 1866에 규정)은 스크립트 제어 하에서 보내질 수 있고, XMLHttpRequest(앞서 언급됨)는 사용될 수 있고, 또는 브라우저는 "경로(path)", "질의(query)" 또는 "프래그먼트(fragment)" 부분들이 데이터를 전달하는 수단으로 특별히 구축되어 있는 URL에 접근하도록 지시될 수 있다. 본 발명은 어떤 데이터가 브라우저를 떠나도록 허용되기 전에 수행되어야만 하는 추가 처리를 정의한다. 기술된 동작은 브라우저 내에서 실행 중인 스크립트에 대한 어떠한 변경들도 요구함이 없이, 그 브라우저의 구성된 언어 프로그램 코드(structured-language program code)로 구현된다.

데이터를 전송할 수 있는 것으로 식별되는 어떤 스크립팅 동작은 그것의 입력 데이터의 태그들에 대해 조건이 만들어진다. 하나의 스크립트 명령의 입력 데이터는 앞서의 스크립트 명령의 출력일 수 있는데, 이 경우 위에서 기술된 태그들의 전파는 데이터 전송을 제어하기 위한 관련 태그를 걸정할 것이다. 전송 제어는 스크립팅 엔진(240)의 한 컴포넌트로서 구현될 수 있거나, 그 브라우저 내에서 개별적으로 구현될 수 있다. 만약 아래에서 정의된 규칙들에 따라 데이터가 전송될 수 없다면, 전송 동작은 완료하지 않아야 한다. 동작은 또한 바람직하게는 하나의 에러를 보고한다(사용자에게 반드시 적접적으로 할 필요는 없음).

일부 전송 동작들은 다수의 입력들을 취하며, 이러한 다수의 입력들은 잠재적으로 다른 태그들을 가질 수 있다. 이 경우, 전송을 위한 규칙들이 선행되기 전에, 태그들은 태그 전파기(270)를 참조하여 위에서 기술된 바와 같이 결합되어야 한다.

만약 전송되고 있는 데이터가 어떤 타입의 어떠한 출처 태그도 갖지 않는다면, 그것은 자유롭게(freely) 보내질 수 있다. 이는 본 발명을 구현하지 않는 브라우저들에서의 상황이며(만약 다른 데이터 보호 메커니즘이 제공되지 않는다면), 뿐만 아니라 민감하지 않은(non-sensitive) 데이터를 처리하는 브라우즈들을 위한 것이다.

만약 데이터가 특별한 "노웨어(NOWHERE)" 태그를 갖는다면, 그것은 로컬 스크립팅 환경 외부로 전송되지 않을 수 있다.

만약 데이터가 타입 "출처(ORIGIN)"의 출처 태그를 갖는다면, 그 데이터는 단지 그것의 태그와 호환가능한(compatible) 위치로 전송될 수 있다. 호환가능한 위치는 다음 중의 하나이다.

- 똑같은 DNS 도메인, 또는 그것의 서브도메인을 가짐(예를 들어, 출처가 "dev.company.com"인 데이터는 "docstore.dev.company.com"으로 보내질 수 있음);

- 태그 내에 규정된 포트 번호에 대응하는 인터넷 프로토콜 포트 상에 존재(reside)(만약 그 태그가 포트 번호를 규정한다면); 및

- 만약 태그가 경로를 규정한다면, 또한 그 경로 또는 그로부터 유래한 것(descendant)에 존재한다(예를 들어, 출처가 경로 "/app/expensetool"인 데이터가 "/apps/expensetool/submitform"으로 보내질 수 있다).

만약 데이터가 특정 "로컬(LOCAL)" 태그를 전달한다면, 다음의 규칙들이 브라우저에 의해 구현될 수 있다.

1. 만약 "출처(ORIGIN)" 또는 "노웨어(NOWHERE)" 태그들 중 어느 하나를 갖는 스크립팅 엔진에 어떠한 데이터도 없다면, 브라우저는 어떠한 민감한 데이터도 포함되지 않다고 추정할 수 있고, "로컬(LOCAL)" 데이터가 어디로든 보내지도록 허용할 수 있다. 이것은 기존의 웹 페이지들 및 어플리케이션들의 동작을 변경하지 않는 이점을 갖지만, 먼저 새로운 데이터 엘리먼트를 생성할 경우 잠재적인 보안 노출을 회피하기 위해 로컬(LOCAL) 태그를 갖는 데이터를 위해 다른 동작(alternative behaviour)이 더 바람직할 수 있다.

2. 만약 엔진에서의 데이터의 일부가 민감하다면, 브라우저는 "로컬(LOCAL)" 데이터의 전송을 방지하거나, "로컬(LOCAL)" 정보를 전송하기 전에 사용자에게 묻도록 구성될 수 있다. 그러나, 만약 사용자에게 결정들을 위임(delegate)한다면, 사용자들은 때로는 그들이 해서는 안될 때 보안 노출들을 받아들인다는 것이 이해되어야 한다. 많은 경우들에서, 사용자에 의해 입력된 데이터는 그것이 전송되기 전에 출처(ORIGIN) 태그된 데이터와 정상적인 처리을 통해 결합될 것이고, 그래서 "로컬(LOCAL)" 태그들에 대한 규칙들보다 오히려 "출처(ORIGIN)" 태그들에 대한 규칙들이 선행할 것이다.

3. 브라우저에서의 모든 출처 태그들이 동일할 경우, "로컬(LOCAL)" 데이터의 전송을 그러한 출처로 허용함(여전히 어디에서든 그것의 전파(dissemination)를 문의(question)하며)에 의해 사용자 제어에 의존하지 않고 더 많은 케이스들(cases)이 처리될 수 있다. 이 해결책은 보안 및 보안 문서 편집 어플리케이션들과 같은 일반적인 경우들에서의 사용에 균형을 둔다.

위에서 기술된 규칙들의 세트는 데이터 보안과 사용자 경험의 지장(disruption) 사이에 균형을 맞추는 한편, 브라우저가 그러한 정보의 민감성에 관한 어떠한 분명한 지식도 갖지 않을 수 있다는 것을 인식한다.

5. 암호화된 데이터에 대한 확장

위에서 기술된 특징들은 민감한 정보의 전송을 제어하기 위한 완전하고 바람직한 시스템을 제공한다. 그러나, 암호화된 데이터(encrypted data)의 개념을 포함함에 의해, 더 유용한 능력들을 제공하는 방법으로 이들 기술들(facilities)을 확장하는 것이 가능하다. 이것은 전송되는 데이터 스트림들의 어떤 SSL 암호화로부터 완전히 분리된다는 것을 주목하자.

이 기술은 변경되지 않은 스크립트들 및 페이지들로써 구현가능한 기본적인 발명과 달리, 스크립트들이 특별하게 그것을 사용하도록 쓰여질 것을 요구한다. 확장을 지원하기 위해, 새로운 동작들은, 적절하게 공개(publish)된 암호를 사용하여 암호화된 형태로 그리고 암호화된 형태로부터 변환할 수 있는 스크립팅 엔진에서 이용가능해질 것이다.

출처 태그의 다섯 번째 종류가 부가된다. 그것은 "암호화(ENCRYPTED)" 이다. 암호화된 데이터에 대한 규칙들은 다음과 같다.

생성(Creation) : 데이터 암호화에 이를 수 있는데, 이 경우 암호화는 적절한 HTTP 헤더(그것을 가졌던(carried) 전송시에)에 의해 표시된다. 스크립팅 엔진의 분명한 암호화 지원은 기존의 데이터를 암호화하는 스크립팅 동작을 수행하기 위해 사용되는 경우, 그 결과는 또한 그것이 가질 수 있었던 어떤 이전의 태그에 관계없이 이 암호화(ENCRYPTED) 태그를 가지고 라벨링된다.

전파(Propagation) : 일반적으로, 암호화된 데이터를 다른 정보와 결합하는 것은 유용할 것 같지 않다. 그러나 그 경우, 출력은 위에서 기술되는 정상적인 전파에 대한 것과 같은 암호화되지 않은 입력 엘리먼트의 태그(또는 만약 하나보다 많이 있다면 가장 제한적인 그러한 태그)를 획득하는 것이 가능하다.

암호해제(Decryption) : 암호화된 데이터가 스크립팅 엔진의 기술을 사용하여 암호해제되는 경우, 출력에 "노웨어(NOWHERE)"의 출처 태그가 제공되고 전송될 수 없다.

전송(Transmission) : 암호화(ENCRYPTED)로 태그된 데이터는, 키(key)를 보유하지 않는 어떤 엔티티(entity)에게 그 데이터는 소용없으므로, 어디로든 전송될 수 있다.

따라서, 본 발명은, 개개의 데이터 엘리먼트들을 태그하거나 웹 페이지들, 파일들 또는 데이터베이스들 - 이것들은 민감한 데이터를 포함함 - 을 태그하여, 출처의 표시를 민감한 데이터와 연관시키고, 그런 다음 그 태그들에 따라 그 데이터의 앞으로의(onward) 전송을 제어한다. 민감한 데이터는 사용자에 의해 클라이언트 데이터 처리 시스템 내에 입력될 수 있고, 그 데이터는 저장된 웹 페이지들 내에서와 같이 보안 콘텐츠 서버 상에서 유지될 수 있으나, 발명은 그것의 앞으로의 전송을 제어하는 것을 보여주기 위해 충분히 민감한 것으로 고려되는 어떤 데이터에 적용가능하다. 본 발명의 위에서 기술된 실시예들에서, 매우 많은 데이터는 이런 방식으로 제한된 그것의 앞으로의 전송을 갖지 않을 것이다. 왜냐하면, 인터넷을 통해 이용가능한 방대한 량의 데이터는 공개적으로 이용가능할 것으로 의도되기 때문이고, 특정 부분의 정보를 생성 또는 컴파일한 개인 또는 조직은 어떠한 보호도 필요없다고 결정할 수 있기 때문이다. 그러나, 또한 데이터 처리 네트워크들을 통해 접근가능한 매우 많은 소유 정보(proprietary information)가 있고 '신뢰할 수 없는(untrusted)' 스크립트들에 의해 노출될 수 없으며, 만약 사용자들이 그들의 정보를 다른 사람들에게 노출함이 없이 이용가능한 웹 서비스들 및 스크립트들의 안전하고 효과적인 사용을 한다면 더 보호될 필요가 있다.

위에서 기술된 발명의 특정 실시예들은 본 발명의 범위 내에서 다양한 방법들로 변형되거나 확장될 수 있으며, 실시예들에 관한 위의 상세한 설명은 발명에 대한 한정이라기 보다는 예로서 고려되어야 한다는 것을 당해 기술 분야에서 숙련된 자라면 이해할 것이다.

예를 들어, 위에서 기술된 새로운 요청 헤더들은 단지 발명의 하나의 가능한 구현을 표현하고 있으며, 발명의 다른 구현은 새로운 요청된 헤더들을 요구하지 않는다. 그 대신에, 타입 XMLHttpRequest의 요청들의 사용에 대한 보안 제약(security constraint)은 발명의 일 실시예에 따른 변경된 스크립팅 엔진에 의해 완화(relax) 및 대체되며, 그것이 제3자(third-party) 웹 사이트로부터 획득될 때마다 민감한 것으로서 데이터를 태그한다. 타입 XMLHttpRequest의 요청들은 현재 그 스크립트가 다운로드된 것 이외의 다른 서버들로부터 데이터를 획득하기 위해 스크립트에 의해 사용될 수 없다(적어도 직접적으로는 아님). 이는 악성 JavaScript가 사용자의 자격증명(credentials), 또는 방화벽 뒤의 사용자의 데이터 처리 시스템의 위치를 이용하는 공격을 방지하기 위한 것이고, 웹 브라우저 내에 제3 사이트로부터 데이터를 읽고, 그런 다음 그 데이터를 그 스크립트가 기원된(originated) 사이트로 데이터를 다시 전송하기 위한 것이다. 이것은 "크로스 사이트 스크립팅 취약성(cross-site-scripting vulnerability)"으로 알려져 있다. 본 발명의 일 실시예에 따라 스크립팅 엔진 내에 출처 태그들을 사용하여, 다운로드된 데이터를 민감한 것으로 식별하는 경우, 그러한 공격은 XMLHttpRequest에 대해 알려진 제한에 의지함이 없이 방지될 수 있다. 그리하여, 유용한 처리를 위해 제3자 사이트들로부터의 데이터의 다운로딩을 허용할 수 있으며, 그러한 데이터를 보안 유지에 대해 민감한 것으로 태그한다.

두 번째, 다른 브라우저들은 "민감한 데이터" 플래그를 포함하는 데이터를 받는 것에 응답하여 출처 태그들을 삽입하기 위해 다른 메커니즘들을 구현할 수 있으며, 관련 데이터 구조들 내에서 카테고리들 및 출처 태그들의 특정 표현은 발명의 다른 실시예들 사이에서 변할 수 있다. 당해 기술 분야에서 통상의 기술을 가진 자는, 일단 그들이 원하는 동작의 위의 설명을 읽는 경우, 본 특허 명세서에 정의된 발명의 범위 내에서 다양한 구현 옵션들이 있다는 것을 알 것이다.

Claims (18)

1. 스크립팅 환경 내에서 수행되는 데이터의 전송을 제어하는 방법으로서,
   출처(origin)의 표시(indication)를 제1 데이터 엘리먼트와 연관시키는 단계;
   상기 제1 데이터 엘리먼트로부터 발생된(generated) 데이터 엘리먼트에 상기 출처의 표시를 전파(propagate)하는 단계; 및
   상기 제1 데이터 엘리먼트 및 상기 발생된 데이터 엘리먼트의 전송을 허가된 목적지들(permitted destinations) - 상기 허가된 목적지들은 상기 출처의 표시를 참조하여 식별됨 - 만으로 제한하는 단계를 포함하는,
   방법.
2. 삭제
3. 삭제
4. 청구항 1에 있어서, 상기 제1 데이터 엘리먼트는 상기 스크립팅 엘리먼트로부터 원격(remote)인 소스 데이터 처리 시스템으로부터 획득되고, 상기 전송을 제한하는 단계는 상기 소스 데이터 처리 시스템 이외의 목적지로의 상기 제1 데이터 엘리먼트의 전송을 방지하는 단계를 포함하는,
   방법.
5. 청구항 1에 있어서, 상기 출처의 표시를 제1 데이터 엘리먼트와 연관시키는 단계는 상기 제1 데이터 엘리먼트가 스크립팅 동작에 의해 처리되어야 한다는 것을 결정하는 것에 응답하여 수행되는,
   방법.
6. 청구항 1에 있어서, 상기 연관시키는 단계, 전파하는 단계 및 제한하는 단계는 원격 서버 데이터 처리 장치와 통신하기 위한 네트워크 연결 인터페이스를 포함하는 클라이언트 데이터 처리 장치 상에서 수행되고;
   여기서, 상기 방법은,
   상기 원격 서버 데이터 처리 장치로부터부터 상기 제1 데이터 엘리먼트를 검색(retrieve)하기 위해, 상기 네트워크 연결 인터페이스를 통해 상기 원격 서버 데이터 처리 장치에 대한 요청을 보내는 단계; 및
   상기 원격 서버 데이터 처리 장치로부터 데이터를 받는 단계를 더 포함하는,
   방법.
7. 삭제
8. 삭제
9. 삭제
10. 삭제
11. 청구항 1에 있어서, 상기 출처의 표시들을 전파하는 단계는,
    하나 또는 그 이상의 출력들을 발생하는 스크립팅 동작에 대한 하나 또는 그 이상의 입력들의 세트를 식별하는 단계;
    상기 하나 또는 그 이상의 입력들과 연관되는 출처의 어떤 표시들을 식별하는 단계;
    출처의 상기 입력들의 표시들로부터 출처의 제2 표시들을 파생시키는(deriving) 단계; 및
    상기 하나 또는 그 이상의 발생된 출력들과 연관된 상기 출처의 제2 표시들을 저장하는 단계를 포함하는,
    방법.
12. 청구항 1에 있어서, 상기 제1 데이터 엘리먼트는 상기 스크립팅 환경으로부터 원격인 데이터 처리 시스템으로부터 스크립팅 동작에 의해 검색되는,
    방법.
13. 데이터 처리 시스템에 있어서,
    적어도 하나의 데이터 처리 유닛;
    적어도 하나의 데이터 스토리지 유닛;
    스크립트 인터프리터;
    출처(origin)의 표시(indication)를 제1 데이터 엘리먼트와 연관시키기 위한 수단;
    상기 제1 데이터 엘리먼트로부터 발생된 데이터 엘리먼트에 상기 출처의 표시를 전파하기 위한 수단; 및
    상기 제1 데이터 엘리먼트 및 상기 발생된 데이터 엘리먼트의 전송들을 허가된 목적지들(permitted destinations) - 상기 허가된 목적지들은 상기 출처의 표시를 참조하여 식별됨 - 만으로 제한하기 위한 수단을 포함하고,
    상기 출처의 표시를 전파하기 위한 수단은,
    하나 이상의 출력들을 발생하는 스크립팅 동작에 대한 하나 이상의 입력들의 세트를 식별하고, 상기 하나 이상의 입력들과 연관되는 출처의 어떤 표시들을 식별하고, 상기 입력들의 출처의 표시로부터 출처의 제2 표시들을 파생시키고, 발생된 하나 이상의 상기 출력들과 연관된 상기 출처의 제2 표시들을 저장하기 위한 수단을 포함하는,
    데이터 처리 시스템.
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 데이터 처리 장치를 제어하기 위한 프로그램 코드가 기록되는 기록 매체에 있어서,
    상기 프로그램 코드는 스크립팅 환경에서 데이터 전송을 제어하기 위하여,
    출처의 표시를 제1 데이터 엘리먼트와 연관시키는 단계; 및
    상기 제1 데이터 엘리먼트로부터 발생된 데이터 엘리먼트로 출처의 표시들을 전파하는 단계 -상기 출처의 표시들을 전파하는 단계는 하나 이상의 출력들을 발생하는 스크립팅 동작에 대한 하나 이상의 입력들의 세트를 식별하고, 상기 하나 이상의 입력들과 연관되는 출처의 어떤 표시들을 식별하고, 상기 입력들의 출처의 표시로부터 출처의 제2 표시들을 파생시키고, 발생된 하나 이상의 상기 출력들과 연관된 상기 출처의 제2 표시들을 저장함- ;를 포함하는 프로세스를 실행하는 것인,
    기록 매체.
    

Images