How to Fix CWE 117 Improper Output Neutralization for Logs

How to Fix CWE 117 Improper Output Neutralization for Logs

 

What is this CWE about?

Veracode Static Analysis reports CWE 117 (“Log Poisoning”) when it detects an application is composing log messages based on data coming from outside the application. This could be data from an HTTP request, a database, or even the filesystem. The concern is that if file-based logging is being used, an attacker might be able to use whitespace characters such as Carriage Return (CR) and Line Feed (LF), to inject their own log lines into application logs. These characters are typically represented as \r and \n respectively, or in hex 0x0D, 0x0A. This might be used to pollute log files during an attack, making it impossible to know which log entries were from the app and which were from an attacker. As the log integrity has been lost, the log files may become significantly less useful for auditing purposes.

 

How to remediate this?

We would always recommend looking into ways to remediate a flaw before considering any mitigation strategies. Remediation of CWE 117 means there is no remaining risk because the application correctly sanitizes this data prior to logging. Veracode maintains a list of Supported Cleansing Functions (https://help.veracode.com/r/review_cleansers) for a range of languages and the respective CWE(s) the cleanser is appropriate for. Using one of these functions that have “CWE 117” as “Flaw Class” would in most cases be detected by Veracode Static Analysis and the flaw will no longer be reported on future scans. Please note that you may need to try several cleansing functions to find the perfect one for your use case. This is because the cleansing functions will remove or encode certain characters differently. For example, using an HTML encoder such as `org.owasp.esapi.Encoder.encodeForHTML` would cleanse CRLF characters (i.e., remediating the flaw) but the log may end up looking more “HTML-esque” and less human-readable, than if for example `org.owasp.encoder.Encode.forJava` was used instead. Note that if the logs are to be viewed as HTML then encoding for HTML would be a much better solution than calling e.g. `org.owasp.encoder.Encode.forJava`. You should always use a cleansing function that does not encode any characters you may want to log to your log files.
For language-specific remediation guidance on CWE 117, you may also want to refer to https://www.veracode.com/security/java/cwe-117 for Java and https://www.veracode.com/security/dotnet/cwe-117 for .NET.

 

Veracode does not list a cleanser for my programming language, what to do?

For many programming languages, such as Python, PHP, or JavaScript, we currently do not support a cleansing function for CWE 117. In this section, we use these three languages as examples to discuss some mitigation strategies. Whenever possible we recommend using popular, community-tested libraries to deal with CWE 117 for the language in use. If you’re aware of a library or function that we can support, please consider suggesting this as a Veracode Community Idea (https://community.veracode.com/s/ideas). Where there isn’t an appropriate function, the application will need to implement custom sanitization, for example in form of a regex or a string replacement. When using a regex for filtering CRLF characters, it is important to make sure that Multiline mode is deactivated. As an example, the following regex ^[a-zA-Z0-9]{1,50}$ (which allows between 1 and 50 alphanumeric characters) would not be sufficient for CRLF character filtering if Multiline mode was enabled.

Please note that Veracode Static Analysis does not automatically detect the strategies mentioned in this section, so the development team would have to propose a mitigation (https://help.veracode.com/r/improve_mitigation) and document the exact control in use for the Security Team to review.


Python:
In Python, a solid mitigation strategy would be using the built-in `encode()` function on all dynamic parts before inserting them into a log message. An example snippet could look like this:

username_sanitized = username.encode()
logger.info(f"User {username_sanitized} logged in.")

Another strategy would be to use the `logging-formatter-anticrlf` logging library which can be applied on a logging handler to automatically encode CRLF characters.
You find more details on both mentioned Python strategies here: https://www.veracode.com/blog/secure-development/fixing-crlf-injection-logging-issues-python​​​​​​


PHP:
We are not aware of a community-tested function that handles CRLF characters securely in PHP. A solid mitigation strategy would be manually replacing all CRLF characters whilst preserving the intent for auditing, with a snippet like this:

str_replace(["\r","\n"], ["\\r","\\n"], $input);


JavaScript:
We are not aware of a community-tested function that handles CRLF characters securely in JavaScript. A strategy could be to manually replace all CRLF characters whilst preserving the intent for auditing. A sample snippet using a regex would look like this:

input.replace(/[\n]/g, '\\n').replace(/[\r]/g, '\\r');

 

We don’t log to a file?

If you use a logging technology such as the ELK Stack (Elasticsearch, Kibana, Logstash) or Splunk, there could still be some risk if the ND-JSON (new-line delimited JSON) data format is used for (bulk) indexing of log data. Here, an attacker might be able to add their own JSON instances via new line delimiters to the bulk to be inserted into your logs. If you are certain the medium you are logging to does not interpret carriage return or line feed characters such that they can be used to create new log entries, this can be a suitable mitigation argument.

 

We use a web-based logging, what to do?

From a log-management point of view, web-based logging should certainly be preferred over traditional file-based logging. In this scenario, the same type of attack could be achieved via injecting the HTML element <br> which would also introduce a line break should the logs be rendered as HTML. Moreover, web-based rendering of log files might allow an attacker to inject their own HTML, which may lead to CWE 80 (Cross-Site Scripting). That’s precisely why using the appropriate context is of such fundamental importance for output encoding. In the case of a web-based logging, we would recommend you apply HTML encoding on all dynamic or external data that may enter the logs.

Please note that Veracode Static Analysis does currently not support any web-based logging cleansing function, requiring a mitigation for this type of finding.

Topics (2)

Related Articles

Related Topics

    Ask the Community

    Get answers, share a use case, discuss your favorite features, or get input from the Community.