XXE چیست؟ بررسی آسیب‌پذیری XML External Entity و روش‌های جلوگیری

XXE یا XML External Entity نوعی آسیب‌پذیری امنیتی در پردازش XML است که زمانی ایجاد می‌شود که یک XML Parser، داده XML غیرقابل اعتماد را با تنظیمات ناامن پردازش کند و اجازه Resolve شدن Entityهای خارجی را بدهد. در چنین شرایطی Parser ممکن است به منابعی خارج از سند XML دسترسی پیدا کند و این رفتار بسته به محیط می‌تواند زمینه افشای فایل‌های محلی، Server-Side Request Forgery یا SSRF، دسترسی ناخواسته به سرویس‌های داخلی و حتی Denial of Service را فراهم کند. OWASP مهم‌ترین راهکار عمومی برای جلوگیری از XXE را غیرفعال کردن DTD و External Entityها در جایی می‌داند که Application واقعاً به آن‌ها نیاز ندارد.

به زبان ساده، مشکل از خود XML شروع نمی‌شود. XML یک Format استاندارد و کاربردی برای ساختاردهی Data است و همچنان در SOAP، SAML، فایل‌های Configuration، Integrationهای قدیمی، Import/Export، Feedها و بسیاری از سیستم‌های Enterprise استفاده می‌شود.

مشکل زمانی شکل می‌گیرد که Application به Parser اجازه دهد XML دریافت‌شده از User یا یک منبع غیرقابل اعتماد، درباره منابع خارجی تصمیم بگیرد.

برای مثال اگر Parser اجازه داشته باشد External Entity را Resolve کند، XML ممکن است به Resource دیگری اشاره کند. اگر Application این Reference را بدون محدودیت دنبال کند، Parser عملاً به واسطه‌ای میان ورودی مهاجم و File System یا Network تبدیل می‌شود.

به همین دلیل XXE صرفاً یک «اشکال XML» نیست؛ یک مشکل Trust Boundary و Parser Configuration است.

در این مقاله رخنه‌کاو بررسی می‌کنیم XXE چیست، Entity و DTD چه مفهومی دارند، حمله XML External Entity چگونه شکل می‌گیرد، چه تفاوتی با XML Injection دارد، چه پیامدهایی مانند File Disclosure، SSRF و DoS ایجاد می‌کند و مهم‌تر از همه چگونه می‌توان XML Parserهای Java، .NET، PHP و سایر محیط‌ها را به شکل امن پیکربندی کرد.

XXE چیست؟

XXE مخفف XML External Entity است.

از دید CWE، این ضعف با شناسه CWE-611 و عنوان Improper Restriction of XML External Entity Reference شناخته می‌شود.

MITRE این ضعف را زمانی تعریف می‌کند که یک Product سند XML دارای Entity Reference خارجی را پردازش کند و Entity بتواند به Resourceهایی خارج از محدوده مورد انتظار Application اشاره کند. نتیجه می‌تواند وارد شدن محتوای خارجی به Process و در بعضی سناریوها افشای Data یا دسترسی شبکه‌ای ناخواسته باشد.

برای ایجاد XXE معمولاً چند عامل کنار هم قرار می‌گیرند:

Application داده XML دریافت می‌کند.

داده از Source غیرقابل اعتماد یا قابل Manipulation می‌آید.

Parser از DTD یا External Entity پشتیبانی می‌کند.

Resolve کردن External Resource فعال است.

Security Restriction مناسبی وجود ندارد.

بنابراین صرف استفاده از XML به معنی آسیب‌پذیری XXE نیست.

یک Application می‌تواند هزاران XML Document در روز پردازش کند و در صورت استفاده از Parser امن و Configuration درست، در برابر XXE مقاوم باشد.

جایگاه XXE در OWASP Top 10 2025

XXE در OWASP Top 10 سال ۲۰۱۷ یک Category مستقل بود.

در نسخه ۲۰۲۱ این ضعف به Security Misconfiguration منتقل شد و CWE-611 به‌صورت مشخص در A05:2021 قرار گرفت.

در جدیدترین نسخه OWASP Top 10 یعنی نسخه ۲۰۲۵، Security Misconfiguration به رتبه A02 رسیده و CWE-611 همچنان یکی از CWEهای شاخص این دسته است.

این تغییر طبقه‌بندی معنی مهمی دارد.

ریشه بسیاری از XXEها این نیست که XML «ذاتاً ناامن» است.

ریشه اصلی اغلب این است که XML Parser با Featureهای بیش از حد نیاز فعال شده است.

مثلاً Application فقط می‌خواهد:

نام،

شماره سفارش،

و تاریخ

را از یک XML Document بخواند.

اما Parser همزمان اجازه:

DTD Processing،

External Entity Resolution،

Network Access

و سایر قابلیت‌هایی را دارد که Application اصلاً به آن‌ها نیاز ندارد.

این نمونه‌ای کلاسیک از Security Misconfiguration و نقض Principle of Least Privilege است.

XML چیست؟

XML مخفف Extensible Markup Language است.

XML برای نمایش Data ساختاریافته طراحی شده است.

یک Document XML ساده می‌تواند اطلاعاتی مانند:

کاربر،

سفارش،

محصول،

تنظیمات،

یا Message بین دو سیستم

را نمایش دهد.

مزیت XML این است که ساختار آن Self-describing است؛ یعنی نام Elementها می‌تواند معنای Data را مشخص کند.

برای مثال یک سیستم فروشگاهی ممکن است XMLی شامل:

Order

Customer

Amount

Date

داشته باشد.

XML طی سال‌ها در Protocolها و Technologyهای مختلف استفاده شده است.

از جمله:

SOAP

XML-RPC

SAML

RSS

WSDL

Configuration Files

Data Import/Export

Office Document Formats

Enterprise Integrations

بنابراین حتی اگر Application مدرن شما بیشتر از JSON استفاده کند، ممکن است هنوز در بخشی از Infrastructure با XML سروکار داشته باشید.

XML Parser چیست؟

XML Parser نرم‌افزار یا Libraryای است که XML Document را می‌خواند و آن را به ساختاری تبدیل می‌کند که Application بتواند پردازش کند.

برای مثال Parser ممکن است XML را تبدیل کند به:

DOM Tree

Object

Stream of Events

Data Structure

Application سپس اطلاعات موردنیاز خود را از این ساختار استخراج می‌کند.

Parserها قابلیت‌های مختلفی دارند.

بعضی از آن‌ها می‌توانند:

DTD را پردازش کنند.

Schema Validation انجام دهند.

Entityها را Expand کنند.

External Resource Load کنند.

Network Request انجام دهند.

همین Featureها هستند که اگر بدون نیاز فعال شوند، Attack Surface را افزایش می‌دهند.

Entity در XML چیست؟

Entity در XML را می‌توان تا حدی مشابه یک Reference یا Placeholder تصور کرد.

یک Entity می‌تواند مقدار مشخصی داشته باشد و هنگام Parse شدن جایگزین شود.

برای مثال یک Application ممکن است در یک Document از Entity برای تعریف مقدار تکراری استفاده کند.

Entityها می‌توانند:

Internal

یا:

External

باشند.

Internal Entity

مقدار آن داخل همان XML یا DTD تعریف می‌شود.

External Entity

به Resource دیگری خارج از Document اشاره می‌کند.

این External Resource می‌تواند بسته به Parser و Configuration یک:

File

URL

Network Resource

یا Resource دیگری

باشد.

همین قابلیت زمینه اصلی XXE را ایجاد می‌کند.

DTD چیست؟

DTD مخفف Document Type Definition است.

DTD برای تعریف Structure و Ruleهای یک XML Document استفاده می‌شود.

می‌تواند مشخص کند:

چه Elementهایی مجاز هستند،

چه Attributeهایی وجود دارند،

