1. Introduction
An XSLT Injection is when an attacker injects XSLT documents into an application. This attack can lead to confidential data being exposed, denial of service, port scanning from the server where the parser runs, and other system impacts. Systems processing XML with untrusted XSLT are usually affected. Impact on confidentiality is likely, integrity may be compromised, and availability could be disrupted.
2. Technical Explanation
XSLT Injection happens when an application uses user-supplied data directly in XSLT transformations without proper sanitisation. An attacker can craft malicious XSLT code that executes arbitrary commands or accesses sensitive information. The attack requires the application to parse XML documents containing injected XSLT. CWE-91 covers this vulnerability class. As a simple example, an attacker could inject XSLT to read local files on the server.
- Root cause: Missing input validation and sanitisation of user-supplied data used in XSLT transformations.
- Exploit mechanism: An attacker provides XML containing malicious XSLT code that is then processed by the application’s parser, leading to unintended execution or data disclosure. For example, an attacker could submit a crafted XML file with XSLT designed to read system files.
- Scope: Applications using XSLT processors in languages like Java, .NET, PHP, and Python are potentially affected. Specific versions depend on the processor implementation.
3. Detection and Assessment
Confirming vulnerability involves checking how user input is handled during XML processing. A quick check is to review application code for XSLT transformations using external data sources. Thorough assessment requires analysing all points where XML is parsed with untrusted content.
- Quick checks: Review source code for calls to XSLT processors and identify if user-controlled data is used directly in the transformation process.
- Scanning: Static analysis tools can detect potential injection vulnerabilities in XSLT transformations, but results should be reviewed carefully as false positives are common.
- Logs and evidence: Examine application logs for errors related to XML parsing or XSLT processing, which may indicate an attempted attack. Look for unusual file access attempts.
grep -r "XSLTProcessor" /path/to/application/code4. Solution / Remediation Steps
Fixing this issue requires careful input validation and sanitisation of all user-supplied data used in XSLT transformations.
4.1 Preparation
- Ensure a roll back plan is in place, such as version control or database backups. A change window may be needed for production deployments.
4.2 Implementation
- Step 1: Identify all instances where user-supplied data is used within XSLT transformations.
- Step 2: Implement strict input validation to ensure only expected characters and formats are allowed in the XML data.
- Step 4: Consider using a templating engine instead of directly embedding user input into XSLT code.
4.3 Config or Code Example
Before
// Insecure: Direct user input in XSLT template
$xml = $_GET['user_data'];
$xslt = new XSLTProcessor();
$result = $xslt->transform($xml);After
// Secure: Validate and sanitize user input before using in XSLT
$userInput = $_GET['user_data'];
if (preg_match('/^[a-zA-Z0-9]+$/', $userInput)) {
$xml = $userInput; // Only allow alphanumeric characters
$xslt = new XSLTProcessor();
$result = $xslt->transform($xml);
} else {
// Handle invalid input (e.g., log error, display message)
}4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent XSLT Injection.
- Least privilege: Run the application with minimal necessary permissions to limit potential damage if exploited.
- Safe defaults: Configure the XSLT processor with secure default settings and disable unnecessary features.
4.5 Automation (Optional)
Automated scanning can help identify vulnerable code patterns.
# Example Bash script to scan for insecure XSLT usage
find /path/to/application/code -name "*.php" -exec grep "XSLTProcessor" {} ; | grep "$_GET"5. Verification / Validation
Confirm the fix by re-testing with malicious input and verifying that it’s blocked or sanitised.
- Post-fix check: Run the application and attempt to inject XSLT code through user input parameters. Verify no unexpected behaviour occurs.
- Re-test: Repeat the earlier detection methods (code review, scanning) to confirm the vulnerability is no longer present.
- Monitoring: Monitor application logs for any errors related to XML parsing or XSLT processing. A simple query could look for “XSLTProcessor” combined with error codes.
grep -i "XSLTProcessor" /path/to/application/logs6. Preventive Measures and Monitoring
Preventative measures include updating security baselines and incorporating checks into the development pipeline.
- Baselines: Update application security baselines to include specific rules for XSLT input validation and sanitisation.
- Pipelines: Integrate static analysis tools (SAST) into the CI/CD pipeline to detect potential injection vulnerabilities during code review.
- Asset and patch process: Maintain a regular patch cycle for all software components, including XSLT processors.
7. Risks, Side Effects, and Roll Back
Applying input validation may cause compatibility issues with existing XML data formats.
- Risk or side effect 1: Strict input validation could break legitimate use cases if not carefully implemented. Thorough testing is required.
- Risk or side effect 2: Incorrect sanitisation could introduce new vulnerabilities. Use well-established libraries and methods for sanitising XML data.
- Roll back: Restore the previous version of the application code from version control. Revert any configuration changes made to the XSLT processor.
8. References and Resources
- Vendor advisory or bulletin: N/A – depends on specific XSLT processor used.
- NVD or CVE entry: https://cwe.mitre.org/data/definitions/91
- Product or platform documentation relevant to the fix: Documentation for your specific XSLT processor (e.g., PHP’s DOMDocument, Java’s javax.xml.transform).