Xml Bomb in Adonisjs
How Xml Bomb Manifests in Adonisjs
An XML bomb is a maliciously crafted XML document that exploits XML parsers to cause resource exhaustion through entity expansion. In Adonisjs applications, XML parsing typically occurs when processing SOAP requests, handling legacy XML-based integrations, or when using third-party modules that parse XML without strict limits.
In Adonisjs, XML parsing often happens in three primary contexts:
- When using
HttpContextto parse incoming XML payloads for REST endpoints that accept application/xml content-type - When integrating with legacy services that communicate via XML (e.g., SOAP-based payment gateways)
- Through AdonisJS community packages that parse XML for configuration or data interchange
Consider a vulnerable endpoint in AdonisJS that processes XML input:
// routes/api.js
Route.post('xml-submit', 'XmlController.handle')
// app/Controllers/Http/XmlController.js
const { parse } = require('xml2js')
class XmlController {
async submit ({ request }) {
const xmlData = await request.getBody()
const parsed = parse(xmlData, { explicitArray: false })
// Process parsed data
}
}
module.exports = XmlController
If an attacker sends a crafted XML payload like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>
<request>
<input>&xxe;</input>
</request>
</root>
The XML bomb expands &xxe; to the contents of /etc/passwd, potentially causing denial of service through excessive memory consumption or file exposure. In Adonisjs specifically, this vulnerability appears when:
- Third-party modules like
xml2jsorxml-parserare used without configuration limits - SOAP service integrations lack input validation
- File processing endpoints accept XML without entity expansion restrictions
AdonisJS does not provide built-in XML parsing safeguards, making it reliant on developer implementation or external middleware to prevent these attacks.
Adonisjs-Specific Detection
middleBrick detects XML bomb vulnerabilities in AdonisJS applications through its black-box scanning of API endpoints. When scanning an endpoint that accepts XML input, middleBrick performs the following checks:
- Submits crafted XML payloads containing general entity references (GEs) and parameter entity references (PEs)
- Measures response time anomalies and memory consumption patterns indicative of XML bomb processing
- Checks for lack of XML parser configuration limits in observed request handling
For example, when scanning an AdonisJS endpoint that uses xml2js without parser options like disableEntityAccess: true, middleBrick identifies the vulnerability by sending a test payload containing an expanded entity reference and monitoring for unexpected behavior.
During a scan, middleBrick also analyzes the OpenAPI specification if available. If the endpoint is documented as accepting application/xml without security requirements, it flags this as a high-risk configuration.
The scanner maps findings to the OWASP API Top 10 category A01:2023 - Broken Object Level Authorization when the XML processing leads to unauthorized data exposure, but specifically identifies it under A04:2023 - Unrestricted Mass Assignment when XML entity expansion enables injection attacks.
Adonisjs-Specific Remediation
To remediate XML bomb vulnerabilities in AdonisJS, developers must explicitly restrict XML parser behavior. The recommended approach uses xml2js with strict configuration:
const { parse } = require('xml2js')
// Safe parsing configuration
const safeParse = (xmlData) => {
return new Promise((resolve, reject) => {
parse(xmlData, {
explicitArray: false,
enableCdata: false,
ignoreAttrs: false,
attrNameProcessors: [],
tagNameProcessors: [],
// Critical: disable entity access
mergeAttrs: false,
normalize: false,
trim: true,
// Security-critical configuration
explicitCharkey: false,
charsets: true,
preserveChildrenOrder: true,
// Prevent XXE attacks
explicitArray: false,
// Disable DTD processing
parserOptions: {
entities: false,
resolveEntity: null
}
}, (err, result) => {
if (err) reject(err)
else resolve(result)
})
})
}
// Usage in controller
class XmlController {
async submit ({ request }) {
const xmlData = await request.getBody()
try {
const parsed = await safeParse(xmlData)
// Process safely parsed data
} catch (error) {
return { error: 'Invalid XML format' }
}
}
}
module.exports = XmlController
Alternatively, use AdonisJS's built-in body parser with XML type validation:
// config/bodyParser.js
module.exports = {
json: {
limit: '10mb',
type: 'application/json'
},
urlencoded: {
limit: '10mb',
extended: true,
type: 'application/x-www-form-urlencoded'
},
multipart: {
limit: '10mb',
type: 'multipart/form-data'
},
xml: {
limit: '5mb',
type: 'application/xml',
// Prevent XXE by rejecting external entities
filter: (ctx, req) => {
return !/\&[a-zA-Z_]+;/g.test(req.getBody().toString())
}
}
}
// routes/api.js
Route.post('xml-submit', 'XmlController.handle', { parser: 'xml' })
For SOAP-based integrations, implement input sanitization before parsing:
// app/Services/SoapService.js
const { sanitize } = require('dompurify')
async processSoapRequest(ctx) {
const xmlBody = ctx.request.getBody()
// Sanitize XML to prevent entity expansion
const safeXml = sanitize(xmlBody, { ADD_TAGS: ['!ENTITY'] })
// Proceed with safe XML processing
}
Key remediation practices:
- Always disable DTD processing when parsing XML
- Use parser configuration options like
disableIdentity: trueor equivalent - Validate XML structure against XSD schemas when possible
- Set parser memory limits to prevent resource exhaustion
- Use dedicated XML validation libraries instead of general-purpose parsers
middleBrick identifies these vulnerabilities during scanning and provides specific remediation paths tailored to AdonisJS's ecosystem, including framework-specific code patterns and configuration recommendations.