KR102583399B1 - PDF에서 Link의 무해화를 위한 방법 및 장치 - Google Patents

PDF에서 Link의 무해화를 위한 방법 및 장치 Download PDF

Info

Publication number
KR102583399B1
KR102583399B1 KR1020237004697A KR20237004697A KR102583399B1 KR 102583399 B1 KR102583399 B1 KR 102583399B1 KR 1020237004697 A KR1020237004697 A KR 1020237004697A KR 20237004697 A KR20237004697 A KR 20237004697A KR 102583399 B1 KR102583399 B1 KR 102583399B1
Authority
KR
South Korea
Prior art keywords
uri
file
server
link
information
Prior art date
Application number
KR1020237004697A
Other languages
English (en)
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 시큐레터 주식회사
Application granted granted Critical
Publication of KR102583399B1 publication Critical patent/KR102583399B1/ko

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
    • G06F16/9566—URL specific, e.g. using aliases, detecting broken or misspelled links
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/561—Virus type analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

본 명세서는 서버가 비실행 파일을 무해화(Disarming) 시키는 방법에 있어서, 상기 비실행 파일의 포맷이 PDF 파일인 것에 근거하여, 상기 PDF 파일의 기본 요소들을 기준으로 순회하여, 자료형(dictionary type)을 탐색하고, “S” 키, 및 “URI” 키에 근거하여, 상기 자료형에 URI entry가 포함되어 있는 지를 검사하고, 상기 URI entry가 포함되어 있는 것에 근거하여, 상기 URI entry를 무해화하며, 상기 URI entry를 무해화하기 위해, 상기 “URI” 키의 ASCII string값에서 Link의 스키마(schema) 정보만을 유지시킬 수 있다.

Description

