Xml External Entities on Azure

Xml External Entities (XXE) vulnerabilities in Azure environments typically arise when XML parsers process untrusted input without proper configuration. In Azure applications, this often occurs in Azure Functions, Azure App Services, and custom APIs that handle XML payloads.

The most common attack vector involves an attacker crafting a malicious XML document containing an external entity reference. When the parser processes this XML, it may attempt to fetch the referenced resource, potentially exposing sensitive files or enabling server-side request forgery (SSRF).

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >
]>
<foo>&xxe;</foo>

In Azure Functions, XXE vulnerabilities often appear when using libraries like xml2js or xmldom without disabling external entity processing. Consider this vulnerable Azure Function:

const xml2js = require('xml2js');

module.exports = async function (context, req) {
  const parser = new xml2js.Parser();
  
  try {
    const xmlData = await parser.parseStringPromise(req.body);
    context.res = { body: xmlData };
  } catch (err) {
    context.res = { status: 400, body: err.message };
  }
};

This code is vulnerable because it doesn't disable external entities. An attacker could exploit this to read files from the Azure Function's file system or make outbound requests to internal services.

Azure App Services face similar risks when hosting applications that process XML. For example, a .NET Core API hosted on Azure App Service might use XDocument without proper configuration:

public IActionResult ProcessXml([FromBody] string xml)
{
    var doc = XDocument.Parse(xml); // Vulnerable - allows external entities
    return Ok(doc);
}

Azure Logic Apps that process XML payloads can also be vulnerable if custom connectors or code actions don't properly sanitize XML input. When integrating with Azure Service Bus or Event Grid, XML processing without validation can expose the entire Azure integration pipeline.

Storage accounts in Azure can be indirectly affected when XXE vulnerabilities in web applications allow attackers to access storage account keys or SAS tokens stored in configuration files. This is particularly concerning when applications use Azure Key Vault for secrets management but still process XML without proper security controls.

Detecting XXE vulnerabilities in Azure requires both static code analysis and dynamic scanning. For static analysis, Azure DevOps and GitHub Actions can integrate security scanning tools that examine XML parsing code patterns.

middleBrick provides Azure-specific XXE detection through its black-box scanning approach. When scanning an Azure Function or App Service endpoint, middleBrick tests for XXE by sending specially crafted XML payloads and analyzing the responses. The scanner looks for indicators like:

• Time delays that suggest external entity resolution
• HTTP 200 responses containing unexpected data
• Service errors that reveal internal file paths
• Network activity patterns indicating outbound requests
• Memory usage spikes during XML processing

For Azure Functions specifically, you can use the Azure Functions Core Tools to test locally:

func start --verbose

# Test with XXE payload
curl -X POST http://localhost:7071/api/ProcessXml \
  -H "Content-Type: application/xml" \
  -d "@xxe_payload.xml"

Azure Application Insights can help detect XXE exploitation in production by monitoring for unusual patterns:

• Sudden increases in XML payload processing
• Unexpected outbound network connections from your Azure services
• Files being accessed outside normal application patterns
• CPU spikes during XML processing

For .NET applications on Azure, use the OWASP .NET Secure Coding Guidelines to audit XML processing code. Look for these vulnerable patterns:

// Vulnerable - allows external entities
XmlReader.Create(reader, settings); // without proper XmlReaderSettings

Azure Security Center can detect misconfigurations that might enable XXE attacks, such as overly permissive network access or exposed management endpoints. Enable Just-In-Time (JIT) VM access and network security groups to reduce the attack surface.

The middleBrick CLI provides a quick way to scan Azure endpoints:

npm install -g middlebrick
middlebrick scan https://yourapp.azurewebsites.net/api/endpoint

This will test for XXE vulnerabilities along with other API security issues, providing a risk score and specific findings about external entity processing vulnerabilities.

Remediating XXE vulnerabilities in Azure requires configuring XML parsers to disable external entity processing. For Node.js applications in Azure Functions or App Services, use the xml2js library with secure settings:

const xml2js = require('xml2js');

const parser = new xml2js.Parser({
  strict: true,
  trim: true,
  normalize: true,
  explicitArray: false,
  mergeAttrs: true,
  validator: (xml) => {
    // Custom validation to prevent external entities
    if (xml.includes('

For Azure Functions using Python, use the defusedxml library which provides secure XML parsing:

from defusedxml.ElementTree import parse

def process_xml(xml_string):
    try:
        tree = parse(xml_string)
        return tree
    except Exception as e:
        raise ValueError(f'XML processing error: {e}')

.NET applications on Azure App Service should use XmlReaderSettings with external entities disabled:

public static class XmlSecurity
{
    public static XmlReader CreateSecureXmlReader(string xml)
    {
        var settings = new XmlReaderSettings
        {
            DtdProcessing = DtdProcessing.Prohibit,
            MaxCharactersFromEntities = 1024,
            XmlResolver = null
        };
        
        using var stringReader = new StringReader(xml);
        return XmlReader.Create(stringReader, settings);
    }
}

For Azure Logic Apps that process XML, use the built-in XML validation actions with schema validation enabled. Create XML schemas that explicitly disallow external entities:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified"
           attributeFormDefault="unqualified"
           blockDefault="#all">
    <xs:element name="root" type="xs:string"/>
</xs:schema>

Azure API Management can add an XXE protection policy to all backend APIs:

<policies>
    <!-- Validate XML before forwarding -->
    <inbound>
        <choose>
            <when condition="context.Request.ContentType == 'application/xml'">
                <xml-to-json apply="preserve-entities">
                    <!-- Custom validation here -->
                </xml-to-json>
            </when>
        </choose>
    </inbound>
</policies>

Implement Azure Key Vault integration for storing sensitive configuration data instead of keeping it in files that might be exposed through XXE. Use Managed Identity to access Key Vault without storing credentials in your application.

For Azure Kubernetes Service (AKS) deployments, add XXE scanning to your CI/CD pipeline using the middleBrick GitHub Action:

name: API Security Scan

on: [push, pull_request]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run middleBrick Scan
        uses: middlebrick/middlebrick-action@v1
        with:
          target_url: ${{ secrets.AZURE_API_ENDPOINT }}
          fail_below_score: B
        env:
          MIDDLEBRICK_API_KEY: ${{ secrets.MIDDLEBRICK_API_KEY }}

Finally, implement Azure Monitor alerts for XML processing anomalies and configure Azure Policy to enforce secure XML processing standards across your Azure subscription.