ساختار Document چگونه است،

و چه Entityهایی تعریف شده‌اند.

DTD ممکن است:

داخل خود XML قرار گیرد

یا:

به یک DTD خارجی اشاره کند.

Microsoft نیز در مستندات XmlReaderSettings توضیح می‌دهد DTD می‌تواند Inline باشد یا به یک فایل DTD خارجی اشاره کند.

از نظر امنیتی، اگر Application به DTD نیازی ندارد، امن‌ترین راه معمولاً Disable کردن آن است.

OWASP نیز همین رویکرد را به‌عنوان دفاع اصلی توصیه می‌کند.

XXE چگونه ایجاد می‌شود؟

برای درک حمله، نیازی نیست Payload عملی XXE را اجرا کنیم.

فرآیند را می‌توان در سطح معماری بررسی کرد.

مرحله اول: Application ورودی XML دریافت می‌کند

برای مثال:

API

File Upload

SOAP Endpoint

Importer

یا Integration خارجی.

مرحله دوم: ورودی به XML Parser داده می‌شود

Parser XML را Parse می‌کند.

مرحله سوم: Document دارای Reference خارجی است

XML درخواست می‌کند Parser یک Entity یا DTD خارجی را Resolve کند.

مرحله چهارم: Parser اجازه External Resolution دارد

این مهم‌ترین نقطه ضعف است.

اگر Parser بدون محدودیت External Resource را Load کند، Application وارد محدوده‌ای می‌شود که طراح سیستم شاید اصلاً انتظار آن را نداشته باشد.

مرحله پنجم: Resource خارجی وارد پردازش می‌شود

این Resource ممکن است:

یک فایل محلی،

یک URL داخلی،

یک Service شبکه

یا Data دیگری

باشد.

مرحله ششم: نتیجه ممکن است در Response یا Behavior سیستم دیده شود

بسته به Application، اطلاعات ممکن است:

در Response نمایش داده شوند،

در Error ظاهر شوند،

در Log قرار بگیرند،

به Server دیگری ارسال شوند،

یا فقط Side Effect شبکه‌ای ایجاد کنند.

بنابراین XXE فقط یک Attack Pattern واحد ندارد.

پیامدهای XXE چیست؟

یکی از دلایل اهمیت XXE این است که Impact آن بسته به Environment می‌تواند بسیار متفاوت باشد.

OWASP پیامدهایی مانند Denial of Service، SSRF و تأثیرهای مرتبط با دسترسی Network را برای XXE مطرح می‌کند.

MITRE نیز File Disclosure و خواندن Resourceهای محلی را از پیامدهای CWE-611 می‌داند.

افشای فایل‌های محلی

اگر XML Parser اجازه Resolve کردن File URI یا External Resource محلی را داشته باشد، ممکن است XML بتواند Parser را وادار کند فایل محلی را بخواند.

شدت این Risk به Permission Process بستگی دارد.

برای مثال اگر Web Server Process فقط دسترسی محدودی داشته باشد، Scope آسیب کمتر است.

اما اگر Application با Privilege زیاد اجرا شود، Risk بیشتر خواهد شد.

این مثال اهمیت Least Privilege در سطح Operating System را نیز نشان می‌دهد.

حتی اگر Parser Configuration اشتباه باشد، محدود بودن Permission Process می‌تواند Blast Radius را کاهش دهد.

SSRF از طریق XXE

یکی از مهم‌ترین کاربردهای XXE برای مهاجم، تبدیل XML Parser به یک HTTP Client ناخواسته است.

فرض کنید Server اجازه دارد به Network داخلی دسترسی داشته باشد.

اگر External Entity Resolution بتواند URL دریافت کند، Parser ممکن است Requestی از داخل Server به مقصد دیگری ایجاد کند.

این رفتار می‌تواند به SSRF منجر شود.

در این حالت مهاجم مستقیماً به Internal Service متصل نمی‌شود.

Server آسیب‌پذیر از طرف او این کار را انجام می‌دهد.

هدف بالقوه می‌تواند شامل:

Internal API

Management Interface

Cloud Metadata Service

Service Discovery

Localhost Service

باشد.

البته میزان دسترسی کاملاً به Network Architecture و Parser بستگی دارد.

آیا XXE می‌تواند برای Network Discovery استفاده شود؟

در بعضی Environmentها External Resource Resolution می‌تواند باعث Connection Attempt به Addressها یا Portهای مختلف شود.

OWASP این قابلیت را نیز در فهرست Impactهای احتمالی XXE ذکر می‌کند.

مهاجم ممکن است از تفاوت:

Response Time

Error

یا Behavior Application

برای استنباط اطلاعات درباره Network داخلی استفاده کند.

به همین دلیل Egress Control و Network Segmentation لایه دفاعی مهمی محسوب می‌شوند.

XXE و Denial of Service

XML Parsing می‌تواند از طریق Entity Processing به Resource Consumption منجر شود.

یکی از خانواده‌های شناخته‌شده حملات XML، Entity Expansion است.

اگر Entityها به شکل بازگشتی یا بسیار بزرگ Expand شوند، Parser ممکن است:

CPU

Memory

یا زمان پردازش

زیادی مصرف کند.

این خانواده گاهی با اصطلاح XML Bomb نیز شناخته می‌شود.

در OWASP Top 10، CWE-776 یا Improper Restriction of Recursive Entity References نیز در کنار XXE در Security Misconfiguration دیده می‌شود.

بنابراین Disable کردن External Entity به‌تنهایی تمام XML Resource Exhaustion Scenarioها را حل نمی‌کند.

Parser Limit نیز اهمیت دارد.

Blind XXE چیست؟

گاهی Application نتیجه External Entity را مستقیماً در Response نمایش نمی‌دهد.

در این شرایط Vulnerability ممکن است همچنان وجود داشته باشد.

به این حالت در ادبیات امنیت معمولاً Blind XXE گفته می‌شود.

مثلاً Parser ممکن است یک Connection خارجی ایجاد کند، اما Response آن به User نشان داده نشود.

از دید دفاعی این موضوع یک پیام مهم دارد:

نبود Data داخل Response به معنی نبود XXE نیست.

Security Testing باید Network Behavior و Parser Configuration را نیز بررسی کند.

Error-based XXE چیست؟

گاهی Information Disclosure از طریق Error Message رخ می‌دهد.

Parser ممکن است هنگام Resolve کردن Entity خارجی با Error روبه‌رو شود و Error حاوی اطلاعاتی درباره:

Path

Resource

Parser

Application

باشد.

بنابراین Secure Error Handling نیز بخشی از XXE Prevention است.

Production Application نباید Parser Stack Trace یا Internal Pathهای حساس را مستقیماً به User نمایش دهد.

XXE و XML Injection چه تفاوتی دارند؟

این دو مفهوم نباید با هم اشتباه گرفته شوند.

XML Injection

XML Injection زمانی رخ می‌دهد که Input User به شکلی ناامن داخل XML قرار گیرد و ساختار Document را تغییر دهد.

تمرکز آن روی Injection به XML Structure است.

XXE

XXE روی External Entity Resolution تمرکز دارد.

Application ممکن است XML را کاملاً معتبر دریافت کند، اما Parser Feature خطرناکی فعال باشد.

هر دو ممکن است همزمان در یک Application وجود داشته باشند، اما Root Cause آن‌ها متفاوت است.

XXE و SSRF چه تفاوتی دارند؟

XXE یک Vulnerability مربوط به XML Processing است.

SSRF یک Attack Class گسترده‌تر است که در آن Application به مقصدی که مهاجم کنترل می‌کند Request Server-side ارسال می‌کند.

XXE می‌تواند یکی از مسیرهای رسیدن به SSRF باشد.

اما SSRF ممکن است از Featureهای دیگری نیز ایجاد شود:

URL Preview

