HIGH xml external entitiesaspnetbasic auth

Xml External Entities in Aspnet with Basic Auth

Xml External Entities in Aspnet with Basic Auth — how this specific combination creates or exposes the vulnerability

XML External Entity (XXE) injection occurs when an XML parser processes external entity references embedded in XML data. In ASP.NET applications that accept XML payloads—such as SOAP endpoints or legacy configuration parsers—enabling external entity resolution allows an attacker to reference local files, trigger SSRF, or cause denial of service. When Basic Authentication is used, credentials are transmitted in the Authorization header as a base64-encoded string (e.g., Authorization: Basic dXNlcjpwYXNz). While Basic Auth itself does not directly affect XML parsing behavior, it influences how the attack surface is exposed and how findings are contextualized during a scan.

middleBrick scans unauthenticated attack surfaces, but when Basic Auth is present and accepted without additional protections, the scanner can include the header in requests. If the endpoint parses XML unsafely—such as using XmlReader with XmlReaderSettings that has ProhibitDtd set to false or uses an older XmlTextReader—an attacker-supplied XML body can define entities that read files like C:\windows\win.ini or trigger HTTP requests to internal services. A finding may be reported under Data Exposure and Input Validation, noting that credentials were transmitted in clear-text encoding and that the endpoint resolved external entities.

Consider an ASP.NET Core controller that accepts XML via HttpRequest.Body without disabling DTD processing:

// Example of vulnerable XML parsing in ASP.NET Core
[HttpPost("legacy")]
public IActionResult ParseLegacyXml()
{
    using var reader = XmlReader.Create(Request.Body, new XmlReaderSettings { DtdProcessing = DtdProcessing.Parse });
    var doc = XDocument.Load(reader);
    // Process doc…
    return Ok();
}

An attacker can send a POST with Basic Auth header and a body like:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
               <!ENTITY xxe SYSTEM "file:///C:/windows/win.ini" >]>>
<foo><bar>&xxe;</bar></foo>

If the parser resolves the external entity, the response may inadvertently include file content or server-side errors that reveal path information. Because Basic Auth transmits credentials in every request, repeated probes can expose whether authentication is enforced before parsing, which affects risk scoring. middleBrick’s checks for Input Validation, Data Exposure, and SSRF interact here: unsafe XML configurations plus the presence of Basic Auth increase the severity guidance, emphasizing that authentication headers do not protect against malformed or malicious XML.

In OpenAPI/Swagger analyses, middleBrick cross-references spec definitions with runtime behavior. If the spec describes XML consumption (e.g., consumes: application/xml) and the runtime allows external entity processing, a prioritized finding will recommend hardening XML parsers and removing DTD processing. The presence of Basic Auth does not mitigate this; it simply means credentials are consistently attached to each request, making session hijacking or credential leakage via error messages more impactful.

Basic Auth-Specific Remediation in Aspnet — concrete code fixes

Remediation focuses on two areas: preventing unsafe XML processing and ensuring that Basic Authentication is used securely. For XML, disable DTD processing and external entity resolution entirely. For Basic Auth, avoid sending credentials in clear-text encoding where possible and ensure transport-layer encryption is enforced.

Secure XML Parsing in ASP.NET Core

Use XmlReader with settings that prohibit DTDs and external entities. For XDocument, create a secure reader and avoid passing raw Request.Body directly to parsers that inherit insecure defaults.

// Secure XML parsing in ASP.NET Core
[HttpPost("secure")]
public IActionResult ParseSecureXml()
{
    var settings = new XmlReaderSettings
    {
        DtdProcessing = DtdProcessing.Prohibit,
        XmlResolver = null // Prevents external network requests
    };
    using var reader = XmlReader.Create(Request.Body, settings);
    var doc = XDocument.Load(reader);
    // Process doc…
    return Ok();
}

If you must work with legacy APIs, consider validating and transforming XML to JSON before parsing, and never enable ProhibitDtd implicitly via older constructors that default to allowing DTDs.

Securing Basic Authentication Headers

Basic Auth should only be used over HTTPS. In ASP.NET Core, you can enforce HTTPS and inspect the Authorization header to ensure credentials are present and properly formatted. Do not rely on Basic Auth alone for authorization; treat it as transport-level authentication only.

// Enforce HTTPS and validate Basic Auth format in middleware
app.Use(async (context, next)
{
    if (context.Request.IsHttps)
    {
        if (context.Request.Headers.ContainsKey("Authorization"))
        {
            var authHeader = context.Request.Headers["Authorization"].ToString();
            if (authHeader.StartsWith("Basic ", StringComparison.OrdinalIgnoreCase))
            {
                // Optionally validate token format or reject if missing
                await next();
                return;
            }
            context.Response.StatusCode = 400;
            await context.Response.WriteAsync("Invalid Authorization header");
            return;
        }
        context.Response.StatusCode = 401;
        await context.Response.WriteAsync("Authorization header required");
        return;
    }
    context.Response.StatusCode = 400;
    await context.Response.WriteAsync("HTTPS required");
});

For production, prefer token-based authentication (e.g., Bearer tokens) or integrated Windows authentication where feasible. If you must keep Basic Auth, rotate credentials frequently and monitor for repeated failed authentication attempts, which may indicate probing for XXE or other injection flaws.

middleBrick’s GitHub Action can be added to CI/CD pipelines to fail builds if risk scores drop below your threshold, ensuring that endpoints accepting XML with Basic Auth are continuously monitored. The CLI tool allows you to scan specific URLs with headers included, and the Web Dashboard tracks findings over time so you can verify remediation.

Frequently Asked Questions

Does using Basic Auth make XXE less exploitable?
No. Basic Auth transmits credentials in base64 encoding and does not prevent an XML parser from resolving external entities. Secure XML parsing requires disabling DTDs and external resolvers regardless of authentication method.
Can middleBrick detect XXE in APIs using Basic Auth?
Yes. When you provide the Authorization header via the CLI or dashboard, middleBrick includes it in requests and can identify unsafe XML processing and data exposure findings. Note that findings highlight risks and provide remediation guidance; they do not automatically fix configurations.