Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarLint
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarCloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube

Secrets
ABAP
Apex
AzureResourceManager
C
C++
CloudFormation
COBOL
C#
CSS
Docker
Flex
Go
HTML
Java
JavaScript
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Scala
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML

Java static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your JAVA code

Tags

Credentials should not be hard-coded
Vulnerability
Components should not be vulnerable to intent redirection
Vulnerability
XML parsers should not allow inclusion of arbitrary files
Vulnerability
Extracting archives should not lead to zip slip vulnerabilities
Vulnerability
Dynamic code execution should not be vulnerable to injection attacks
Vulnerability
NoSQL operations should not be vulnerable to injection attacks
Vulnerability
HTTP request redirections should not be open to forging attacks
Vulnerability
Deserialization should not be vulnerable to injection attacks
Vulnerability
Endpoints should not be vulnerable to reflected cross-site scripting (XSS) attacks
Vulnerability
Database queries should not be vulnerable to injection attacks
Vulnerability
XML parsers should not be vulnerable to XXE attacks
Vulnerability
A secure password should be used when connecting to a database
Vulnerability
XPath expressions should not be vulnerable to injection attacks
Vulnerability
I/O function calls should not be vulnerable to path injection attacks
Vulnerability
LDAP queries should not be vulnerable to injection attacks
Vulnerability
OS commands should not be vulnerable to command injection attacks
Vulnerability
Counter Mode initialization vectors should not be reused
Vulnerability
Thread suspensions should not be vulnerable to Denial of Service attacks
Vulnerability
A new session should be created during user authentication
Vulnerability
JWT should be signed and verified with strong cipher algorithms
Vulnerability
Cipher algorithms should be robust
Vulnerability
Encryption algorithms should be used with secure mode and padding scheme
Vulnerability
Server hostnames should be verified during SSL/TLS connections
Vulnerability
Insecure temporary file creation methods should not be used
Vulnerability
Passwords should not be stored in plain-text or with a fast hashing algorithm
Vulnerability
Server certificates should be verified during SSL/TLS connections
Vulnerability
Persistent entities should not be used as arguments of "@RequestMapping" methods
Vulnerability
"HttpSecurity" URL patterns should be correctly ordered
Vulnerability
LDAP connections should be authenticated
Vulnerability
Cryptographic keys should be robust
Vulnerability
Weak SSL/TLS protocols should not be used
Vulnerability
"SecureRandom" seeds should not be predictable
Vulnerability
Cipher Block Chaining IVs should be unpredictable
Vulnerability
Basic authentication should not be used
Vulnerability
Regular expressions should not be vulnerable to Denial of Service attacks
Vulnerability
"HttpServletRequest.getRequestedSessionId()" should not be used
Vulnerability
Hashes should include an unpredictable salt
Vulnerability
Accessing files should not lead to filesystem oracle attacks
Vulnerability
Environment variables should not be defined from untrusted input
Vulnerability
XML operations should not be vulnerable to injection attacks
Vulnerability
JSON operations should not be vulnerable to injection attacks
Vulnerability
XML signatures should be validated securely
Vulnerability
XML parsers should not be vulnerable to Denial of Service attacks
Vulnerability
Mobile database encryption keys should not be disclosed
Vulnerability
Applications should not create session cookies from untrusted input
Vulnerability
Reflection should not be vulnerable to injection attacks
Vulnerability
Authorizations should be based on strong decisions
Vulnerability
OpenSAML2 should be configured to prevent authentication bypass
Vulnerability
Server-side requests should not be vulnerable to forging attacks
Vulnerability
OS commands should not be vulnerable to argument injection attacks
Vulnerability
"ActiveMQConnectionFactory" should not be vulnerable to malicious code deserialization
Vulnerability
Logging should not be vulnerable to injection attacks
Vulnerability
Exceptions should not be thrown from servlet methods
Vulnerability
HTTP response headers should not be vulnerable to injection attacks
Vulnerability
Classes should not be loaded dynamically
Vulnerability
XML parsers should not load external schemas
Vulnerability

XML parsers should not be vulnerable to Denial of Service attacks

Vulnerability

MajorSonarSource default severity
click to learn more

symbolic-execution

Why is this an issue?

An XML bomb / billion laughs attack is a malicious XML document containing the same large entity repeated over and over again. If no restrictions is in place, such a limit on the number of entity expansions, the XML processor can consume a lot memory and time during the parsing of such documents leading to Denial of Service.

Noncompliant code example

For DocumentBuilder, SAXParser and Schema and Transformer JAPX factories:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant

SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant

SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant

TransformerFactory factory = javax.xml.transform.TransformerFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant

For Dom4j library:

SAXReader xmlReader = new SAXReader();
xmlReader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false); // Noncompliant

For Jdom2 library:

SAXBuilder builder = new SAXBuilder();
builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, false);  // Noncompliant

Compliant solution

For DocumentBuilder, SAXParser and Schema and Transformer JAPX factories:

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

SAXParserFactory factory = SAXParserFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI);
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

TransformerFactory factory = javax.xml.transform.TransformerFactory.newInstance();
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

For Dom4j library:

SAXReader xmlReader = new SAXReader();
xmlReader.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

For Jdom2 library:

SAXBuilder builder = new SAXBuilder();
builder.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);

Resources

Oracle Java Documentation - XML External Entity Injection Attack
OWASP Top 10 2017 Category A4 - XML External Entities (XXE)
OWASP XXE Prevention Cheat Sheet
MITRE, CWE-776 - Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Developer
Edition

© 2008-2023 SonarSource S.A., Switzerland. All content is copyright protected. SONAR, SONARSOURCE, SONARLINT, SONARQUBE, and SONARCLOUD are trademarks of SonarSource S.A. All other trademarks and copyrights are the property of their respective owners. All rights are expressly reserved.
Privacy Policy | Cookie Policy

In-IDE

SaaS

Self-Hosted