Webhook

Image Fetcher

PDF Generator

Proxy Endpoint

Remote Import

بنابراین:

XXE می‌تواند باعث SSRF شود.

اما هر SSRF یک XXE نیست.

XXE و Path Traversal چه تفاوتی دارند؟

در Path Traversal مهاجم معمولاً Path ورودی را Manipulate می‌کند تا به فایل خارج از Directory مجاز دسترسی پیدا کند.

در XXE، Parser با Resolve کردن Entity خارجی ممکن است به File Resource دسترسی پیدا کند.

نتیجه در بعضی Scenarioها مشابه است؛ یعنی خواندن فایل.

اما Mechanism و Defense متفاوت‌اند.

کدام برنامه‌ها بیشتر در معرض XXE هستند؟

هر Applicationی که XML غیرقابل اعتماد Parse کند باید بررسی شود.

نمونه‌ها:

SOAP Web Service

SAML Integration

Enterprise API

XML-RPC

File Importer

RSS/Feed Processor

Office Document Processor

SVG Processor

Custom Plugin

Legacy Application

B2B Integration

Configuration Import

Web Service Gateway

همچنین ممکن است Developer حتی متوجه XML بودن Data نباشد.

برای مثال Formatهایی مانند SVG اساساً XML-based هستند.

برخی Office Formatها نیز XML را در Packageهای خود استفاده می‌کنند.

بنابراین Attack Surface Inventory باید بر اساس Parser واقعی انجام شود، نه فقط File Extension .xml.

آیا JSON جایگزین امن XML است؟

استفاده از JSON می‌تواند Attack Surface مربوط به DTD و External Entity را حذف کند، زیرا JSON این Conceptها را ندارد.

OWASP نیز در شرایطی که Functionality اجازه دهد استفاده از Data Format ساده‌تر مانند JSON را یکی از راه‌های کاهش XXE Attack Surface مطرح می‌کند.

اما این به معنی «JSON همیشه امن است» نیست.

JSON نیز ممکن است در برابر:

Injection

Mass Assignment

Unsafe Deserialization

DoS

و Validation Error

آسیب‌پذیر باشد.

مفهوم اصلی کاهش Featureهای غیرضروری است.

بهترین روش جلوگیری از XXE چیست؟

اصل اول OWASP بسیار واضح است:

اگر Application به DTD نیاز ندارد، DTD را کاملاً Disable کنید.

اگر DTD غیرفعال باشد، بسیاری از XXE Scenarioها از پایه حذف می‌شوند.

اما در عمل Prevention چند لایه دارد.

Disable کردن DTD

در Parserهایی که امکان آن وجود دارد:

DOCTYPE و DTD Processing را Prohibit کنید.

Disable کردن External Entity

External General Entity و External Parameter Entity نباید Resolve شوند مگر Requirement مشخصی وجود داشته باشد.

Disable کردن Network Access

Parser نباید بتواند Arbitrary Resource را از Network Load کند.

استفاده از Parser به‌روز

Defaultهای امنیتی Parserها طی سال‌ها تغییر کرده‌اند.

نسخه قدیمی ممکن است Behavior کاملاً متفاوتی با نسخه جدید داشته باشد.

Input Validation

فرمت ورودی باید دقیقاً با انتظار Application سازگار باشد.

Resource Limit

محدودیت:

Size

Depth

Entity Expansion

Time

Memory

در نظر گرفته شود.

Least Privilege

Process باید حداقل دسترسی لازم به File System و Network را داشته باشد.

Egress Filtering

Application Server نباید بدون نیاز به تمام Internet یا Internal Network دسترسی داشته باشد.

Defense in Depth برای XXE

فرض کنیم Developer Parser را اشتباه Config کرد.

آیا Application بلافاصله باید بتواند فایل‌های مهم Server را بخواند و به تمام Network داخلی وصل شود؟

نه.

Security Architecture باید چند لایه باشد.

یک مدل دفاعی مناسب:

Parser Security

Application Validation

File System Permission

Container Isolation

Network Segmentation

Egress Filtering

Secret Management

Error Handling

Monitoring

را با هم ترکیب می‌کند.

این همان مفهوم Defense in Depth است.

XXE در Java

Java یکی از Environmentهایی است که XML Processing APIهای متعدد دارد.

برای مثال:

DocumentBuilderFactory

SAXParserFactory

XMLInputFactory

TransformerFactory

SchemaFactory

هر API ممکن است Security Propertyهای متفاوتی داشته باشد.

OWASP برای Java توصیه‌های Parser-specific ارائه می‌کند و تأکید می‌کند DTD، External General Entity و External Parameter Entity در Parserهایی که XML غیرقابل اعتماد دریافت می‌کنند محدود یا غیرفعال شوند.

Oracle نیز در JAXP Security Guide می‌گوید جلوگیری از Arbitrary External Access برای XML Security ضروری است و External Access Propertyها و Resolver/Catalogهای کنترل‌شده برای محدود کردن Resource Resolution استفاده می‌شوند.

نکته مهم در Java

نباید فقط به Default اعتماد کرد.

Oracle صراحتاً می‌گوید بعضی Security Featureها به شکل پیش‌فرض وجود دارند، اما Default Configuration الزاماً تمام External Entity Resolution را Restrict نمی‌کند و بهتر است External Access Restrictions به‌صورت صریح تنظیم شوند.

الگوی دفاعی

اگر DTD نیاز ندارید:

DTD را غیرفعال کنید.

External Entity را غیرفعال کنید.

External Schema Access را ببندید.

External DTD Access را ببندید.

و Parser Configuration را Unit Test کنید.

این بهتر از اعتماد به Default Version-specific است.

XXE در .NET

در .NET، رفتار امن به:

Version

Class

و Configuration

وابسته است.

XmlReaderSettings Propertyای به نام DtdProcessing دارد.

Microsoft سه حالت را معرفی می‌کند:

Prohibit

Ignore

و:

Parse

در حالت Prohibit اگر DTD دیده شود، Exception ایجاد می‌شود.

در حالت Ignore DTD پردازش نمی‌شود.

و Parse باعث DTD Processing خواهد شد.

برای XML غیرقابل اعتماد، معمولاً نباید DTD Processing بدون Requirement مشخص فعال شود.

Microsoft همچنین در Ruleهای امنیتی .NET هشدار می‌دهد Processing کردن DTD یا Schema غیرقابل اعتماد می‌تواند به Information Disclosure، SSRF و Denial of Service منجر شود.

XmlResolver

یکی دیگر از تنظیمات مهم XmlResolver است.

اگر Application به External Resource نیاز ندارد، Resolver نباید اجازه دسترسی Arbitrary بدهد.

Microsoft برای کاهش XXE توصیه می‌کند از Resolver امن استفاده شود یا در موارد مناسب XmlResolver به null تنظیم شود.

نتیجه مهم

یک .NET Application جدید ممکن است Defaultهای امن‌تری نسبت به Software بسیار قدیمی داشته باشد.

اما Security Review باید تنظیم واقعی Parser را بررسی کند، نه اینکه فقط Version Framework را امن فرض کند.

XXE در PHP

PHP در بسیاری از Applicationهای وب و CMSها استفاده می‌شود و XML Processing معمولاً از طریق libxml انجام می‌شود.

PHP Manual توضیح می‌دهد از libxml 2.9.0 به بعد Entity Substitution به‌صورت پیش‌فرض غیرفعال شده است. به همین دلیل تابع قدیمی libxml_disable_entity_loader() از PHP 8.0 Deprecated شده است.

اما این موضوع نباید به شکل:

«PHP 8 هیچ‌وقت XXE ندارد»

تفسیر شود.

Configuration و Flagهای Parser همچنان مهم هستند.

PHP Manual هشدار می‌دهد LIBXML_NOENT Entity Substitution را فعال می‌کند و می‌تواند زمینه XXE را ایجاد کند.

