1.2 XML 조회 및 결과 검증

XML 조회시 질의문(XPath, XQuery 등) 내 입력값과 그 조회결과에 대한 유효성 검증방법 (필터링 등)과 유효하지 않은 값에 대한 처리방법을 설계해야 한다.

 

[취약점]

1. XML 삽입 공격

2. 부적절한 XML 외부개체 참조(XXE, XML External Entity)

 

[보안대책]

1. 필터링해서 사용 또는 자료형에 따라 바인딩해서 사용
* XML삽입을 발생시킬 수 있는 문자열(", [ , ] , / , = , @ 등)을 제거 또는 안전하게 치환

 

(ㄱ) 공통 검증 컴포넌트를 이용한 입력값 필터링

쉽게 이해하기: "입력값 검사를 전담하는 **'전문 검증 팀(Validator)'**을 하나 만들어 두고, XML을 쓰는 모든 화면(애플리케이션)이 데이터 처리를 하기 전에 반드시 이 팀을 거쳐 가도록 통일하는 설계"입니다.

• 핵심 단어: Validator 컴포넌트, 일괄 적용
• 설명: 개발자 A, B, C가 각자 검증 코드를 짜면 구멍이 생길 수 있으니, 회사 차원에서 공인된 검증 도구(Validator)를 딱 하나 개발해 두고 "앞으로 XML 조회 기능 만들 때는 무조건 이 도구로 검사 맡아!" 하고 강제하는 스마트한 설계 방식입니다.

(ㄴ) 필터 컴포넌트를 이용한 입력값 필터링

쉽게 이해하기: "사용자의 요청이 웹 서버 문을 열고 **들어오는 최외곽 길목(Filter)**에 바리케이드를 쳐서, XML 공격용 특수문자들을 일괄적으로 걸러내는 설계"입니다.

• 핵심 단어: Filter컴포넌트, 전체 요청 또는 요구되는 요청, 일괄 적용
• 설명: 개별 코드나 비즈니스 로직에 닿기도 전에, 웹 시스템의 가장 앞단(Filter)에서 [, ], /, = 같은 위험한 글자가 들어있는지 먼저 스캔하는 것입니다. 프레임워크 설정을 통해 모든 요청에 자동으로 적용되므로 개발자가 깜빡하고 검증을 누락하는 실수를 원천 차단할 수 있습니다.

(ㄷ) 개별 코드에서 입력값 필터링하도록 시큐어코딩 규칙 정의

쉽게 이해하기: "앞단에서 놓쳤을 때를 대비해, 개발자가 직접 코딩하는 소스코드 칸칸마다 위험한 문자를 지우거나 바꾸는 규칙(가이드라인)을 정해두는 것"입니다.

• 핵심 단어: 각각의 컴포넌트(개별 코드), 제거 또는 안전하게 치환, 규칙 정의
• 설명: 이것은 시스템이 자동으로 해주는 게 아니라, 진단원이나 보안팀이 개발자 가이드에 "코딩할 때 입력값에 특수문자 있으면 반드시 replace() 함수 같은 걸 써서 안전하게 치환해서 쓰세요"라고 규칙을 정해두는 설계 방침입니다. (예: [ 가 들어오면 지워버리거나 안전한 문자로 바꾸기)

(ㄹ) 안전한 API를 사용하도록 시큐어코딩 규칙 정의

쉽게 이해하기: "문자열을 필터링하는 걸 넘어서, SQL 인젝션을 막을 때 PreparedStatement를 썼던 것처럼 XML 전용의 안전한 쿼리 도구(XQuery 파라미터화 등)를 쓰도록 규칙을 정하는 것"입니다.

• 핵심 단어: 구조를 바꿀 수 없는 API, XQuery, 규칙 정의
• 설명: (ㄱ), (ㄴ), (ㄷ)은 모두 나쁜 글자를 '지우거나 막는' 방식(필터링)인 반면, (ㄹ)은 구조적으로 방어하는 방식입니다. XML 데이터를 조회할 때 쓰는 언어인 XQuery 등에서 외부 입력값을 명령어(태그 등)가 아닌 단순 '데이터'로만 강제 취급하는 안전한 API 함수를 쓰도록 가이드라인을 만드는 것입니다.
  • (ㄱ), (ㄴ), (ㄷ) ➔ 필터링/치환 중심 방어 (나쁜 글자를 거르자!
  • (ㄹ) ➔ 구조적/안전한 API 중심 방어 (글자를 거르는 게 아니라, 시스템 자체를 안전한 도구로 쓰자!)