Contents
V5319. OWASP. Possible log injection. Potentially tainted data is written into logs.
The analyzer has detected data written into logs from an external source without validation. This can violate logging processes or compromise the contents of log files.
Errors related to data logging can be categorized under the OWASP Top 10 2021 Security Risks list as follows:
- A09:2021 – Security Logging and Monitoring Failures.
If logging of user input is performed without validation, an attacker can inject arbitrary data into logs.
Here is an example—let's say logs are stored in text format. An attacker can use different ways to find out the storage type—it's easy if the project is open source. Moreover, intruders may exploit other attack techniques. A possible log can look as follows:
INFO: User 'SomeUser' entered value: '2022'.
INFO: User 'SomeUser' logged out.
The code that performs logging can look as follows:
public class InputHelper {
private final Logger logger = LoggerFactory.getLogger(InputHelper.class);
private String username;
public void process(InputStream stream) {
Scanner scanner = new Scanner(stream);
String userInput = scanner.next();
String logMessage = "User '" + userName +
"' entered value: '" + userInput + "'.";
logger.info(logMessage); // <=
}
}In this case, an attacker can inject arbitrary data about events that never happened.
For example, an attacker enters the following:
2022/r/nINFO: User 'Admin' logged out.
The following entry will appear in the logs, which may mislead a person analyzing the logs:
INFO: User 'SomeUser' entered value: '2022'.
INFO: User 'Admin' logged out.
Let's consider another type of an attack. For example, if logs are stored in the XML format, an attacker can inject data that will make the contents of the report incorrect. Moreover, the following parsing of ready-made logs may produce incorrect data or fail with an error.
An attacker can inject an unclosed tag and make it impossible to parse an XML file.
Possible vulnerabilities depend on architecture, input settings, logger, log output and other parts of the logging system. For example, a log injection attack in XML format allows attackers to:
- violate the process of adding new log entries;
- violate the process of viewing ready-made logs;
- exploit XEE vulnerabilities;
- exploit XXE vulnerabilities;
- exploit an insecure deserialization vulnerability.
You can prevent some attacks by escaping characters so that they are not treated as part of XML syntax. For example, the initial character of the "<" tag should be escaped as "<". You can escape the XML log as follows:
import org.apache.commons.text.StringEscapeUtils;
public class EscapedInputHelper {
private final Logger logger =
LoggerFactory.getLogger(EscapedInputHelper.class);
private String username;
public void process(InputStream stream) {
Scanner scanner = new Scanner(stream);
String userInput = scanner.next();
String escapedInput = StringEscapeUtils.escapeXml11(userInput);
String logMessage = "User '" + userName +
"' entered value: '" + escapedInput + "'.";
logger.info(logMessage);
}
}Let's look at the example: the JSON standard prohibits null characters ("\0") in files. If an attacker introduces this character, it can break the process of saving or viewing ready-made logs. Therefore, the null character should be escaped as "\u0000".
Here is another example. If logs are stored in a relational DBMS that uses SQL and input data is not verified, this can lead to an SQL injection attack (for more details, see the V5309 diagnostic rule).
Was this page helpful?