همچنین در PHP 8.4 همراه libxml 2.13 یا جدیدتر، Constant جدید LIBXML_NO_XXE برای جلوگیری از External XML Entity هنگام Entity Substitution در دسترس قرار گرفته است.

نکته مهم برای پروژه‌های PHP

هنگام Review موارد زیر را بررسی کنید:

DOMDocument

SimpleXML

XMLReader

SOAP

Libraryهای Third-party

Flagهای libxml

Version واقعی libxml

وجود LIBXML_NOENT

وجود DTD Validation

Developer نباید فقط Version PHP را بررسی کند.

XXE در Python

در Python نیز Library انتخابی و Parser Behavior مهم است.

اگر Application XML غیرقابل اعتماد Parse می‌کند، باید Documentation دقیق Library و نسخه مورد استفاده بررسی شود.

اصل امن همان است:

Featureهای XML که به آن‌ها نیاز ندارید فعال نکنید.

External Resource Resolution را محدود کنید.

Size و Complexity Input را کنترل کنید.

در Applicationهای حساس استفاده از Libraryهایی که برای XML غیرقابل اعتماد Hardening بیشتری دارند می‌تواند کمک‌کننده باشد.

XXE در WordPress

WordPress نیز بخش‌هایی دارد که با XML ارتباط دارند.

برای مثال WordPress دارای XML-RPC API است و مستندات رسمی WordPress مجموعه‌ای از Methodهای XML-RPC برای Post، Media، Comment، User و سایر بخش‌ها ارائه می‌کنند.

WordPress همچنین از فایل‌های WXR مبتنی بر XML برای Import/Export محتوا استفاده می‌کند.

اما وجود XML-RPC یا XML Import به معنی وجود XXE در WordPress Core نیست.

Risk اصلی زمانی مطرح می‌شود که:

Plugin اختصاصی،

Importer،

SOAP Integration،

SVG Processor،

یا Library ثالث

XML غیرقابل اعتماد را با Parser Configuration ناامن پردازش کند.

بنابراین Finding امنیتی نباید صرفاً بگوید:

«WordPress XML استفاده می‌کند، پس XXE دارد.»

باید Parser و Data Flow واقعی بررسی شود.

XXE در افزونه‌های وردپرس

در Plugin Review باید دنبال Functionalityهایی باشید که XML دریافت می‌کنند.

مثلاً:

Import Product

Import Feed

SOAP Integration

CRM Sync

Payment Integration

SVG Processing

Remote Feed

Legacy API

اگر Plugin XML Upload را قبول می‌کند، باید مشخص شود:

Parser چیست؟

DTD فعال است؟

External Entity فعال است؟

Network Resolution فعال است؟

File Size Limit وجود دارد؟

Errorها چگونه مدیریت می‌شوند؟

Dependency به‌روز است؟

بسیاری از Riskهای WordPress نه از Core، بلکه از Extensionهای Third-party یا Custom Code ایجاد می‌شوند.

XXE و WooCommerce

فروشگاه WooCommerce ممکن است از Pluginهای مختلف برای:

ERP

Accounting

Inventory

Supplier Feed

Payment

Shipping

Product Import

استفاده کند.

بعضی Integrationهای Enterprise هنوز XML یا SOAP استفاده می‌کنند.

اگر Data از Vendor یا External Source دریافت شود، نباید صرفاً به دلیل «Partner بودن» Trusted تلقی شود.

Supply Chain Compromise یا Configuration Error می‌تواند Data را تغییر دهد.

XML ورودی باید براساس Trust Level واقعی پردازش شود.

آیا XML-RPC را برای جلوگیری از XXE باید غیرفعال کنیم؟

نه لزوماً.

غیرفعال کردن XML-RPC صرفاً به دلیل نگرانی XXE تصمیم دقیقی نیست.

باید بررسی شود:

آیا سایت از XML-RPC استفاده می‌کند؟

آیا Endpoint موردنظر Vulnerability واقعی دارد؟

چه قابلیت‌هایی نیاز هستند؟

WordPress Documentation می‌گوید XML-RPC از نسخه 3.5 به‌صورت پیش‌فرض فعال است و Methodهای Authentication-based آن را می‌توان از طریق Filter مربوطه محدود کرد.

اما XXE Prevention باید روی Parser Configuration متمرکز باشد، نه صرفاً نام Protocol.

XXE در SVG

SVG یک Image Format مبتنی بر XML است.

این یعنی Upload یا Processing فایل SVG باید با دقت بیشتری نسبت به Formatهای ساده‌تر تصویر انجام شود.

Risk SVG فقط XXE نیست؛ SVG می‌تواند Security Concernهای دیگری نیز داشته باشد.

اگر سایت اجازه SVG Upload می‌دهد:

File را صرفاً بر اساس Extension Trust نکنید.

Parser/Renderer واقعی را بررسی کنید.

Sanitization مناسب داشته باشید.

Library به‌روز باشد.

XML External Resolution غیرفعال باشد.

اگر SVG به Feature سایت نیاز ندارد، Allow نکردن آن Attack Surface را کاهش می‌دهد.

XXE در SOAP

SOAP به‌شدت با XML گره خورده است.

SOAP Service ممکن است:

Request XML دریافت کند،

WSDL بخواند،

Schema Validation انجام دهد،

و Resourceهای External داشته باشد.

به همین دلیل تنظیم Parser اهمیت زیادی دارد.

خصوصاً در Applicationهای قدیمی، Defaultهای Parser باید بازبینی شوند.

Migration Framework بدون Security Review نیز ممکن است Behavior را تغییر دهد.

XXE در SAML

SAML نیز XML-based است.

Security SAML بسیار فراتر از XXE است و شامل:

Signature Validation

Audience

Issuer

Replay Protection

و Trust Configuration

می‌شود.

اما Parser XML مورد استفاده برای خواندن SAML Assertion نیز باید در برابر Entity Resolution ناامن محافظت شود.

در Authentication Systemها، Parser Misconfiguration می‌تواند Impact بسیار جدی داشته باشد.

چرا فقط Input Validation کافی نیست؟

ممکن است Developer تلاش کند عبارت‌هایی مانند DOCTYPE را با Regex از XML حذف کند.

این رویکرد معمولاً Defence اصلی مناسبی نیست.

XML Grammar پیچیده‌تر از یک String ساده است.

امنیت باید در Parser Layer enforce شود.

اصل بهتر:

Parser خطرناک را Disable کنید،

سپس Validation اضافه کنید.

نه اینکه Parser همچنان External Entity را Resolve کند و قبل از آن چند Keyword را Filter کنیم.

آیا WAF می‌تواند XXE را متوقف کند؟

WAF ممکن است برخی Patternهای شناخته‌شده XML Attack را شناسایی کند.

اما WAF Defense اصلی نیست.

دلایل:

Encoding ممکن است متفاوت باشد.

XML Syntax متنوع است.

Traffic داخلی ممکن است WAF را دور بزند.

Application ممکن است File Upload را Async Parse کند.

Parser Behavior را فقط Application می‌داند.

WAF می‌تواند Layer اضافی باشد، اما Fix واقعی باید در Parser Configuration انجام شود.

آیا Antivirus جلوی XXE را می‌گیرد؟

خیر.

XXE الزاماً Malware File نیست.

ممکن است XML کاملاً Textual و از نظر Syntax معتبر باشد.

مشکل در نحوه Interpretation سند توسط Parser است.

Antivirus جای Secure XML Parser را نمی‌گیرد.

Egress Filtering چگونه کمک می‌کند؟

اگر Application Server اجازه Connection به هیچ مقصد غیرضروری نداشته باشد، XXE-based SSRF محدودتر می‌شود.

برای مثال Web Application شاید فقط نیاز داشته باشد به:

