XXE – iOS secure coding


iOS includes the C/C++ libxml2 library described in C/C++ secure coding examples, so that guidance applies if you are using libxml2 directly. However, the version of libxml2 provided up through iOS6 is prior to version 2.9 of libxml2 (which protects against XXE by default).


iOS also provides an NSXMLDocument type, which is built on top of libxml2. However, NSXMLDocument provides some additional protections against XXE that aren’t available in libxml2 directly:

iOS4 and earlier: All external entities are loaded by default.
iOS5 and later: Only entities that don’t require network access are loaded. (which is safer)

However, to completely disable XXE in an NSXMLDocument in any version of iOS you simply specify NSXMLNodeLoadExternalEntitiesNever when creating the NSXMLDocument.


XXE – PHP secure coding

The following should be set when using the default PHP XML parser in order to prevent XXE:

XXE – Java secure coding

Java applications using XML libraries are particularly vulnerable to XXE because the default settings for most Java XML parsers is to have XXE enabled. To use these parsers safely, you have to explicitly disable XXE in the parser you use. The following describes how to disable XXE in the most commonly used XML parsers for Java.

JAXP DocumentBuilderFactory

import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

try {
   dbf.setFeature("http://apache.org/xml/features/allow-java-encodings", true);
catch (ParserConfigurationException e) {
   System.err.println("could not set parser feature");



import javax.xml.parsers.SAXParser;
import org.xml.sax.SAXException;
import org.xml.sax.XMLReader;
SAXParser parser = /* created from SAXParserFactory */;
XMLReader reader = parser.getXMLReader();
try {
   reader.setFeature("http://xml.org/sax/features/allow-java-encodings", true);
catch (SAXException e) {
   System.err.println("could not set parser feature");



To protect a Java XMLReader from XXE, do this:

XMLReader spf = XMLReaderFactory.createXMLReader();
spf.setFeature(“http://xml.org/sax/features/external-general-entities”, false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

more libraries and references:

XXE – C/C++ secure coding


The Enum xmlParserOption should not have the following options defined:

XML_PARSE_NOENT // Expands entities and substitutes them with replacement text
XML_PARSE_DTDLOAD // Load the external DTD

Note: starting with libxml2 version 2.9, XXE has been disabled by default as committed by the following patch: http://git.gnome.org/browse/libxml2/commit/?id=4629ee02ac649c27f9c0cf98ba017c6b5526070f.


XXE Injection


Different client technologies such as Web, Mobile Cloud and more – sends messages to business applications using XML. In order for the application to work with these self-descriptive XML messages, it has to parse them and check that the format is correct.

XML External Entity (XXE) attacks occurs when the attacker declares an external entity inside an XML message that is sent to the server, and uses it in the body of the XML message. When the XML parser receives the XML message, it notices the reference to the entity and looks for the value of the entity to replace the entity’s reference with the actual value.

External entity meant to be declared in an XML document, to reference external source to be fetched and be used as the content of the entity – this behavior leads to scenarios where the attacker can inject “SYSTEM” identifier which tells the XML parser that the value of the entity is actually a file path on the local server.

The result will allow the attacker to read files located on the application server such as “/etc/passwd” or “c:\windows\win.ini”
Same goes for Internal URLs in an organization – the attacker will be able to extract the content of these URLs using XXE attack assuming he has additional info about internal servers.

See how to fix it!

Read more

Embedded Ajax Brute-Force Tool

There are a few cases when preparing a PoC for brute-force attack on the login page can be complicated. It is no longer uncommon to find a login form based on web sockets, or which implements some sort of client-side encryption with JavaScript. In these cases, configuring a brute-attack quickly with a middle proxy (e.g. Burp’s Intruder) is not possible. It also happens that clients request for the penetration testings to be conducted on a specific machine, without access to common attacking tools.

For these reasons, I wrote a very minimalistic brute-force tool that runs inside the browser (the source code, following this post, has to be copy-pasted into browser’s JavaScript console).

Read more