취약점 헤드라인을 읽다 보면 XML 인젝션이 주목을 받는 경우는 거의 없습니다. RCE나 SQLi와 같은 강렬한 이름도 없고, 화려한 원격 익스플로잇처럼 시각적으로 극적이지도 않습니다. 하지만 SOAP 엔드포인트, 레거시 XML API, 문서 처리 파이프라인, SAML/SOAP 통합 등 많은 엔터프라이즈 스택에서 XML 인젝션은 신뢰할 수 있는 입력을 로직 실수로 바꾸는 조용한 장애 모드입니다.
본질적으로 XML 인젝션은 하나의 익스플로잇이 아닙니다. 공격자가 제어하는 XML이 서버가 요청을 해석하는 방식을 변경하는 일련의 동작입니다. 즉, XPath 쿼리가 갑자기 예기치 않은 레코드를 반환하거나, 파서가 의도하지 않은 외부 리소스를 확인하거나, 엔티티 확장이 CPU와 메모리를 소모할 수 있습니다. 공격자 입장에서는 파일을 읽거나, 내부 요청을 트리거하거나, 유용한 혼란을 야기하는 등 실용적인 구성 요소입니다. 방어자의 관점에서는 이러한 요소들이 로직과 가시성 격차를 해결하기 위한 네비게이션 맵에 해당합니다.
작고 구체적인 취향 - 누구에게도 플레이북을 제공하지 않고도
화려한 페이로드가 없어도 패턴을 확인할 수 있습니다. 네이티브 문자열 연결을 통해 요청 필드에서 XPath를 구축하는 서버 측 코드를 상상해 보세요:
// 취약한 패턴(의사)
userId = 요청.xml.user.id
role = request.xml.user.role
query = "doc('/db/users.xml')/users/user[id = " + userId + " and role = '" + role + "']"
결과 = xmlEngine.평가(쿼리)
다음과 같은 경우 무해해 보입니다. userId 그리고 역할 는 잘 형성되어 있습니다. 하지만 사용자 입력이 쿼리 구조를 제어하도록 하면 데이터 그리고 논리. 취약한 쿼리를 조작하여 진리 조건을 변경하고 반환하지 않아야 할 행을 반환할 수 있기 때문입니다.
또 다른 축은 엔티티 또는 DTD 처리입니다. 많은 XML 엔진이 문서 유형 선언, 엔티티 및 외부 참조를 허용하는데, 이는 합법적인 구성에는 유용하지만 신뢰할 수 없는 입력에 대해 켜두면 위험합니다. 방어 규칙은 간단합니다. 엔티티 확장이나 DOCTYPE 처리가 필요하지 않은 경우 이를 끄면 됩니다.
구성 구문 분석이 비전 익스플로잇보다 더 중요한 이유
이 문제에는 두 가지 수준이 있습니다. 첫 번째는 비즈니스 로직 버그입니다. 신뢰할 수 없는 값을 쿼리 로직에 전달하고, XML을 XPath 또는 XPath와 유사한 평가기로 템플릿화하며, "잘 형식화된"이 "안전한"을 의미한다고 가정하는 것입니다. 이는 유효성 검사, 정규화, 쿼리에서 데이터 분리 등 설계를 통해 수정할 수 있습니다.
두 번째는 파서 동작입니다. XML 파서는 파일 콘텐츠를 가져오거나 HTTP 요청을 하거나 중첩된 엔티티를 확장하여 메모리를 늘릴 수 있는 강력한 기능을 제공합니다. 이러한 기능은 통제된 컨텍스트에서는 괜찮지만 공개 입력이 허용되면 재앙이 됩니다. 따라서 실질적인 방어책은 파서 강화와 행동 원격 측정입니다.
실용적이고 엔지니어 친화적인 대응책(예시 포함)
안전을 위해 XML을 금지할 필요는 없습니다. 하지만 세 가지 습관적인 변화가 필요합니다:
1) 파서 기능을 제한합니다. 대부분의 언어에서 외부 엔티티 및 DOCTYPE 처리를 비활성화할 수 있습니다. 예를 들어 Java(의사 API)의 경우입니다:
도큐먼트 빌더 팩토리 dbf = 도큐먼트 빌더 팩토리.새로운 인스턴스();
dbf.setFeature("", true);
dbf.setFeature("", false);
dbf.setFeature("", false);
또는 Python에서 defusedxml (기본값이 안전 동작으로 설정된 라이브러리 사용):
defusedxml.ElementTree에서 fromstring 가져오기
tree = fromstring(untrusted_xml)
2) 유효성 검사 및 정식화. 엔드포인트에 작은 태그 집합만 필요한 경우, XSD에 대해 유효성을 검사하거나 예기치 않은 DOCTYPE을 거부하세요. 문자열 연결로 쿼리를 작성하는 것보다 데이터 구조로 파싱하고 매개변수화된 액세스를 사용하는 것을 선호하세요.
3) 계기 및 알림. 이상한 신호를 감시하는 후크를 추가하세요. DOCTYPE/ENTITY를 참조하는 파서 예외, 파싱 서비스에서 갑작스러운 아웃바운드 DNS/HTTP, 파싱 중에 시작된 파일 열기 작업 등 이상한 신호가 있는지 확인합니다. 이러한 신호는 정적 규칙 목록보다 훨씬 더 실행 가능한 신호입니다.
실제로 방어자에게 도움이 되는 감지 가능한 신호
모니터링을 조정할 때는 취약한 텍스트 시그니처가 아닌 실제 행동을 찾아보세요:
- 구문 분석기 프로세스에서 발생하는 아웃바운드 DNS 또는 HTTP 호출.
- XML 처리 중에 발생하는 로컬 경로에 대한 파일 액세스 시도.
- 파서 예외 트레이스에서 DOCTYPE 또는 외부 엔티티 해상도를 언급합니다.
- 내부 전용 필드 또는 데이터가 갑자기 포함된 응답(XPath 또는 쿼리 조작을 나타냄).
- 정상 부하에서 코드 구문 분석 시 비정상적인 CPU/메모리 급증.
이러한 것들을 신속하게 경고하고 분류할 수 있습니다.
무모하지 않게 연습하는 방법
탐지 규칙을 확인하거나, 파서 강화가 작동하는지 확인하거나, CTF 스타일의 챌린지에 대한 훈련을 하는 등 실험을 하고 싶다면 통제된 실험실에서만 하세요. 프로덕션 환경에서 잘못된 XML을 푸시하지 마세요. 대신 격리된 VM, 입증 가능한 랩 범위 또는 다음을 생성하는 툴을 사용하세요. 위생적이고 착취적이지 않은 테스트 케이스.
자연어 워크플로 - 펜리전트 인 더 루프
바로 이 부분에서 실용적인 자동화가 빛을 발합니다. 구문 분석기 설정이나 탐지 로직의 유효성을 검사하기 위해 수십 개의 테스트를 직접 코딩할 필요가 없어야 합니다. 다음과 같은 자연어 기반 펜테스트 도구를 사용하면 펜리전트의 흐름을 일상 언어로 표현하면 다음과 같습니다:
"스테이징 SOAP 엔드포인트에 XML 인젝션 위험이 있는지 확인하세요. 안전한 프로브만 사용하고, 파서 예외, 파일 액세스 이벤트, 모든 아웃바운드 DNS/HTTP 콜백을 수집하세요. 우선순위가 지정된 강화 단계를 생성하세요."
Penligent는 이 문장을 승인된 테스트 환경에 대한 표적화된 위생 검사로 전환합니다. 라이브 익스플로잇 체인이 아닌 집중 테스트 사례를 실행하고, 원격 분석(파서 오류, 파일 액세스 로그, DNS 콜백)을 수집하고, 증거를 상호 연관시키고, 간결한 해결 체크리스트를 반환합니다. 셸 스크립트를 작성하거나 수십 개의 페이로드 파일을 만들지 않고도 가설을 검증하고 탐지가 실행되었는지 여부를 파악한 다음 반복할 수 있기 때문에 CTF의 장점은 속도입니다.
마무리 생각
XML 인젝션은 취약점 순위표에서는 눈에 띄지 않는 것처럼 보이지만, 그 진짜 위력은 은밀합니다. 데이터 계층이 무해하고, 파서가 '예상대로' 작동하며, 모니터링이 명백한 오류를 포착할 것이라는 가정을 악용합니다. 이 문제를 해결하려면 구문 분석기 권한을 최소화하고, 데이터와 로직을 분리하고, 적극적으로 유효성을 검사하고, 중요한 신호를 계측하는 등 설계 위생을 강화하는 것이 중요합니다. 자연어 의도를 안전한 검증 실행으로 변환하는 도구는 번거로운 작업을 없애고 팀이 수정과 학습에 집중할 수 있게 해주며, 이것이 바로 최신 방어 자동화의 핵심입니다.