Database

Payment API

یک Storage Service

متصل شود.

دلیلی ندارد به تمام Private Network و Internet دسترسی آزاد داشته باشد.

Egress Policy می‌تواند Destinationهای مجاز را محدود کند.

این Control علاوه بر XXE، Riskهای:

SSRF

Malware Callback

Compromised Dependency

را نیز کاهش می‌دهد.

File System Permission چگونه Impact را کاهش می‌دهد؟

Web Server Process نباید Permission Root داشته باشد.

اگر Application فقط باید Fileهای Upload خودش را بخواند، بهتر است به:

System Configuration

Secret Directory

SSH Key

Backup

دسترسی نداشته باشد.

Least Privilege باعث می‌شود حتی در صورت ایجاد Parser Bug، Data قابل دسترسی محدودتر باشد.

Containerization آیا XXE را حل می‌کند؟

خیر، اما Impact را کاهش می‌دهد.

اگر Application داخل Container با:

Read-only Filesystem

Network Restriction

Non-root User

Limited Mount

اجرا شود، Blast Radius یک XXE می‌تواند کمتر شود.

ولی اگر Container به Secretها یا Internal Network دسترسی کامل داشته باشد، Isolation مزیت محدودی خواهد داشت.

XML Schema Validation آیا XXE را متوقف می‌کند؟

نه الزاماً.

Schema Validation و XXE Prevention دو مسئله متفاوت‌اند.

Application ممکن است Document را با XSD Validate کند ولی Parser همچنان External Resource Resolution داشته باشد.

حتی Schema خود نیز ممکن است External Reference داشته باشد.

Oracle و Microsoft هر دو بر محدود کردن External Access هنگام XML Validation تأکید دارند.

بنابراین Validation جای Parser Hardening را نمی‌گیرد.

Secure Resolver چیست؟

گاهی Application واقعاً به External Resource نیاز دارد.

مثلاً مجموعه‌ای از Schemaهای داخلی و کنترل‌شده.

در این صورت Disable کامل External Resolution ممکن است Functionality را بشکند.

راهکار بهتر می‌تواند Custom Resolver یا Catalog باشد.

Resolver امن می‌تواند بگوید:

فقط این Resourceها مجاز هستند.

فقط Local Catalog استفاده شود.

Network Access ممنوع است.

Destinationهای دیگر Reject شوند.

Oracle نیز Resolverها و Catalogها را برای کنترل Fine-grained External Resource Access پیشنهاد می‌کند.

Allowlist بهتر است یا Blocklist؟

در XML External Resource Resolution، Allowlist معمولاً رویکرد امن‌تری است.

Blocklist می‌پرسد:

«چه چیزهایی خطرناک‌اند؟»

Allowlist می‌پرسد:

«Application واقعاً به چه چیزهایی نیاز دارد؟»

اگر فقط سه Schema داخلی لازم است، همان سه مورد را Allow کنید.

نیازی نیست صدها Protocol و Destination بالقوه را یکی‌یکی Block کنید.

URL Schemeها باید محدود شوند

اگر External Resolution اجتناب‌ناپذیر است، باید بررسی شود چه Protocolهایی مجاز هستند.

در بسیاری از موارد فقط:

File داخلی مشخص

یا:

HTTPS به Domain مشخص

لازم است.

نباید Parser بتواند بدون Requirement هر Scheme پشتیبانی‌شده توسط Runtime را Resolve کند.

XXE و Secretهای Cloud

در Cloud Environment، SSRF پیامد مهم‌تری پیدا می‌کند.

Server ممکن است به Endpointهایی در Network داخلی دسترسی داشته باشد که Internet User به آن‌ها دسترسی مستقیم ندارد.

به همین دلیل:

Metadata Service Protection

IAM Least Privilege

Network Policy

و Parser Hardening

باید همزمان در نظر گرفته شوند.

حتی اگر XXE مستقیم Data فایل را نمایش ندهد، Network Access می‌تواند Impact مهمی داشته باشد.

چگونه بفهمیم Application XML Parse می‌کند؟

مرحله اول Asset Discovery است.

در Code و Dependencyها به دنبال مواردی مانند:

XML Parser

DOM

SAX

XMLReader

DocumentBuilder

SOAP

SAML

WSDL

RSS

SVG

XSLT

XPath

Import XML

باشید.

همچنین Endpointهایی با Content-Typeهای XML را بررسی کنید.

اما فقط HTTP API کافی نیست.

Background Job و File Importer نیز اهمیت دارند.

Code Review برای XXE

در Code Review سؤال‌های زیر مهم هستند:

Parser کدام است؟

Version چیست؟

DTD Processing فعال است؟

External Entity Resolution فعال است؟

External Schema Resolution فعال است؟

Network Access ممکن است؟

Custom Resolver وجود دارد؟

Parser Optionها چگونه تنظیم شده‌اند؟

Input از کجا می‌آید؟

Errorها چه چیزی نمایش می‌دهند؟

Resource Limit چیست؟

Developer باید دقیقاً Library Documentation همان Version را بررسی کند.

Dependency Review

حتی اگر Application Code مستقیم XML Parse نکند، Dependency ممکن است این کار را انجام دهد.

مثلاً:

SAML Library

Office Parser

SVG Library

SOAP Client

Document Converter

Framework Plugin

ممکن است Parser داخلی داشته باشند.

SCA یا Software Composition Analysis می‌تواند Versionهای آسیب‌پذیر شناخته‌شده را شناسایی کند، اما Configuration Review همچنان لازم است.

SAST برای XXE

Static Application Security Testing می‌تواند بعضی APIهای XML ناامن یا Parser Optionهای خطرناک را پیدا کند.

برای مثال Rule امنیتی .NET CA3075 برای Insecure DTD Processing طراحی شده است و مواردی مانند DTD Parse فعال یا Resolver ناامن را شناسایی می‌کند.

اما SAST ممکن است Data Flow یا Dynamic Configuration را کامل متوجه نشود.

بنابراین یافته باید Manual Review شود.

DAST برای XXE

Dynamic Testing می‌تواند رفتار Application را هنگام دریافت XML غیرعادی بررسی کند.

در محیط مجاز می‌توان بررسی کرد:

آیا DTD پذیرفته می‌شود؟

آیا External Resolution رخ می‌دهد؟

آیا Network Side Effect ایجاد می‌شود؟

آیا Error اطلاعات حساس می‌دهد؟

برای تست Security باید از Resourceهای کنترل‌شده و بی‌خطر استفاده شود و نباید فایل‌های حساس واقعی یا سیستم‌های بدون مجوز هدف قرار بگیرند.

تست امن XXE چگونه باشد؟

هدف تست دفاعی اثبات Configuration است، نه استخراج Data.

روش بهتر:

Test XML کنترل‌شده

External URL متعلق به Test Environment

Monitoring Connection

عدم استفاده از Resource حساس

اجرای تست روی Staging

ثبت Log Parser

است.

اگر Parser تلاش کند Resource Test را Resolve کند، همان برای نشان دادن مشکل Configuration کافی است.

نیازی به خواندن فایل واقعی Server نیست.

Negative Testing

برای Parser باید Testهایی وجود داشته باشند که:

Document دارای DTD Reject شود.

Entity خارجی Resolve نشود.

Network Resource Load نشود.

XML بیش از حد بزرگ Reject شود.

Entity Expansion Limit رعایت شود.

Error امن برگردد.

این تست‌ها باید در CI/CD تکرار شوند.

Secure Defaults چرا مهم است؟

فرض کنید Developer جدید Function XML Import ایجاد می‌کند.

اگر Library داخلی سازمان Parser امن آماده‌ای داشته باشد، احتمال ایجاد XXE کمتر می‌شود.

