XXE: XML external entity
- Transfer
In this article we will explain what the injection of external XML entities is, describe some common examples, explain how to find and use different types of XXE injections, and also generalize how to prevent attacks with their help.
What is an injection of external XML entities?
Injecting external XML entities (also known as XXE) is a web security vulnerability that could allow an attacker to interfere with the processing of XML data by an application. It often allows an attacker to view files in the application server file system and interact with any server or external systems that the application itself can access.
In some situations, an attacker could leverage a XXE attack to compromise a core server or other internal infrastructure by exploiting the XXE vulnerability to perform server-side request forgery attacks (SSRFs).
How do XXE vulnerabilities arise?
Some applications use the XML format to transfer data between the browser and the server. Applications that do this almost always use the standard library or platform APIs to process XML data on the server. The XXE vulnerabilities arise because the XML specification contains various potentially dangerous functions, and standard parsers support these functions, even if they are not usually used by the application.
XML external entities are a type of custom XML entity whose specific values are loaded from the DTD files in which they are written. External entities are particularly interesting from a security point of view, because they allow you to define an entity based on the contents of a file path or URL.
What types of XXE attacks exist?
- Using XXE to extract files, where an external entity that includes the contents of the file is defined and returned in the application response.
- Using XXE to perform SSRF attacks, where an external entity is determined based on the URL of the internal system.
- The use of blind extraction of XXE information on the control channel, where sensitive data is transferred from the application server to the system controlled by the attacker.
- Using blind XXE to return data from error messages when an attacker can trigger an error message containing the necessary information.
- Using XXE to extract files
To perform an attack of the form XXE injection, which extracts an arbitrary file from the server file system, you must modify the XML presented in one of two ways:
- Enter (or modify) the DOCTYPE element that defines the external entity containing the file path.
- Change the value of the data in XML returned in the application response to use a specific external entity.
For example, suppose a shopping application checks the quantity of product stocks by sending the following XML to the server:
<?xml version="1.0" encoding="UTF-8"?><stockCheck><productId>381</productId></stockCheck>
Приложение не защищено от атак XXE, поэтому можно использовать уязвимость XXE для получения файла /etc/passwd, отправив следующую конструкцию XXE:
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]><stockCheck><productId>&xxe;</productId></stockCheck>
This XXE structure defines an external entity & xxe, whose value is the contents of the / etc / passwd file, and uses an entity with the value productId. This causes the application response to include the contents of the file:
Invalid product ID: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...
In the case of real XXE vulnerabilities, there will often be a large number of data values in the submitted XML, any of which can be used in the application response. For systematic testing of XXE vulnerabilities, as a rule, it will be necessary to check each data node in XML individually, using a specific entity and see the status of the response.
In addition to extracting sensitive data, another way to use XXE attacks is to use them to fake server-side requests (SSRF).
This is a potentially serious vulnerability; with its help, the server application can be used to execute HTTP requests to any URL that the server can access.
To use the XXE vulnerability to perform an SSRF attack, you must define an external XML entity using the URL you want to access and use a specific entity with a data value. If you can use a specific entity with the data value that is returned in the application response, you can view the response from the URL in the application response and thus get two-way interaction with the server system. If not, then you can only perform blind SSRF attacks (which can also have critical consequences).
In the following example using XXE, an external entity forces the server to execute an internal HTTP request to the internal system within the system infrastructure:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>
Using XXE to perform SSRF attacks:
Many types of XXE vulnerabilities are blind. This means that the application does not return the value of any specific external entities in its responses, and therefore direct search of files on the server side is impossible.
XXE blind vulnerabilities can still be detected and exploited, but more advanced methods are required. Sometimes you can use external methods to search for vulnerabilities and use them to exfiltrate data. It can also sometimes cause XML parsing errors that result in the disclosure of sensitive data in error messages.
Search and use of blind vulnerabilities XXE:
The ability to attack with an XXE injection is obvious in many cases, since the normal HTTP traffic of the application includes requests containing XML data. In other cases, the opportunity for attack is less noticeable. However, if you look in the right places, you will find the opportunity to attack XXE in queries that do not contain XML.
XInclude Attacks
Some applications receive data sent by the client, insert it on the server side into an XML document, and then parse it. An example of this is when client data is placed in a backend SOAP request, which is then processed by the backend SOAP service.
In this case, you cannot run the classic XXE attack because you are not in control of the whole XML document and therefore cannot determine or modify the DOCTYPE element. However, you can use XInclude instead. XInclude is part of the XML specification, which allows you to create an XML document from nested documents. You can place an XInclude attack on any data value in an XML document, so the attack can be performed in situations where you control only one data element placed in an XML document on the server side.
To perform an XInclude attack, you must reference the XInclude namespace and specify the path to the file you want to involve. For example:
<fooxmlns:xi="http://www.w3.org/2001/XInclude"><xi:includeparse="text"href="file:///etc/passwd"/></foo>
Some applications allow users to upload files, which are then processed on the server side. Some common file formats use XML or contain XML subcomponents. Examples of XML formats are Office document formats such as DOCX and image formats such as SVG.
For example, an application may allow users to upload images and process or verify them on the server after downloading. Even if the application expects to receive PNG or JPEG format, the image processing library used may support SVG images. Because the SVG format uses XML, an attacker could send a malicious SVG image and thus be able to attack XXE vulnerabilities.
Using XXE by uploading image files:
Most POST requests use the default content type created by HTML forms, such as application / x-www-form-urlencoded. Some sites expect to receive requests in this format, but allow other types of content, including XML.
For example, if a regular request contains the following:
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>
If your application accepts requests containing XML in the body of the message and parses the content as XML, you can get the opportunity to attack XXE by simply reformatting the requests to use the XML format.
How to find and check XXE vulnerabilities
The vast majority of XXE vulnerabilities can be quickly and reliably found using the Burp Suite web vulnerability scanner.
- Manual testing of XXE vulnerabilities typically includes:
- Testing file extraction by defining an external entity based on a known operating system file and using this object in the data returned in the application response.
- Testing XXE blind vulnerabilities by defining an external entity based on the URL of the system you are managing and monitoring the interaction with this system. The Burp Collaborator client is ideal for this purpose.
- Testing for vulnerable inclusion of non-XML user data in an XML server document using an XInclude attack to attempt to obtain a known operating system file.
How to prevent XXE vulnerabilities
Almost all XXE vulnerabilities arise due to the fact that the XML application parsing library supports potentially dangerous XML functions that the application does not need or are not intended to use. The easiest and most effective way to prevent XXE attacks is to disable these features.
As a rule, it is enough to disable the resolution of external entities and disable XInclude support. This can usually be done using configuration options or programmatically overriding the default behavior. For more information about disabling unnecessary features, see the XML or API parsing library documentation.
You can use specialized laboratories as a training ground for testing the skills of exploiting such vulnerabilities .
The latest dual-processor configurations of dedicated servers with 2019 Intel Scalable processors are available on DEDIC.SH :
- 2x Xeon Silver 4214 - a total of 24 cores
- 2x Xeon Gold 5218 - a total of 32 cores
- 2x Xeon Gold 6240 - configuration with 36 cores.
The cost of a server with two Xeon Silver 4214 - from 15210 rubles / month.
We are also ready to collect any configuration for you - write to us !
If large powers of a dedicated server are not required - VDS from 150 rubles / month is what you need!