This method contains a call to java.lang.Object.wait() which is not in a loop.  If the monitor is used for multiple conditions, the condition the caller intended to wait for might not be the one that actually occurred.

Classes that throw exceptions in their constructors are vulnerable to Finalizer attacks

A finalizer attack can be prevented, by declaring the class final, using an empty finalizer declared as final, or by a clever use of a private constructor.

See SEI CERT Rule OBJ-11 [https://wiki.sei.cmu.edu/confluence/display/java/OBJ11-J.+Be+wary+of+letting+constructors+throw+exceptions] for more information.

This code creates a java.util.Random object, uses it to generate one random number, and then discards the Random object. This produces mediocre quality random numbers and is inefficient. If possible, rewrite the code so that the Random object is created once and saved, and each time a new random number is required invoke a method on the existing Random object to obtain it.

If it is important that the generated Random numbers not be guessable, you must not create a new Random for each random number; the values are too easily guessable. You should strongly consider using a java.security.SecureRandom instead (and avoid allocating a new SecureRandom for each random number needed).

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

When data from an untrusted source is put into a logger and not neutralized correctly, an attacker could forge log entries or include malicious content. Inserted false entries could be used to skew statistics, distract the administrator or even to implicate another party in the commission of a malicious act. If the log file is processed automatically, the attacker can render the file unusable by corrupting the format of the file or injecting unexpected characters. An attacker may also inject code or other commands into the log file and take advantage of a vulnerability in the log processing utility (e.g. command injection or XSS).


Code at risk:


String val = request.getParameter("user");
String metadata = request.getParameter("metadata");
[...]
if(authenticated) {
    log.info("User " + val + " (" + metadata + ") was authenticated successfully");
}
else {
    log.info("User " + val + " (" + metadata + ") was not authenticated");
}


A malicious user could send the metadata parameter with the value: "Firefox) was authenticated successfully\r\n[INFO] User bbb (Internet Explorer".



Solution:


You can manually sanitize each parameter.


log.info("User " + val.replaceAll("[\r\n]","") + " (" + userAgent.replaceAll("[\r\n]","") + ") was not authenticated");




You can also configure your logger service to replace new line for all message events. Here is sample configuration for LogBack using the replace function [https://logback.qos.ch/manual/layouts.html#replace].


%-5level - %replace(%msg){'[\r\n]', ''}%n




Finally, you can use a logger implementation that replace new line by spaces. The project OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging] has an implementation for Logback and Log4j.


References
CWE-117: Improper Output Neutralization for Logs [https://cwe.mitre.org/data/definitions/117.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://cwe.mitre.org/data/definitions/93.html]
CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection') [https://logback.qos.ch/manual/layouts.html#replace]
OWASP Security Logging [https://github.com/javabeanz/owasp-security-logging]

Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behavior to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.

Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behavior to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.