اما اگر هر Developer مجبور باشد ده Option امنیتی را از حافظه تنظیم کند، خطا محتمل‌تر است.

بنابراین سازمان‌ها می‌توانند Secure Wrapper ایجاد کنند.

مثلاً:

SecureXmlParser

که تمام Defaultهای امن را از قبل فعال می‌کند.

این نمونه‌ای از Paved Road در Secure Development است.

Parser Upgrade و Regression

گاهی با Upgrade Library رفتار Default تغییر می‌کند.

ممکن است Feature قبلاً Disable بوده و بعد Configuration تغییر کند یا برعکس.

بنابراین Unit Test امنیتی باید Behavior را Verify کند.

نباید فقط فرض کنیم:

«Library جدید است، پس امن است.»

Security Regression Test اهمیت دارد.

Error Handling در XML Parser

XML Error Message ممکن است شامل:

Full File Path

Internal URL

Library Version

Stack Trace

Schema Path

باشد.

Production Application باید Error مناسب User را از Technical Log جدا کند.

مثلاً User فقط ببیند:

«فایل XML معتبر نیست.»

و Technical Detail داخل Log محافظت‌شده ثبت شود.

این کار Information Disclosure را کاهش می‌دهد.

Logging برای XXE

مواردی که می‌توان Monitor کرد:

DOCTYPE در ورودی غیرمنتظره

External Entity Attempt

XML Parser Error غیرعادی

URL Resolution توسط Parser

افزایش XML Parsing Failure

Oversized XML

Repeated Import Failure

اما Log نباید کل XML حساس را بدون نیاز ذخیره کند.

ممکن است Document شامل PII یا Credential باشد.

Rate Limiting

اگر Endpoint XML Parsing سنگین دارد، Rate Limit اهمیت بیشتری پیدا می‌کند.

XML Processing می‌تواند CPU-intensive باشد.

مهاجم حتی بدون XXE ممکن است تعداد زیادی Document بزرگ ارسال کند.

Controlهای مناسب:

Request Size Limit

Rate Limit

Timeout

Concurrency Limit

Queue

Resource Quota

هستند.

محدود کردن اندازه XML

یکی از دفاع‌های ساده ولی مؤثر:

حداکثر File Size.

اگر Business Requirement حداکثر فایل ۲ مگابایت است، پذیرش فایل ۵۰۰ مگابایتی منطقی نیست.

همچنین Limit روی:

Element Count

Depth

Attribute Count

Text Length

می‌تواند XML Bomb و Parser Abuse را سخت‌تر کند.

XML Parsing را از Process اصلی جدا کنیم؟

برای Applicationهای پرخطر، پردازش File غیرقابل اعتماد می‌تواند در یک Worker محدود انجام شود.

Worker می‌تواند:

Container جدا

Network محدود

File System محدود

CPU Limit

Memory Limit

داشته باشد.

اگر Parser Fail شود، کل Web Application تحت تأثیر قرار نمی‌گیرد.

XML Parser و Principle of Least Functionality

اگر Application فقط XML ساده می‌خواهد، چرا Featureهای زیر فعال باشند؟

DTD

External Entity

XInclude

External Schema

Remote Resource

XSLT Extension

هر Feature اضافی باید Requirement داشته باشد.

غیرفعال کردن Capabilityهای غیرضروری یکی از اصول اصلی Hardening است.

آیا Disable کردن DTD همیشه امکان‌پذیر است؟

نه.

بعضی Legacy Protocolها ممکن است واقعاً DTD نیاز داشته باشند.

در چنین شرایطی باید به‌جای Disable کامل:

External Entity را محدود کنید.

Resolver Allowlist ایجاد کنید.

Network Access را ببندید.

Local Catalog استفاده کنید.

Resource Limit اعمال کنید.

Input Source را محدود کنید.

Environment را Sandbox کنید.

هدف حذف Trust بی‌حد است.

Secure XML Parser در Java؛ رویکرد مفهومی

به‌جای ارائه یک Configuration واحد برای تمام Parserها، باید Factory مورد استفاده را دقیق مشخص کنید.

برای Parser موردنظر:

DTD را Prohibit کنید.

External General Entity را غیرفعال کنید.

External Parameter Entity را غیرفعال کنید.

External DTD/Schema Access را محدود کنید.

Secure Processing Feature را فعال کنید.

سپس Test کنید Document دارای External Reference واقعاً Reject می‌شود.

OWASP برای APIهای مختلف Java Configurationهای متفاوتی دارد؛ زیرا یک Flag واحد برای تمام Parserها وجود ندارد.

Secure XML Parser در .NET؛ نمونه دفاعی

در .NET برای XML غیرقابل اعتماد می‌توان Parser را طوری Config کرد که DTD پردازش نشود و External Resolver نداشته باشد.

الگوی دفاعی معمول شامل:

DtdProcessing = Prohibit

و در Contextهای مناسب:

XmlResolver = null

است.

Microsoft این تنظیمات را برای محدود کردن DTD و External Resource Processing مستند کرده است.

هدف این مثال آموزش حمله نیست؛ بلکه جلوگیری از Parser Behavior ناخواسته است.

Secure XML Parsing در PHP

در PHPهای جدید، External Entity Loading Default محدودتر شده است، اما Flagهای Parse همچنان باید بررسی شوند.

مخصوصاً از فعال کردن Entity Substitution بدون Requirement خودداری کنید.

PHP Manual هشدار امنیتی مشخصی برای LIBXML_NOENT دارد.

در PHP 8.4 و libxml جدید، قابلیت LIBXML_NO_XXE نیز برای محدود کردن External Entity در سناریوهای Entity Substitution اضافه شده است.

Configuration باید براساس Version واقعی Server تست شود.

چرا Copy/Paste تنظیمات اینترنتی خطرناک است؟

XML Parser Security به Version و Library وابسته است.

Snippet نوشته‌شده در سال ۲۰۱۴ ممکن است:

Deprecated باشد،

دیگر لازم نباشد،

یا حتی Behavior متفاوتی ایجاد کند.

برای مثال libxml_disable_entity_loader() در PHP 8 Deprecated است چون Defaultهای libxml تغییر کرده‌اند.

همیشه Documentation نسخه فعلی Runtime را بررسی کنید.

اشتباهات رایج در جلوگیری از XXE

اشتباه اول: تصور اینکه XML قدیمی است و دیگر استفاده نمی‌شود

ممکن است Frontend JSON استفاده کند اما Backend هنوز SOAP، SVG، SAML یا WXR داشته باشد.

اشتباه دوم: اعتماد به Default Parser

Defaultها میان Versionها متفاوت هستند.

Configuration امن باید Explicit باشد.

اشتباه سوم: Regex برای حذف DOCTYPE

Defense باید در Parser اعمال شود.

اشتباه چهارم: Disable کردن External Entity ولی باز گذاشتن XML Bomb

Entity Expansion و Resource Limit نیز باید بررسی شوند.

اشتباه پنجم: استفاده از WAF به‌عنوان Fix اصلی

Parser آسیب‌پذیر همچنان باقی می‌ماند.

اشتباه ششم: Trust کردن Partner XML

Data از Partner نیز ممکن است Compromise یا Manipulate شود.

اشتباه هفتم: اجرا با Permission بالا

این موضوع Impact File Disclosure را افزایش می‌دهد.

اشتباه هشتم: Network Access نامحدود Server

XXE-based SSRF را خطرناک‌تر می‌کند.

اشتباه نهم: نمایش Parser Error به User

می‌تواند Internal Information را افشا کند.

اشتباه دهم: بررسی فقط فایل .xml

SVG، SOAP، SAML و Formatهای دیگر نیز XML هستند.

چک‌لیست جلوگیری از XXE

Inventory

• تمام نقاط XML Parsing شناسایی شوند.
• Parser و Version هر کدام مشخص شود.
• Libraryهای Third-party بررسی شوند.
• SOAP، SAML، SVG و Importerها فراموش نشوند.

Parser

• DTD در صورت عدم نیاز Disable شود.
• External Entity Resolution غیرفعال شود.
• External Parameter Entity غیرفعال شود.
• Network Resolution محدود شود.
• XInclude در صورت عدم نیاز غیرفعال شود.
• Secure Processing Optionهای Parser فعال شوند.

Input

• Content-Type بررسی شود.
• XML Size محدود شود.
• Schema مورد انتظار Validate شود.
• Depth و Complexity محدود شود.
• Source غیرقابل اعتماد فرض شود.

Network

• Egress Access محدود شود.
• دسترسی به Internal Serviceها حداقلی باشد.
• Cloud Metadata Protection فعال باشد.
• Resolver فقط Destinationهای لازم را ببیند.

File System

• Process با User کم‌دسترسی اجرا شود.
• Secretها از Web Process جدا باشند.
• Directoryهای حساس Readable نباشند.
• Container Mountها محدود شوند.

Application

• Error Detail به User نمایش داده نشود.
• XML Parsing Failure Log شود.
• Rate Limit وجود داشته باشد.
• Timeout تعریف شود.
• Import Jobها Monitor شوند.

Development

• Parser Configuration Code-reviewed شود.
• Security Unit Test وجود داشته باشد.
• SAST Ruleهای XXE فعال باشند.
• Dependencyها به‌روز باشند.
• Security Regression Test انجام شود.

چک‌لیست XXE برای WordPress

در سایت WordPress موارد زیر را بررسی کنید:

• آیا Pluginی XML Import انجام می‌دهد؟
• آیا SVG Upload فعال است؟
• آیا SOAP Integration وجود دارد؟
• آیا XML-RPC واقعاً موردنیاز است؟
• آیا ERP یا CRM فایل XML ارسال می‌کند؟
• Parser Plugin از چه Library استفاده می‌کند؟
• PHP و libxml چه Versionی دارند؟
• آیا LIBXML_NOENT در Custom Code استفاده شده؟
• آیا XML File Size محدود است؟
• آیا External URL Resolution ممکن است؟
• آیا Server Egress محدود است؟
• آیا Logها Parser Error حساس نمایش می‌دهند؟
• آیا Pluginهای قدیمی XML Processor به‌روز هستند؟

هدف این Checklist غیرفعال کردن کورکورانه قابلیت‌های WordPress نیست؛ بلکه شناسایی Data Flow واقعی XML و Hardening همان مسیرهاست.

چه زمانی تست XXE ضروری‌تر است؟

اولویت بررسی بیشتر است اگر Application:

XML را از User Upload دریافت می‌کند.

SOAP API عمومی دارد.

SAML پردازش می‌کند.

فایل SVG Upload می‌پذیرد.

XML از Vendor دریافت می‌کند.

Document Converter دارد.

از Java XML API قدیمی استفاده می‌کند.

Legacy .NET دارد.

PHP/libxml قدیمی دارد.

Importer سفارشی دارد.

به Internal Network دسترسی گسترده دارد.

این موارد لزوماً Vulnerable نیستند؛ فقط سطح بررسی باید بالاتر باشد.

آیا XXE فقط مشکل Backend است؟

تقریباً همیشه Parser آسیب‌پذیر در Server یا Backend Context اهمیت امنیتی اصلی دارد.

Browserهای مدرن XML را در Context متفاوتی پردازش می‌کنند و Security Boundaryهای خود را دارند.

اما Applicationهای Desktop، Mobile یا Client-side Native نیز اگر XML خارجی با Parser قدرتمند پردازش کنند می‌توانند XXE-like Risk داشته باشند.

CWE-611 محدود به Web Server نیست.

چگونه XXE را اولویت‌بندی کنیم؟

Severity باید براساس Impact واقعی تعیین شود.

Risk پایین‌تر

Parser خارجی Entity را Attempt می‌کند ولی:

Sandbox شده،

Network ندارد،

File System محدود است،

Response Data را نمایش نمی‌دهد.

Risk بالاتر

Parser:

با Privilege بالا اجرا می‌شود،

به File System حساس دسترسی دارد،

به Internal Network متصل است،

Output Entity را به User بازمی‌گرداند.

Severity باید براساس Context باشد، نه صرفاً وجود DTD.

آیا حذف XML بهترین راه است؟

گاهی بله.

اگر Application هیچ Requirement واقعی برای XML ندارد و JSON تمام نیازها را پوشش می‌دهد، حذف Parser XML Attack Surface را کاهش می‌دهد.

اما مهاجرت باید با Compatibility و Business Requirement بررسی شود.

در سیستم Enterprise، XML ممکن است هنوز Requirement اساسی باشد.

هدف Security نابود کردن Technology نیست؛ استفاده حداقلی و امن از آن است.

راهکار مرحله‌به‌مرحله برای یک پروژه موجود

مرحله اول: پیدا کردن XML Parserها

Codebase و Dependencyها را Inventory کنید.

مرحله دوم: مشخص کردن Data Source

هر Parser چه Dataیی دریافت می‌کند؟

User؟

Partner؟

File؟

Internal System؟

مرحله سوم: مشخص کردن Featureهای لازم

آیا DTD واقعاً نیاز است؟

External Schema چطور؟

مرحله چهارم: Disable کردن Featureهای غیرضروری

کمترین Capability ممکن.

مرحله پنجم: محدود کردن Resource Access

File و Network.

مرحله ششم: اضافه کردن Test

DTD و External Resource نباید Resolve شوند.

مرحله هفتم: بررسی Infrastructure

Container، Firewall، IAM و Egress.

مرحله هشتم: Monitoring

Parser Error و Unexpected Outbound Connection.

Security Review برای Legacy Application

در Application قدیمی ممکن است تغییر Parser رفتار Business را بشکند.

به همین دلیل Hardening باید مرحله‌ای باشد.

ابتدا در Staging:

XML Sampleهای واقعی جمع‌آوری شوند.

Dependencyهای DTD شناسایی شوند.

External Referenceهای قانونی مشخص شوند.

سپس Allowlist ایجاد شود.

بعد Parser Config سخت‌گیرانه شود.

در نهایت Regression Test اجرا شود.

هدف ایجاد Security بدون شکستن Functionality است.

سوالات متداول درباره XXE

XXE چیست؟

XXE یا XML External Entity آسیب‌پذیری‌ای است که وقتی XML Parser ورودی غیرقابل اعتماد را با امکان Resolve کردن Entityهای خارجی پردازش می‌کند ایجاد می‌شود. این ضعف با CWE-611 شناخته می‌شود.

XXE مخفف چیست؟

XXE مخفف XML External Entity است.

XXE چه خطراتی دارد؟

بسته به Configuration می‌تواند به File Disclosure، SSRF، Network Interaction و Denial of Service منجر شود.

XXE در OWASP Top 10 2025 کجاست؟

در OWASP Top 10:2025، CWE-611 مربوط به XXE در دسته A02:2025 Security Misconfiguration قرار دارد.

بهترین روش جلوگیری از XXE چیست؟

اگر DTD نیاز نیست، OWASP توصیه می‌کند DTD و External Entity Processing کاملاً غیرفعال شوند.

آیا XML به‌خودی‌خود ناامن است؟

خیر. Risk از Parser Configuration، Featureهای فعال و Trust کردن ورودی ناشی می‌شود.

DTD چیست؟

DTD ساختار و Ruleهای XML Document را تعریف می‌کند و می‌تواند Entity نیز تعریف کند. DTD می‌تواند Inline یا External باشد.

External Entity چیست؟

Entityای است که مقدار آن از Resource خارج از XML Document دریافت می‌شود.

XXE چگونه باعث SSRF می‌شود؟

اگر Parser اجازه Load کردن URL خارجی داشته باشد، XML ممکن است باعث شود Server به Destination دیگری Request ارسال کند.

آیا XXE می‌تواند فایل Server را بخواند؟

در بعضی Parserها و Configurationهای ناامن، External Entity می‌تواند به Resource محلی دسترسی پیدا کند. MITRE این مورد را از Consequenceهای CWE-611 می‌داند.

Blind XXE چیست؟

حالتی است که External Entity پردازش می‌شود ولی Data مستقیماً در Response User ظاهر نمی‌شود.

XML Bomb چیست؟

نوعی Abuse از Entity Expansion یا ساختار پیچیده XML برای مصرف بیش از حد Resource است. این موضوع با CWE-776 مرتبط است و باید در کنار XXE Prevention بررسی شود.

آیا WAF برای جلوگیری از XXE کافی است؟

خیر. Fix اصلی باید Parser Configuration امن باشد. WAF فقط می‌تواند Layer تکمیلی باشد.

آیا JSON XXE دارد؟

JSON مفاهیم DTD و External Entity XML را ندارد؛ بنابراین XXE کلاسیک در JSON وجود ندارد. اما JSON Vulnerabilityهای دیگری می‌تواند داشته باشد.

آیا PHP 8 در برابر XXE امن است؟

PHP 8 همراه libxml جدید Defaultهای امن‌تری دارد و libxml_disable_entity_loader() نیز Deprecated شده است؛ با این حال Parser Flagها و Library Configuration همچنان باید بررسی شوند. خصوصاً فعال کردن Entity Substitution می‌تواند Risk ایجاد کند.

LIBXML_NOENT چیست؟

یک Flag در libxml برای Entity Substitution است. PHP Manual هشدار می‌دهد فعال کردن آن می‌تواند XXE Risk ایجاد کند.

LIBXML_NO_XXE چیست؟

در PHP 8.4 همراه libxml 2.13 یا جدیدتر Constantی برای جلوگیری از External Entity در شرایط Entity Substitution فراهم شده است.

در .NET چگونه XXE را کاهش دهیم؟

برای XML غیرقابل اعتماد، DTD Processing را Prohibit یا Ignore کنید و External Resolver را در صورت عدم نیاز غیرفعال کنید. Microsoft این Controls را در XmlReaderSettings مستند کرده است.

Java چگونه در برابر XXE محافظت می‌شود؟

به Parser مورد استفاده بستگی دارد. معمولاً DTD و External Entity باید غیرفعال و External Access Restrictions صریحاً تنظیم شوند. Oracle نیز محدود کردن External Access را برای XML Security ضروری می‌داند.

آیا WordPress ممکن است با XML کار کند؟

بله. WordPress XML-RPC API دارد و WXR نیز XML-based است؛ همچنین Pluginهای مختلف ممکن است XML پردازش کنند. این موضوع به‌تنهایی به معنی Vulnerability نیست و Parser واقعی باید بررسی شود.

آیا غیرفعال کردن XML-RPC جلوی XXE را می‌گیرد؟

XXE باید در Parser آسیب‌پذیر اصلاح شود. غیرفعال کردن XML-RPC فقط در صورتی مرتبط است که آن مسیر مشخص در Threat Model شما نقش داشته باشد.

آیا SVG می‌تواند به XXE مرتبط باشد؟

SVG یک Format XML-based است. هر Systemی که SVG غیرقابل اعتماد را Parse می‌کند باید XML Parser و سایر Security Riskهای SVG را بررسی کند.

آیا Schema Validation جلوی XXE را می‌گیرد؟

نه الزاماً. XML Schema Processing نیز می‌تواند External Resource داشته باشد. Resolver و External Access باید جداگانه محدود شوند.

آیا XXE فقط در سیستم‌های قدیمی وجود دارد؟

خیر، ولی Runtimeهای جدید معمولاً Defaultهای امن‌تری دارند. Custom Configuration یا Library Third-party همچنان می‌تواند External Entity را فعال کند.

آیا می‌توان XXE را با Regex جلوگیری کرد؟

بهتر است نه. Security باید در XML Parser Configuration enforce شود.

چه چیزی را باید در تست XXE بررسی کنیم؟

پذیرش DTD، External Entity Resolution، Network Access، File Access، Error Handling، Resource Limit و Parser Version باید بررسی شوند.

جمع‌بندی

XXE یا XML External Entity نمونه‌ای روشن از آسیب‌پذیری‌هایی است که نه به دلیل یک Algorithm پیچیده، بلکه به دلیل فعال بودن Featureهایی بیش از نیاز Application ایجاد می‌شوند.

XML در بسیاری از سیستم‌ها Formatی قانونی و مفید است.

مشکل زمانی ایجاد می‌شود که Document غیرقابل اعتماد بتواند به Parser بگوید Resourceی خارج از Document را Load کند و Parser نیز بدون Restriction آن درخواست را اجرا کند.

در این حالت XML Parser می‌تواند از یک Component ساده برای خواندن Data به Gateway ناخواسته‌ای برای دسترسی به File System یا Network تبدیل شود.

پیامد XXE بسته به محیط ممکن است شامل:

افشای اطلاعات،

دسترسی به فایل،

SSRF،

Network Discovery،

Resource Exhaustion

و Denial of Service باشد.

CWE این ضعف را با شناسه 611 ثبت کرده و OWASP Top 10:2025 آن را در دسته A02 Security Misconfiguration قرار داده است.

مهم‌ترین راهکار دفاعی این است که اگر Application به DTD نیاز ندارد، آن را غیرفعال کنید.

External Entity Resolution نباید فقط به این دلیل فعال باشد که XML Parser از آن پشتیبانی می‌کند.

همین اصل درباره:

External Schema،

XInclude،

Network Resource،

و سایر قابلیت‌های Parser

نیز صدق می‌کند.

در Java باید Configuration Parser-specific بررسی شود و External Access به‌صورت صریح Restrict شود.

در .NET استفاده امن از XmlReaderSettings، محدود کردن DTD Processing و Resolver اهمیت دارد.

در PHP نیز اگرچه نسخه‌های جدید libxml Entity Loading را به‌صورت پیش‌فرض محدودتر کرده‌اند، Flagهایی مانند LIBXML_NOENT و Version واقعی libxml همچنان باید بررسی شوند.

همزمان نباید تنها به Parser اعتماد کرد.

Process Application باید با Least Privilege اجرا شود.

Server Egress باید محدود باشد.

Secretها از Web Process جدا شوند.

Container و Network Segmentation باید Blast Radius را کاهش دهند.

Input Size و Complexity باید محدود شوند.

Errorها نباید Internal Path یا Parser Detail را نمایش دهند.

و Security Test باید به‌طور خودکار بررسی کند که External Resource دیگر Resolve نمی‌شود.

در سایت‌های WordPress نیز تمرکز باید روی Data Flow واقعی باشد.

XML-RPC، WXR، SVG، SOAP Integration و Pluginهای Import ممکن است XML را وارد Application کنند، اما وجود XML به‌تنهایی Vulnerability نیست.

سؤال اصلی این است:

«کدام Parser، کدام XML را، با چه تنظیماتی و با چه سطح دسترسی پردازش می‌کند؟»

اگر پاسخ این سؤال مستند و کنترل‌شده باشد، XXE به‌شدت قابل پیشگیری است.

اگر Application نمی‌داند چه Parserهایی دارد، چه Featureهایی فعال هستند و XML از کجا وارد سیستم می‌شود، Risk اصلی حتی قبل از اولین حمله ایجاد شده است.

امنیت XXE در نهایت به یک اصل ساده برمی‌گردد:

به XML غیرقابل اعتماد اجازه ندهید درباره فایل‌ها، شبکه یا Resourceهای خارج از Document برای Server تصمیم بگیرد.