PDF에서 Link의 무해화를 위한 방법 및 장치 {METHODS AND APPARATUS FOR DISARMING A LINK IN PDF}
본 명세서는 PDF 문서에서 Link의 무해화를 위한 방법 및 장치에 관한 것이다.
지능형 지속 위협(APT: Advanced Persistent Threat) 공격은 공격자가 특정 타깃을 정하고 목표한 정보를 빼내기 위해 고도의 공격기법을 적용하여 지속적으로 다양한 형태의 악성 코드를 활용한다.
특히 APT 공격은 초기 침입단계에서 탐지하지 못하는 경우가 많으며, 주로 악성 코드를 포함하는 비실행((Non-PE: Non-Portable Executable) 파일을 이용하는 경우가 많다.
비실행 파일의 악성 여부 검사 방법으로, 시그니처 기반의 검사 방법이 있다. 이것은 비실행 파일이 악성 코드의 시그니처를 포함하는지를 검사하는 방법이다. 그런데 대부분의 악성 비실행 파일은 악성 코드를 자바스크립트나 매크로스크립트와 같은 스크립트에 포함시키거나 경우에 따라서는 스크립트를 인코딩하여 이러한 진단을 회피하는데, 비실행 파일 자체로는 그 안에 어떤 스크립트가 존재하는지 알기 어렵다. 따라서 기존의 시그니처 기반 검사 방법으로는 비실행 파일의 악성 여부를 제대로 검사하는 것이 거의 불가능하다.
본 명세서의 목적은, PDF의 전체 구조를 유지하면서 Link를 무해화 하기 위한 방법을 제안한다.
본 명세서가 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 이하의 명세서의 상세한 설명으로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
본 명세서의 일 양상은,서버가 비실행 파일을 무해화(Disarming) 시키는 방법에 있어서, 상기 비실행 파일의 포맷이 PDF 파일인 것에 근거하여, 상기 PDF 파일의 기본 요소들을 기준으로 순회하여, 자료형(dictionary type)을 탐색하는 단계; “S” 키, 및 “URI” 키에 근거하여, 상기 자료형에 URI entry가 포함되어 있는 지를 검사하는 단계; 및 상기 URI entry가 포함되어 있는 것에 근거하여, 상기 URI entry를 무해화하는 단계;를 포함하며, 상기 URI entry를 무해화하는 단계는 상기 “URI” 키의 ASCII string값에서 Link의 스키마(schema) 정보만을 유지시키는 단계; 를 포함할 수 있다.
또한, 상기 자료형은 URI 액션(action) 개체를 포함할 수 있다.
본 명세서의 또 다른 일 양상은, 비실행 파일을 무해화(Disarming) 시키는 서버에 있어서, 통신부; 메모리; 및 상기 통신부 및 상기 메모리를 기능적으로 제어하는 프로세서;를 포함하고, 상기 프로세서는 상기 비실행 파일의 포맷이 PDF 파일인 것에 근거하여, 상기 PDF 파일의 기본 요소들을 기준으로 순회하여, 자료형(dictionary type)을 탐색하고, “S” 키, 및 “URI” 키에 근거하여, 상기 자료형에 URI entry가 포함되어 있는 지를 검사하며, 상기 URI entry가 포함되어 있는 것에 근거하여, 상기 URI entry를 무해화하고, 상기 URI entry를 무해화하기 위해, 상기 “URI” 키의 ASCII string값에서 Link의 스키마(schema) 정보만을 유지시킬 수 있다.
본 명세서의 실시예에 따르면, PDF의 전체 구조를 유지하면서 Link를 무해화를 수행할 수 있다.
본 명세서에서 얻을 수 있는 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 명세서가 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 본 명세서와 관련된 서버 또는 클라이언트를 나타내는 도면이다.
도 2는 본 명세서에 적용될 수 있는 비정상 입력의 예시이다.
도 3은 본 명세서가 적용될 수 있는 무해화 방법을 예시한다.
도 4는 본 명세서가 적용될 수 있는 HWP 파일의 무해화 방법을 예시한다.
도 5는 본 명세서가 적용될 수 있는 일반적인 HWP 파일의 구조를 예시한다.
도 6은 본 명세서가 적용될 수 있는 레코드(record) 구조의 예시이다.
도 7은 본 명세서가 적용될 수 있는 Section 스트림의 레코드의 예시이다.
도 8은 본 명세서가 적용될 수 있는 텍스트 하이퍼 링크를 지시하는 레코드의 예시이다.
도 9는 본 명세서가 적용될 수 있는 개체 하이퍼 링크를 지시하는 레코드의 예시이다.
도 10은 본 명세서가 적용될 수 있는 자료 연결을 지시하는 레코드의 예시이다.
도 11은 본 명세서가 적용될 수 있는 PDF 파일의 무해화 방법을 예시한다.
본 명세서에 관한 이해를 돕기 위해 상세한 설명의 일부로 포함되는, 첨부 도면은 본 명세서에 대한 실시예를 제공하고, 상세한 설명과 함께 본 명세서의 기술적 특징을 설명한다.
이하, 첨부된 도면을 참조하여 본 명세서에 개시된 실시예를 상세히 설명하되, 도면 부호에 관계없이 동일하거나 유사한 구성요소는 동일한 참조 번호를 부여하고 이에 대한 중복되는 설명은 생략하기로 한다. 이하의 설명에서 사용되는 구성요소에 대한 접미사 "모듈" 및 "부"는 명세서 작성의 용이함만이 고려되어 부여되거나 혼용되는 것으로서, 그 자체로 서로 구별되는 의미 또는 역할을 갖는 것은 아니다. 또한, 본 명세서에 개시된 실시예를 설명함에 있어서 관련된 공지 기술에 대한 구체적인 설명이 본 명세서에 개시된 실시예의 요지를 흐릴 수 있다고 판단되는 경우 그 상세한 설명을 생략한다. 또한, 첨부된 도면은 본 명세서에 개시된 실시예를 쉽게 이해할 수 있도록 하기 위한 것일 뿐, 첨부된 도면에 의해 본 명세서에 개시된 기술적 사상이 제한되지 않으며, 본 명세서의 사상 및 기술 범위에 포함되는 모든 변경, 균등물 내지 대체물을 포함하는 것으로 이해되어야 한다.
제1, 제2 등과 같이 서수를 포함하는 용어는 다양한 구성요소들을 설명하는데 사용될 수 있지만, 상기 구성요소들은 상기 용어들에 의해 한정되지는 않는다. 상기 용어들은 하나의 구성요소를 다른 구성요소로부터 구별하는 목적으로만 사용된다.
어떤 구성요소가 다른 구성요소에 "연결되어" 있다거나 "접속되어" 있다고 언급된 때에는, 그 다른 구성요소에 직접적으로 연결되어 있거나 또는 접속되어 있을 수도 있지만, 중간에 다른 구성요소가 존재할 수도 있다고 이해되어야 할 것이다. 반면에, 어떤 구성요소가 다른 구성요소에 "직접 연결되어" 있다거나 "직접 접속되어" 있다고 언급된 때에는, 중간에 다른 구성요소가 존재하지 않는 것으로 이해되어야 할 것이다.
단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다.
본 명세서에서, "포함한다" 또는 "가지다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.
또한, 명세서에서 사용되는 "부"라는 용어는 소프트웨어 또는 하드웨어 구성요소를 의미하며, "부"는 어떤 역할들을 수행한다. 그렇지만 "부"는 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. "부"는 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 "부"는 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로 코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들 및 변수들을 포함한다. 구성요소들과 "부"들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 "부"들로 결합되거나 추가적인 구성요소들과 "부"들로 더 분리될 수 있다.
또한, 본 명세서의 일 실시예에 따르면 "부"는 프로세서 및 메모리로 구현될 수 있다. 용어 "프로세서"는 범용 프로세서, 중앙 처리 장치 (CPU), 마이크로프로세서, 디지털 신호 프로세서 (DSP), 제어기, 마이크로제어기, 상태 머신 등을 포함하도록 넓게 해석되어야 한다. 몇몇 환경에서는, "프로세서"는 주문형 반도체 (ASIC), 프로그램가능 로직 디바이스 (PLD), 필드 프로그램가능 게이트 어레이 (FPGA) 등을 지칭할 수도 있다. 용어 "프로세서"는, 예를 들어, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들의 조합, DSP 코어와 결합한 하나 이상의 마이크로프로세서들의 조합, 또는 임의의 다른 그러한 구성들의 조합과 같은 처리 디바이스들의 조합을 지칭할 수도 있다.
용어 "메모리"는 전자 정보를 저장 가능한 임의의 전자 컴포넌트를 포함하도록 넓게 해석되어야 한다. 용어 메모리는 임의 액세스 메모리 (RAM), 판독-전용 메모리 (ROM), 비-휘발성 임의 액세스 메모리 (NVRAM), 프로그램가능 판독-전용 메모리 (PROM), 소거-프로그램가능 판독 전용 메모리 (EPROM), 전기적으로 소거가능 PROM (EEPROM), 플래쉬 메모리, 자기 또는 광학 데이터 저장장치, 레지스터들 등과 같은 프로세서-판독가능 매체의 다양한 유형들을 지칭할 수도 있다. 프로세서가 메모리로부터 정보를 판독하고/하거나 메모리에 정보를 기록할 수 있다면 메모리는 프로세서와 전자 통신 상태에 있다고 불린다. 프로세서에 집적된 메모리는 프로세서와 전자 통신 상태에 있다.
본 명세서에서 사용되는 "비실행 파일"이란 실행 파일 또는 실행 가능한 파일과 반대되는 개념으로서 자체적으로 실행되지 않는 파일을 의미한다. 예를 들어, 비실행 파일은 PDF 파일, 한글 파일, 워드 파일과 같은 문서 파일, JPG 파일과 같은 이미지 파일, 동영상 파일, 자바 스크립트 파일, HTML 파일 등이 될 수 있으나, 이에 한정되지 않는다.
아래에서는 첨부한 도면을 참고하여 실시예에 대하여 본 명세서가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그리고 도면에서 본 개시를 명확하게 설명하기 위해서 설명과 관계없는 부분들은 생략될 수 있다.
도 1은 본 명세서와 관련된 서버 또는 클라이언트를 나타내는 도면이다.
본 명세서에서 서버(또는 클라우드 서버) 또는 클라이언트는 제어부(100) 및 통신부(130)를 포함할 수 있다. 제어부(100)는 프로세서(110) 및 메모리(120)를 포함할 수 있다. 프로세서(110)는 메모리(120)에 저장된 명령어들을 수행할 수 있다. 프로세서(110)는 통신부(130)를 제어할 수 있다.
프로세서(110)는 메모리(120)에 저장된 명령어에 기초하여 서버 또는 클라이언트의 동작을 제어할 수 있다. 서버 또는 클라이언트는 하나의 프로세서를 포함할 수 있고, 복수의 프로세서를 포함할 수 있다. 서버 또는 클라이언트가 복수의 프로세서를 포함하는 경우, 복수의 프로세서 중 적어도 일부는 물리적으로 이격된 거리에 위치할 수 있다. 또한, 서버 또는 클라이언트는 이에 한정되지 않고 알려진 다양한 방식으로 구현될 수 있다.
통신부(130)는, 서버 또는 클라이언트와 무선 통신 시스템 사이, 서버 또는 클라이언트와 다른 서버 또는 클라이언트 사이, 또는 서버 또는 클라이언트와 외부서버 사이의 무선 통신을 가능하게 하는 하나 이상의 모듈을 포함할 수 있다. 또한, 통신부(110)는, 서버 또는 클라이언트를 하나 이상의 네트워크에 연결하는 하나 이상의 모듈을 포함할 수 있다.
제어부(100)는 메모리(120)에 저장된 응용 프로그램을 구동하기 위하여, 서버 또는 클라이언트의 구성요소들 중 적어도 일부를 제어할 수 있다. 나아가, 제어부(100)는 상기 응용 프로그램의 구동을 위하여, 서버 또는 클라이언트에 포함된 구성요소들 중 적어도 둘 이상을 서로 조합하여 동작 시킬 수 있다.
본 명세서에서 서버는 리버싱 엔진 또는/및 CDR 서비스를 제공하는 CDR 엔진을 포함할 수 있다.
리버싱(Reversing) 엔진
리버싱 엔진이란, 악성 비실행 파일에 대한 리버스 엔지니어링(리버싱) 과정을 자동화 한 분석/진단 엔진이다.
예를 들어, 리버싱 엔진은 다음의 단계를 수행할 수 있다.
1. 파일 분석: 비실행 파일 자체의 외관(예를 들어, 속성, 작성자, 작성 날짜, 파일 타입)을 분석하는 단계로서, 일반 백신 프로그램과 유사하게 비실행 파일 자체의 정보만으로 악성여부를 진단할 수 있다.
2. 정적 분석: 비실행 파일 내의 데이터를 추출, 분석해서 정상, 악성 여부를 판별하는 단계로서, 비실행 파일은 실행하지 않고 파일 구조에 맞게 내부 데이터를 추출하여 비교 분석하여 악성여부를 진단할 수 있다. 이는 매크로, URL 추출 분석 등에 적합할 수 있다.
3. 동적 분석: 비실행 파일을 실행하고 모니터링하면서 행위를 분석하여 악성 여부를 판별하는 단계로서, 매크로, 하이퍼링크, DDE 등 정상기능을 이용한 악성 행위를 탐지하기에 용이하다.
4. 디버깅 분석: 비실행 파일을 실행하고 디버깅하여 취약점, 익스플로잇 등을 분석하는 단계로서, 매크로, 하이퍼링크, DDE를 포함하여 문서 내 본문, 표, 폰트, 그림 등을 이용한 응용프로그램의 취약점을 탐지하기에 적합하다.
리버싱 엔진은 디버깅 분석에 사용될 수 있는 디버깅 엔진을 포함할 수 있다. 디버깅 엔진은 비실행 파일의 열람 과정을 디버깅하여 문서 입력, 처리, 출력단계에서 발생하는 취약점을 진단할 수 있다. 여기서 취약점이란, 응용프로그램이 응용프로그램의 개발자가 개발한 코드(로직)에서 예상하지 못한 값을 입력 받았을 때, 발생하는 오류, 버그 등을 이용하는 것으로서, 공격자는 취약점을 통해 비정상 종료로 인한 서비스 거부, 원격 코드 실행 등의 악성 행위를 실행할 수 있다.
CDR(Contents Disarm and Reconstruction)
CDR 서비스는 비실행 파일을 분해해 악성파일 혹은 불필요한 파일을 제거하고 콘텐츠는 원본과 최대한 동일하게 하여, 새로운 파일을 만드는 솔루션이다.
즉, Contents Disarm and Reconstruction(CDR)은 문서 내의 컨텐츠를 무해화(Disarm)하고 재조합(Reconstruction)하여 안전한 문서를 만들어 고객에게 제공하는 서비스를 의미하며, 무해화 대상 파일은 비실행 파일 일체(예를 들어, 워드, 엑셀, 파워포인트, 한글, PDF)를 대상으로 할 수 있으며, 무해화 대상 컨텐츠는 액티브 컨텐츠(예를 들어, 매크로, 하이퍼링크, OLE 객체 등)일 수 있다.
도 2는 본 명세서에 적용될 수 있는 비정상 입력의 예시이다.
도 2를 참조하면, 응용프로그램은 비실행 파일을 통해, 비정상적인 값(예를 들어, 입력값이 정상범위인 2를 초과하는 경우)을 입력 받는 경우, 개발자가 의도하지 않은 실행흐름으로 변경되어 취약점이 동작될 수 있다. 디버깅 엔진은 문서 열람 과정을 자동 디버깅하여 취약점과 관련된 특정 지점에 브레이크 포인트를 설정하고 입력값과 관련된 특정값을 확인하여 입력값이 취약점을 일으키는 값인지 아닌지 판별하여 악성 여부를 진단할 수 있다.
보다 자세하게, 디버깅 엔진은 비실행 파일을 확인하고 이를 열람하기 위한 응용프로그램을 실행하여 디버깅을 시작할 수 있다. 비실행 파일을 열람하는 과정에서 모듈이 로드되면, 디버깅 엔진은 해당 모듈이 분석 대상 모듈인지 확인하고, 분석 대상이라면 지정된 주소에 브레이크 포인트를 설정할 수 있다.
예를 들어, 악성 비실행 파일은 응용프로그램의 버전이나 운영체제 환경 등의 특정 조건이 만족하지 않으면 응용프로그램을 종료하거나 아무런 악성 행위가 발생하지 않는 흐름으로 분기하는 분기 지점들을 가질 수 있다. 서버는 사전에 분석가에 의해 분석되어 이러한 가능성을 가지는 분기 지점에 브레이크 포인트를 설정할 수 있다.
또한, 서버는 해당 분기 지점과 연관되어, 응용프로그램을 종료하지 않고 계속 실행하거나 악성 행위가 발생할 수 있는 흐름으로 유도할 수 있는 조건들을 설정할 수 있다.
응용프로그램의 프로세스 실행 중 해당 브레이크 포인트 지점에서 프로세스가 멈춘 경우, 서버는 탐지 로직에 따라 취약점 여부를 탐지한 후, 결과를 분석 리포트에 저장하는 단계를 수행할 수 있다.
서버에 포함된 자동화 리버싱 엔진은 전술한 단계들을 자동으로 수행하면서 분석하여 분석가가 연구, 개발한 진단 알고리즘을 통해, 악성 비실행 파일을 진단하고 차단할 수 있다.
도 3는 본 명세서가 적용될 수 있는 무해화 방법을 예시한다.
도 3을 참조하면, 서버는 비실행 파일의 문서 포맷을 판단할 수 있다(S3010). 예를 들어, 서버는 비실행 파일의 문서 포맷을 판단하기 위해, 비실행 파일을 열고 바이너리 코드 상의 식별(Signature) 타입을 확인하여, 문서의 포맷이 무엇인지 확인할 수 있다.
예를 들어, 비실행 파일들은 각각 고유한 포맷을 가지고 있는데 포맷의 기본이 되는 내용이 파일 시그니처(File Signature)이다. 파일 시그니처는 파일의 가장 처음에 위치하는 특정 바이트들도 파일 포맷을 구분하기 위해 사용될 수 있다.
예를 들어, HWP 파일은 “D0 CF 11 E0 A1 B1 1A E1″의 시그니처를 갖을 수 있고, PDF 파일은 “25 50 44 46”의 시그니처를 갖을 수 있다.
서버는 비실행 파일의 포맷을 PDF 파일로 판단한 경우, PDF 파일의 무해화를 수행하고(S3020), 비실행 파일의 포맷을 HWP 파일로 판단한 경우, HWP 파일의 무해화를 수행할 수 있다(S3030).
*도 4는 본 명세서가 적용될 수 있는 HWP 파일의 무해화 방법을 예시한다.
도 4를 참조하면, 서버가 비실행 파일의 포맷을 HWP 파일로 판단한 경우, HWP 파일의 무해화 방법을 예시한다.
HWP 파일을 비롯한 CFB 계열의 파일에 대해 압축을 해제하면, 디렉토리와 파일 구조를 확인할 수 있다. 이 때 디렉토리 형태를 스토리지(storage), 파일 형태를 스트림(stream)이라고 한다.
도 5는 본 명세서가 적용될 수 있는 일반적인 HWP 파일의 구조를 예시한다.
도 5를 참조하면, BodyText는 Section 스트림을 포함할 수 있다.
BodyText - Section 스트림 : 여기에는 문서의 본문에 해당하는 문단, 표, 그리기 개체 등의 내용들이 저장될 수 있다. 링크 정보 또한 Section 스트림에 저장될 수 있다. HWP 파일의 본문 구역에 따라 Section0, Section1 등으로 구분될 수 있다.
파일 압축 저장 : 파일 크기를 줄이기 위해 스트림은 압축 저장될 수 있다(예를 들어, zlib 방식). 압축해제 시 내용은 동일하며, Section 스트림 또한 압축 대상이다.
다시 도 4를 참조하면, 서버는 HWP 링크 기능에 따라 무해화 동작을 수행할 수 있다.
표 1은 본 명세서가 적용될 수 있는 HWP 링크 기능의 예시이다.
종류 설명
텍스트 하이퍼링크 텍스트에 설정된 하이퍼링크.
개체 하이퍼링크 그림이나 도형 등 개체에 설정된 하이퍼링크.
자료 연결 텍스트에 설정된 하이퍼링크.
본문에 표시되는 방식이 하이퍼링크와 다름.
이러한 링크 기능의 정보는 본문 영역(Section 스트림)에 저장될 수 있다.BodyText 스토리지에 Section 스트림들이 포함되며, Section 스트림은 HWP 데이터 레코드로 구성될 수 있다. 서버는 HWP 파일 내 Section 스트림을 추출하고, Section 스트림 내 모든 레코드를 순회하면서 링크 관련 레코드를 무해화 할 수 있다. 도 6은 본 명세서가 적용될 수 있는 레코드(record) 구조의 예시이다.
도 6은 한글 문서 파일 구조 5.0 (Hwp Document File Formats 5.0), revision 1.3:20181108 문서(HWP 명세)를 참조한, 레코드 구조의 예시이다.
레코드 헤더의 크기는 32bits이고 TagID(10bits), Level(10bits), Size(12bits)로 구성된다.
(1) Tag ID : 레코드가 나타내는 데이터의 종류를 나타내는 태그이다. Tag ID에는 10 비트가 사용되므로 0x000 - 0x3FF까지 가능하다.
- 0x000 - 0x00F = 일반 레코드 태그가 아닌 특별한 용도로 사용한다.
- 0x010 - 0x1FF = 한글에 의해 내부용으로 예약된 영역(HWPTAG_BEGIN = 0x010)
- 0x200 - 0x3FF = 외부 어플리케이션이 사용할 수 있는 영역
(2) Level : 대부분 하나의 오브젝트는 여러 개의 레코드로 구성되는 것이 일반적이기 때문에 하나의 레코드가 아닌 "논리적으로 연관된 연속된 레코드"라는 개념이 필요하다. 레벨은 이와 같이 연관된 레코드의 논리적인 묶음을 표현하기 위한 정보이다. 스트림을 구성하는 모든 레코드는 계층 구조로 표현할 수 있는데, 레벨은 바로 이 계층 구조에서의 depth를 나타낸다.
(3) Size : 데이터 영역의 길이를 바이트 단위로 나타낸다. 12개의 비트가 모두 1일 때는 데이터 영역의 길이가 4095 바이트 이상인 경우로, 이때는 레코드 헤더에 연이어 길이를 나타내는 DWORD가 추가된다. 즉, 4095 바이트 이상의 데이터일 때 레코드는 확장 데이터 레코드와 같이 표현된다.
다시 도 4를 참조하면, 서버는 HWP 파일로부터 레코드를 수집한다(S4010).
예를 들어, 서버는 BodyText 스토리지의 Section 스트림으로부터 레코드를 수집할 수 있다.
표 2는 본 명세서가 적용될 수 있는 본문(BodyText)의 데이터 레코드의 예시이다.
Tag ID Value 설명
HWPTAG_PARA_HEADER HWPTAG_BEGIN+50 문단 헤더
HWPTAG_PARA_TEXT HWPTAG_BEGIN+51 문단의 텍스트
HWPTAG_PARA_CHAR_SHAPE HWPTAG_BEGIN+52 문단의 글자 모양
HWPTAG_PARA_LINE_SEG HWPTAG_BEGIN+53 문단의 레이아웃
HWPTAG_PARA_RANGE_TAG HWPTAG_BEGIN+54 문단의 영역 태그
HWPTAG_CTRL_HEADER HWPTAG_BEGIN+55 컨트롤 헤더
HWPTAG_LIST_HEADER HWPTAG_BEGIN+56 문단 리스트 헤더
HWPTAG_PAGE_DEF HWPTAG_BEGIN+57 용지 설정
HWPTAG_FOOTNOTE_SHAPE HWPTAG_BEGIN+58 각주/미주 모양
HWPTAG_PAGE_BORDER_FILL HWPTAG_BEGIN+59 쪽 테두리/배경
HWPTAG_SHAPE_COMPONENT HWPTAG_BEGIN+60 개체
HWPTAG_TABLE HWPTAG_BEGIN+61 표 개체
HWPTAG_SHAPE_COMPONENT_LINE HWPTAG_BEGIN+62 직선 개체
HWPTAG_SHAPE_COMPONENT_RECTANGLE HWPTAG_BEGIN+63 사각형 개체
HWPTAG_SHAPE_COMPONENT_ELLIPSE HWPTAG_BEGIN+64 타원 개체
HWPTAG_SHAPE_COMPONENT_ARC HWPTAG_BEGIN+65 호 개체
HWPTAG_SHAPE_COMPONENT_POLYGON HWPTAG_BEGIN+66 다각형 개체
HWPTAG_SHAPE_COMPONENT_CURVE HWPTAG_BEGIN+67 곡선 개체
HWPTAG_SHAPE_COMPONENT_OLE HWPTAG_BEGIN+68 OLE 개체
HWPTAG_SHAPE_COMPONENT_PICTURE HWPTAG_BEGIN+69 그림 개체
HWPTAG_SHAPE_COMPONENT_CONTAINER HWPTAG_BEGIN+70 컨테이너 개체
HWPTAG_CTRL_DATA HWPTAG_BEGIN+71 컨트롤 임의의 데이터
HWPTAG_EQEDIT HWPTAG_BEGIN+72 수식 개체
RESERVED HWPTAG_BEGIN+73 예약
HWPTAG_SHAPE_COMPONENT_TEXTART HWPTAG_BEGIN+74 글맵시
HWPTAG_FORM_OBJECT HWPTAG_BEGIN+75 양식 개체
HWPTAG_MEMO_SHAPE HWPTAG_BEGIN+76 메모 모양
HWPTAG_MEMO_LIST HWPTAG_BEGIN+77 메모 리스트 헤더
HWPTAG_CHART_DATA HWPTAG_BEGIN+79 차트 데이터
HWPTAG_VIDEO_DATA HWPTAG_BEGIN+82 비디오 데이터
HWPTAG_SHAPE_COMPONENT_UNKNOWN HWPTAG_BEGIN+99 Unknown
표 2를 참조하면, 서버는 레코드의 헤더에서 Tag ID를 추출하여, 헤더의 의미를 판단할 수 있다. 여기서, HWPTAG_BEGIN = 0x010 일 수 있다.도 7은 본 명세서가 적용될 수 있는 Section 스트림의 레코드의 예시이다.도 7을 참조하면, 서버는 헤더정보 첫 4 바이트를 (예를 들어, 0x4200 8001) 파싱할 수 있다. 예를 들어, 서버는 헤더로부터 Tag ID를 획득하고, 표 2에 따라 Tag ID 가 문단 헤더를 의미함을 판단할 수 있다. 레코드의 헤더가 문단 헤더를 지시하는 것에 근거하여, 서버는 데이터 영역을 판단할 수 있다.
표 3은 서버가 Section 스트림의 레코드를 파싱하는 동작의 예시이다.
순서 동작
1 - 4바이트 0x4200 8001를 바이트 단위로 분리 후 역순으로 배치 바이트 단위 : 42 00 80 01(16) (2자리가 1바이트, 1자리는 4bit)
역순 배치 : 01 80 00 42(16)
비트 배치 : (Size)0000 0001 1000 (Level)0000 0000 00(Tag ID)00 0100 0010(2)
2 Tag ID는 비트 0번~9번까지 하위 10비트00 0100 0010(2)
= 0 4 2(16) (= 0x042)
= 0x010 + 0x032 = 0x010 + 50(10) => 문단 헤더를 지시함
3 데이터 영역의 Size는 비트 20번~31번까지 상위 12비트0000 0001 1000(2) = 0x018
4 Level정보는 0x0000000 0000 00(2) = 0x000
서버는 Size 값을 통해, 데이터 영역을 판단할 수 있다. 예를 들어, 서버는 헤더 영역(710) 이후, 데이터 영역(720)을 판단할 수 있다. 서버는 Tag ID 가 문단 헤더를 지시하므로, 데이터 영역을 문단 헤더 데이터로 파싱할 수 있다. 이러한 작업을 통해, 서버는 Section 스트림의 레코드를 수집할 수 있다.다시 도 4를 참조하면, 서버는 레코드가 텍스트 하이퍼 링크를 지시하는 것에 근거하여, 제1 링크 정보를 추출한다(S4020). 예를 들어, 서버는 레코드의 헤더정보에서 Tag ID가 HWPTAG_CTRL_HEADER (컨트롤 헤더)를 지시하면, 레코드가 하이퍼 링크를 지시한다고 판단할 수 있다. 이 경우, 데이터 영역은 0x6B 6C 68 25 (klh%)로 시작할 수 있다.도 8은 본 명세서가 적용될 수 있는 텍스트 하이퍼 링크를 지시하는 레코드의 예시이다.
도 8을 참조하면, 서버는 텍스트 하이퍼 링크를 지시하는 레코드의 헤더정보(810)를 분석할 수 있다.
표 4는 서버의 헤더정보 분석의 예시이다.
종류 값
헤더 0x4704 B004
바이트 단위로 역순배치 04 B0 04 47(16)
비트 단위로 배치 (Size)0000 0100 1011 (Level)0000 0000 01(Tag ID)00 0100 0111(2)
Tag ID (하위 10비트) 00 0100 0111(2)
= 0x047
= 0x010 + 0x37
= 0x010 + 55(10)
= HWPTAG_CTRL_HEADER (컨트롤 헤더)
Size (상위 12비트) 0000 0100 1011(2)
= 0x04B
Level 00 0000 0001(2)
= 0x001
표 4를 참조하면, 서버는 Tag ID 가 컨트롤 헤더를 지시하므로, 데이터 영역을 컨트롤 헤더의 명세(Spec)를 근거로 판단할 수 있다.
표 5는 본 명세서가 적용될 수 있는 컨트롤 헤더 명세의 예시이다.
자료형 길이(바이트) 설명
UINT32 4 ctrl ID
UINT 4 속성(표 153 참조)
BYTE 1 기타 속성
WORD 2 command 길이(len)
WCHAR array[len] 2Хlen command(각 필드 종류마다 처리해야할 고유 정보)
UINT32 4 id(문서 내 고유 아이디)
전체 길이 가변 15 + (2Хlen)
표 6은 본 명세서가 적용될 수 있는 텍스트 하이퍼 링크의 제1 링크 정보 추출의 예시이다.
순서 동작
1 [ctrl ID]데이터 영역에서 ctrl ID 인 첫 4바이트(820)를 읽어 들이고, 역순으로 배치
6B 6C 68 25 = klh%
서버는 Tag ID가 컨트롤 헤더이고 ctrl ID가 %hlk 이기 때문에,
해당 레코드를 텍스트 하이퍼링크로 인식
2 [속성]데이터 영역에서 그 다음 4바이트(830)를 읽어 들임.
3 [기타 속성]데이터 영역에서 그 다음 1바이트(840)를 읽어 들임.
4 [command 길이]데이터 영역에서 그 다음 2바이트(850)를 읽어 들이고, 역순으로 배치
1C 00 => 00 1C
command 길이는 0x001C = 28(10)
5 [command]데이터 영역에서 그 다음 {command 길이 - 14}(= 56 - 14 = 42) 바이트를 읽어 들임. (6800 7400 7400 7000 5C00 3A00 2F00 2F00 7700 7700 7700 2E00 6E00 6100 7600 6500 7200 2E00 6300 6F00 6D00)
Command 길이가 28이고, 하나의 문자는 2바이트의 길이를 갖기 때문에, 실제 길이는 28*2 =56 바이트
한편, 56바이트 중 하위 14바이트는 문자열 정보가 아닌 옵션 값이기 때문에, 링크 주소의 문자열을 구하기 위해서는 56 - 14 = 42 바이트 만큼을 읽어 들임
이 42바이트에는 다음의 2가지 정보가 포함되어 있음.
- 웹주소에 대한 문자열 + “|” (구분자) + 설명할 문자열
실제 필요한 데이터는 웹주소에 대한 문자열이므로, 서버는 42바이트 중 “|” 문자가 나오기 전까지를 웹주소 문자열로 인식, 문자열에 “|” 문자가 없는 경우에, 서버는 42바이트 전체가 웹주소 문자열로 인식
따라서, 서버는 “http\://www.naver.com” 문자열을 제1 링크 정보로 추출
다시 도 4를 참조하면, 서버는 레코드가 개체 하이퍼 링크를 지시하는 것에 근거하여, 제2 링크 정보를 추출한다(S4030). 개체 하이퍼링크는 개체 레코드를 뒤따르는 HWPTAG_CTRL_DATA (컨트롤 임의의 데이터 레코드)의 형태로 생성될 수 있다. 예를 들어, 개체 하이퍼 링크는 HWPTAG_SHAPE_COMPONENT 레코드 + HWPTAG_CTRL_DATA 레코드 형태를 갖을 수 있으며, 제2 링크 정보는 HWPTAG_CTRL_DATA 레코드에 포함될 수 있다. 서버는 Section 스트림에서 개체 하이퍼 링크의 레코드 구조를 확인한 후, {컨트롤 임의의 데이터 레코드}를 무해할 수 있다.
도 9는 본 명세서가 적용될 수 있는 개체 하이퍼 링크를 지시하는 레코드의 예시이다.
도 9를 참조하면, 서버는 텍스트 하이퍼 링크를 지시하는 레코드의 헤더정보(910)를 분석할 수 있다.
표 7은 서버의 헤더정보 분석의 예시이다.
종류 값
헤더 0x570C 0005
바이트 단위로 역순배치 05 00 0C 57(16)
비트 단위로 배치 (Size)0000 0101 0000 (Level)0000 0000 11(Tag ID)00 0101 0111(2)
Tag ID (하위 10비트) 00 / 0101 /0111(2)
= 0 / 5 / 7(16) ( = 0x057)
= 0x010 + 0x47
= 0x010 + 71(10)
= HWPTAG_CTRL_DATA (컨트롤 임의의 데이터)
Size (상위 12비트) 0000 0101 0000(2)
= 0x050
Level 00 0000 0011(2)
= 0x003
서버는 HWP 명세에 근거하여, 컨트롤 임의의 데이터 레코드에서 데이터 영역을 판단할 수 있다.
4. 데이터 레코드
4.2. '문서 정보'의 데이터 레코드
4.2.12. 문서 임의의 데이터
파라미터 아이템의 개수만큼 아이템 데이터를 얻는다.
표 8은 본 명세서가 적용될 수 있는 HWP 명세의 파라미터 셋을 예시한다.
자료형 길이(바이트) 설명
WORD 2 파라미터 셋 ID
INT16 2 파라미터 셋에 존재하는 아이템 개수(n)
Parameter Item 가변Хn 파라미터 아이템(표 9 참조)
전체 길이 가변 4 + (가변Хn) 바이트
표 9는 본 명세서가 적용될 수 있는 HWP 명세의 파라미터 아이템을 예시한다.
자료형 길이(바이트) 설명
WORD 2 파라미터 아이템 ID
WORD 2 파라미터 아이템 종류(표 10 참조)
Parameter Item
Type		 가변 파라미터 아이템 데이터
전체 길이 가변 4 + 가변 바이트
표 10은 본 명세서가 적용될 수 있는 HWP 명세의 파라미터 아이템 종류를 예시한다.
값 구분 자료형 설명
0 PIT_NULL UINT NULL
1 PIT_BSTR WORD 문자열 길이(slen)
WCHAR array[len] 문자열
2 PIT_I1 UINT INT8
3 PIT_I2 UINT INT16
4 PIT_I4 UINT INT32
5 PIT_I UINT INT
6 PIT_UI1 UINT UINT8
7 PIT_UI2 UINT UINT16
8 PIT_UI4 UINT UINT32
9 PIT_UI UINT UINT
0x8000 PIT_SET Parameter Set 파라미터 셋
0x8001 PIT_ARRAY INT16 파라미터 셋 개수
ParameterArray 파라미터 셋 배열
0x8002 PIT_BINDATA UINT16 바이너리 데이터 ID
서버는 표 8 내지 표 10을 참조하여, 데이터 영역을 파싱할 수 있다.
표 11은 본 명세서가 적용될 수 있는 개체 하이퍼 링크의 제2 링크 정보 추출의 예시이다.
순서 동작
1 [파라미터 셋 ID]데이터 영역에서 파라미터 셋 ID 인 첫 2바이트(920)를 읽어 들임.
- 1B 02 => 02 1B
2 [파라미터 셋에 존재하는 아이템 개수]데이터 영역에서 그 다음 4바이트(930)를 읽어 들이고, 역순으로 배치
- 0100 0000(2) => 0000 0001(2) = 1(10)
- 파라미터 셋에 존재하는 아이템 개수는 1개
3 [파라미터 아이템 - 파라미터 아이템 ID]데이터 영역에서 그 다음 2바이트(940)를 읽어 들임
- 6F 02 => 02 6F
4 [파라미터 아이템 - 파라미터 아이템 종류]데이터 영역에서 그 다음 2바이트(950)를 읽어 들이고, 역순으로 배치
- 00 80 => 80 00
- 0x8000 이므로, 서버는 이후의 데이터를 파라미터 셋으로 해석
5 [파라미터 셋 ID]데이터 영역에서 그 다음 2바이트(960)를 읽어 들임.
- 6F 02 => 02 6F
6 [파라미터 셋에 존재하는 아이템 개수]데이터 영역에서 그 다음 4바이트(0100 0000)를 읽어 들이고, 역순으로 배치
- 0100 0000(2) => 0000 0001(2) = 1(10)
- 서버는 파라미터 셋에 존재하는 아이템 개수를 1개로 판단
7 [파라미터 아이템 - 파라미터 아이템 ID]데이터 영역에서 그 다음 2바이트(6502)를 읽어 들임
- 65 02 => 02 65
8 [파라미터 아이템 - 파라미터 아이템 종류]데이터 영역에서 그 다음 2바이트(0100)를 읽어 들이고, 역순으로 배치
- 01 00 => 00 01
- 서버는 1 = PIT_BSTR(표 10 참조) 이므로, 이후의 데이터를 “문자열 길이(2바이트) + 문자열”로 해석
9 [문자열 길이]데이터 영역에서 그 다음 2바이트(1D00)를 읽어 들이고, 역순으로 배치
- 1D 00 => 00 1D
- 문자열 길이는 0x1D = 29(10)
10 [문자열]서버는 데이터 영역에서 그 다음 {문자열 길이 - 14}(= 58 - 14 = 44) 바이트(6800 ~ 6D00)를 읽어 들임
- Command 길이가 29이고, 하나의 문자는 2바이트의 길이를 갖기 때문에, 실제 길이는 29*2 =58 바이트
- 한편, 58바이트 중 하위 14바이트는 문자열 정보가 아닌 옵션 값이기 때문에, 링크 주소의 문자열을 구하기 위해서는 58 - 14 = 44 바이트 만큼을 읽어 들임
이 44바이트에는 다음의 2가지 정보가 포함되어 있음
- 웹주소에 대한 문자열 + “|” (구분자) + 설명할 문자열
실제 필요한 데이터는 웹주소에 대한 문자열이므로, 서버는 42바이트 중 “|” 문자가 나오기 전까지를 웹주소 문자열로 인식
- “|” 문자가 없기 때문에 서버는 44바이트 전체가 웹주소 문자열로 인식
서버는 제2 링크 정보로서 “http\://www.google.com” 문자열을 추출
다시 도 4를 참조하면, 서버는 레코드가 자료 연결을 지시하는 것에 근거하여, 제3 링크 정보를 추출한다(S4040). 예를 들어, 자료 연결은 텍스트 하이퍼 링크와 동일하게 컨트롤 헤더 태그이며, ctrl ID은 %unk (unknown field) 값을 갖을 수 있다. 보다 자세하게, 자료 연결을 지시하는 레코드의 헤더 정보에서 Tag ID 는 HWPTAG_CTRL_HEADER (컨트롤 헤더)이며, 데이터 영역은 0x6B 6E 75 25 (knu%)로 시작할 수 있다.
도 10은 본 명세서가 적용될 수 있는 자료 연결을 지시하는 레코드의 예시이다.
도 10을 참조하면, 서버는 텍스트 하이퍼 링크를 지시하는 레코드의 헤더정보(1010)를 분석할 수 있다.
표 12는 서버의 헤더정보 분석의 예시이다.
종류 값
헤더 0x4704 7006
바이트 단위로 역순배치 06 70 04 47(16)
비트 단위로 배치 (Size)0000 0110 0111 (Level)0000 0000 01(Tag ID)00 0100 0111(2)
Tag ID (하위 10비트) 00 0100 0111(2)
= 0x047
= 0x010 + 0x37
= 0x010 + 55(10)
= 컨트롤 헤더
Size (상위 12비트) 0000 0110 0111(2)
= 0x067
Level 00 0000 0001(2)
= 0x001
표 12를 참조하면, 서버는 Tag ID(0x047)가 컨트롤 헤더이므로, 표 5의 명세에 근거하여, 레코드를 해석할 수 있다.
표 13은 본 명세서가 적용될 수 있는 자료 연결의 제3 링크 정보 추출의 예시이다.
순서 동작
1 [ctrl ID]데이터 영역에서 ctrl ID 인 첫 4바이트(1020)를 읽어 들임
- 6B 6E 75 25 = knu%
- 역순으로 배치하면 %unk
서버는 Tag ID가 컨트롤 헤더이고 ctrl ID가 %unk 이므로, 해당 레코드를 자료 연결을 지시하는 것으로 판단
2 [속성]데이터 영역에서 그 다음 4바이트(1030)를 읽어 들임
3 [기타 속성]데이터 영역에서 그 다음 1바이트(1040)를 읽어 들임
4 [command 길이]데이터 영역에서 그 다음 2바이트(1050)를 읽어 들이고, 역순으로 배치
- 2A 00 => 00 2A
command 길이는 0x002A = 42(10)
5 서버는 우선 데이터 영역에서 그 다음 {문자열 길이 - 14}(= 84 - 14 = 70) 바이트(6800~6500)를 읽어 들임- Command 길이가 42이고, 하나의 문자는 2바이트의 길이를 갖기 때문에, 실제 길이는 42*2 =84 바이트. 다만, 84바이트 중 하위 14바이트는 문자열 정보가 아닌 옵션 값이기 때문에, 서버는 링크 주소의 문자열을 구하기 위해서 84 - 14 = 70 바이트 만큼을 읽어 들임
이 70바이트에는 다음의 2가지 정보가 포함되어 있음
- 웹주소에 대한 문자열 + “|” (구분자) + 표시할 문자열
실제 필요한 데이터는 웹주소에 대한 문자열이므로, 서버는 70바이트 중 “|” 문자가 나오기 전까지를 웹주소 문자열로 인식.
서버는 제3 링크 정보로서, “http\://www.google.com” 문자열을 추출
다시 도 4를 참조하면, 서버는 추출된 링크 정보를 무해화한다(S4050).예를 들어, 서버는 링크 정보(예를 들어, 제1/제2/제3 링크정보)에서 스키마(schema) 정보만 남기고, 나머지는 빈칸(2000)으로 대체할 수 있다. 이를 통해, 링크 정보의 전체 길이는 그대로 유지될 수 있으며, 최소한의 수정으로 링크 정보는 무해화 될 수 있다.
도 11은 본 명세서가 적용될 수 있는 PDF 파일의 무해화 방법을 예시한다.
도 11을 참조하면, 서버가 비실행 파일의 포맷을 PDF 파일로 판단한 경우, PDF 파일의 무해화 방법을 예시한다.
서버는 PDF 파일의 기본 요소(element)들을 기준으로 순회하여 자료형(dictionary type)을 탐색한다(S1110). 예를 들어, 서버는 PDF 파일의 기본 요소로서 obj를 기준으로 순회할 수 있다. obj에 설정된 값에 따라, 당해 요소의 실제 역할과 기능이 정의될 수 있다.
만일, 각 페이지를 기준으로 순회하여 페이지 내부의 요소를 확인하는 일반적인 방법의 경우, 실제 문서에서는 Action obj가 자기 자신을 순환 참조하는 등, 많은 예외가 존재할 수 있으므로, 예외 처리가 누락될 위험이 있다.
예를 들어, PDF는 indirect obj를 참조하는 일이 빈번하기 때문에, obj 기준으로 순회하는 것이 시간복잡도 측면에서도 안정적이다.
또한, 하나의 obj를 여러 페이지에서 각각 참조할 수 있기 때문에, 중복 탐색의 문제도 고려해야 한다. obj를 기준으로 순회하는 방식은 일정한 문서의 모든 obj를 순회할 수 있으므로, 한 번의 순회로 모든 obj에 대한 탐색을 보장할 수 있다.
이러한 obj는 dictionary type을 갖을 수 있다. 예를 들어, dictionary type은 8가지 기본 데이터 형식(Boolean values, Integer and Real numbers, Strings, Names, Arrays, Dictionaries, Streams, and the null object) 중 하나로서, {key}-{value} 한 쌍의 대응관계를 갖는 하나의 엔트리로 포함할 수 있다.
서버는 탐색된 자료형에 URI(Uniform Resource Identifier) entry가 포함되어 있는 지 검사한다(S1120).
예를 들어, 자료형은 URI 액션 개체를 포함할 수 있다. URI Action은 Dictionary 타입이며, 필수요소로 S와 URI를 포함한다(예를 들어, <</S URI /URI (https://www.seculetter.com)>>). 서버는 S와 URI 키(key)가 포함되어 있는 지를 기준으로 URI entry를 검사할 수 있다.
표 14는 본 명세서가 적용될 수 있는 S와 URI 키의 예시이다.
Key Type Value
S name (Required)
The type of action that this dictionary describes; shall be URI for a URI action.
URI ASCII string (Required) The uniform resource identifier to resolve, encoded in 7-bit ASCII.
서버는 URI entry가 포함되어 있는 것에 근거하여, URI entry를 무해화 한다(S1130).예를 들어, 서버는 URI 키의 ASCII string값에서 Link의 스키마 정보만 남길 수 있다.
표 15는 본 명세서가 적용될 수 있는 URI 엔트리 무해화의 예시이다.
무해화 이전 무해화 이후
<<
/S URI
/URI ( https://www.seculetter.com)
/Next 10 0 R
>>		 <<
/S URI
/URI (https://)
/Next 10 0 R
>>
만일, 필수요소가 제거되거나, URI Action 자체를 제거하는 경우, URI Action과 연결된 Next Action 동작이 수행되지 않는 문제가 발생할 수 있다. 따라서. 서버는 실제로 문제가 되는 부분만을 최소한으로 수정하여 무해화를 수행한다.서버는 다른 기본 요소들에 대해서도 반복적으로 URI entry 무해화를 수행할 수 있다. 전술한 본 명세서는, 프로그램이 기록된 매체에 컴퓨터가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 컴퓨터가 읽을 수 있는 매체는, 컴퓨터 시스템에 의하여 읽혀 질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 컴퓨터가 읽을 수 있는 매체의 예로는, HDD(Hard Disk Drive), SSD(Solid State Disk), SDD(Silicon Disk Drive), ROM, RAM, CD-ROM, 자기 테이프, 플로피 디스크, 광 데이터 저장 장치 등이 있으며, 또한 캐리어 웨이브(예를 들어, 인터넷을 통한 전송)의 형태로 구현되는 것도 포함한다. 따라서, 상기의 상세한 설명은 모든 면에서 제한적으로 해석되어서는 아니되고 예시적인 것으로 고려되어야 한다. 본 명세서의 범위는 첨부된 청구항의 합리적 해석에 의해 결정되어야 하고, 본 명세서의 등가적 범위 내에서의 모든 변경은 본 명세서의 범위에 포함된다.
또한, 이상에서 서비스 및 실시 예들을 중심으로 설명하였으나 이는 단지 예시일 뿐 본 명세서를 한정하는 것이 아니며, 본 명세서가 속하는 분야의 통상의 지식을 가진 자라면 본 서비스 및 실시 예의 본질적인 특성을 벗어나지 않는 범위에서 이상에 예시되지 않은 여러 가지의 변형과 응용이 가능함을 알 수 있을 것이다. 예를 들어, 실시 예들에 구체적으로 나타난 각 구성 요소는 변형하여 실시할 수 있는 것이다. 그리고 이러한 변형과 응용에 관계된 차이점들은 첨부한 청구 범위에서 규정하는 본 명세서의 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (3)

  1. 서버가 비실행 파일을 무해화(Disarming) 시키는 방법에 있어서,
    상기 비실행 파일의 포맷이 HWP 파일인 것에 근거하여:
    상기 HWP 파일로부터 레코드(record)를 수집하는 단계;
    상기 레코드가 텍스트에 설정된 하이퍼 링크를 지시하는 것에 근거하여, 제1 링크 정보를 추출하는 단계;
    상기 레코드가 개체에 설정된 하이퍼 링크를 지시하는 것에 근거하여, 제2 링크 정보를 추출하는 단계;
    추출된 링크 정보에서 스키마(schema) 정보 외에 나머지는 빈칸으로 대체하는 단계;로서, 상기 추출된 링크 정보는 상기 제1 링크 정보, 또는 상기 제2 링크 정보를 포함함;
    상기 비실행 파일의 포맷이 PDF 파일인 것에 근거하여:
    상기 PDF 파일의 기본 요소(obj)들을 기준으로 순회하여, 자료형(dictionary type)을 탐색하는 단계;로서, 상기 자료형은 URI 액션(action) 개체를 포함함;상기 자료형에 "S" 키, 및 "URI" 키가 포함되어 있는 것에 근거하여, 상기 자료형에 URI entry가 포함되어 있는 지를 검사하는 단계;
    상기 URI entry가 포함되어 있는 것에 근거하여, 상기 "URI" 키의 ASCII string 값에서 Link의 스키마 정보를 획득하는 단계; 및
    상기 ASCII string 값에서 상기 Link의 스키마 정보를 제외한 나머지 문자열을 삭제하는 단계;
    를 포함하는, 무해화 방법.
  2. 삭제
  3. 비실행 파일을 무해화(Disarming) 시키는 서버에 있어서,
    통신부;
    메모리; 및
    상기 통신부 및 상기 메모리를 기능적으로 제어하는 프로세서;를 포함하고,
    상기 프로세서는
    상기 비실행 파일의 포맷이 HWP 파일인 것에 근거하여: 상기 HWP 파일로부터 레코드(record)를 수집하고, 상기 레코드가 텍스트에 설정된 하이퍼 링크를 지시하는 것에 근거하여, 제1 링크 정보를 추출하며, 상기 레코드가 개체에 설정된 하이퍼 링크를 지시하는 것에 근거하여, 제2 링크 정보를 추출하고, 추출된 링크 정보에서 스키마(schema) 정보 외에 나머지는 빈칸으로 대체하며, 상기 추출된 링크 정보는 상기 제1 링크 정보, 또는 상기 제2 링크 정보를 포함하고,
    상기 비실행 파일의 포맷이 PDF 파일인 것에 근거하여: 상기 PDF 파일의 기본 요소(obj)들을 기준으로 순회하여, 자료형(dictionary type)을 탐색하고, 상기 자료형은 URI 액션(action) 개체를 포함함;상기 자료형에 "S" 키, 및 "URI" 키가 포함되어 있는 것에 근거하여, 상기 자료형에 URI entry가 포함되어 있는 지를 검사하며, 상기 URI entry가 포함되어 있는 것에 근거하여, 상기 "URI" 키의 ASCII string 값에서 Link의 스키마 정보를 획득하고, 상기 ASCII string 값에서 상기 Link의 스키마 정보를 제외한 나머지 문자열을 삭제하는, 서버.

KR1020237004697A 2022-09-23 2022-09-23 PDF에서 Link의 무해화를 위한 방법 및 장치 KR102583399B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
PCT/KR2022/014298 WO2024063184A1 (ko) 2022-09-23 2022-09-23 Pdf 또는 hwp에서 link의 무해화를 위한 방법 및 장치
KR1020227033330A KR102499555B1 (ko) 2022-09-23 2022-09-23 PDF 또는 HWP에서 Link의 무해화를 위한 방법 및 장치

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020227033330A Division KR102499555B1 (ko) 2022-09-23 2022-09-23 PDF 또는 HWP에서 Link의 무해화를 위한 방법 및 장치

Publications (1)

Publication Number Publication Date
KR102583399B1 true KR102583399B1 (ko) 2023-09-27

Family

ID=85330646

Family Applications (3)

Application Number Title Priority Date Filing Date
KR1020237004696A KR102547757B1 (ko) 2022-09-23 2022-09-23 HWP에서 Link의 무해화를 위한 방법 및 장치
KR1020237004697A KR102583399B1 (ko) 2022-09-23 2022-09-23 PDF에서 Link의 무해화를 위한 방법 및 장치
KR1020227033330A KR102499555B1 (ko) 2022-09-23 2022-09-23 PDF 또는 HWP에서 Link의 무해화를 위한 방법 및 장치

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020237004696A KR102547757B1 (ko) 2022-09-23 2022-09-23 HWP에서 Link의 무해화를 위한 방법 및 장치

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020227033330A KR102499555B1 (ko) 2022-09-23 2022-09-23 PDF 또는 HWP에서 Link의 무해화를 위한 방법 및 장치

Country Status (2)

Country Link
KR (3) KR102547757B1 (ko)
WO (1) WO2024063184A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102547757B1 (ko) * 2022-09-23 2023-06-26 시큐레터 주식회사 HWP에서 Link의 무해화를 위한 방법 및 장치

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101860546B1 (ko) * 2017-04-28 2018-05-23 (주)지란지교시큐리티 파일 내 포함된 콘텐츠 무력화 장치 및 방법, 그 기록매체

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023551858A (ja) * 2020-12-29 2023-12-13 株式会社ギウォンテク メールセキュリティー基盤のゼロデイｕｒｌ攻撃防御サービス提供装置及びその動作方法
KR102547757B1 (ko) * 2022-09-23 2023-06-26 시큐레터 주식회사 HWP에서 Link의 무해화를 위한 방법 및 장치

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101860546B1 (ko) * 2017-04-28 2018-05-23 (주)지란지교시큐리티 파일 내 포함된 콘텐츠 무력화 장치 및 방법, 그 기록매체

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
Mike Mclain, "Using Python to Remove PDF Hyperlinks"(2021.12.)* *
Ron Brandis and Luke Steller, "Threat Modelling Adobe PDF", Defence Science and Technology Organisation(2012.08.)* *
세인트시큐리티, "APT : 악성 한글 파일을 통해 확산되는 악성코드"(2016.01.) *

Also Published As

Publication number Publication date
KR102499555B1 (ko) 2023-02-16
KR102547757B1 (ko) 2023-06-26
WO2024063184A1 (ko) 2024-03-28

Similar Documents

Publication Publication Date Title
Garfinkel Digital media triage with bulk data analysis and bulk_extractor
Halfond et al. Preventing SQL injection attacks using AMNESIA
Laskov et al. Static detection of malicious JavaScript-bearing PDF documents
US20190311113A1 (en) Methods, media, and systems for detecting attack on a digital processing device
van den Burg et al. Wrangling messy CSV files by detecting row and type patterns
US20020073330A1 (en) Detection of polymorphic script language viruses by data driven lexical analysis
Walls et al. Forensic Triage for Mobile Phones with {DEC0DE}
US11373065B2 (en) Dictionary based deduplication of training set samples for machine learning based computer threat analysis
US11687534B2 (en) Method and system for detecting sensitive data
US20080027866A1 (en) System and method for authenticating file content
Brengel et al. {YARIX}: Scalable {YARA-based} malware intelligence
CN103279707A (zh) 一种用于主动防御恶意程序的方法、设备及系统
KR102583399B1 (ko) PDF에서 Link의 무해화를 위한 방법 및 장치
WO2020014663A1 (en) Systems and methods for detecting obfuscated malware in obfuscated just-in-time (jit) compiled code
CN103716394A (zh) 下载文件的管理方法及装置
KR102468431B1 (ko) Ms-ooxml에서 ole object 무해화를 위한 방법 및 장치
KR101244945B1 (ko) 메타 패턴을 이용한 웹쉘 탐지 장치
Falah et al. Towards enhanced PDF maldocs detection with feature engineering: design challenges
KR102468428B1 (ko) PDF 또는 HWP에서 JavaScript의 무해화를 위한 방법 및 장치
KR102494838B1 (ko) MS-CFB의 DocumentSummaryInformation 스트림에서 Link의 무해화를 위한 방법 및 장치
KR102494836B1 (ko) MS-DOC에서 Link의 무해화를 위한 방법 및 장치
KR102538664B1 (ko) Excel 계열의 문서에서 수식 기능에 있는 Link의 무해화를 위한 방법 및 장치
KR102488943B1 (ko) MS-PPT에서 Link의 무해화를 위한 방법 및 장치
KR102468434B1 (ko) Ms excel 문서 포맷에서 dde 무해화를 위한 방법 및 장치
Anantharaman et al. A format-aware reducer for scriptable rewriting of PDF files

Legal Events

Date Code Title Description
AMND Amendment
X091 Application refused [patent]
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant