[
https://issues.apache.org/jira/browse/LOG4J2-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235086#comment-16235086
]
ASF GitHub Bot commented on LOG4J2-1203:
----------------------------------------
GitHub user rturner-edjuster opened a pull request:
https://github.com/apache/logging-log4j2/pull/122
LOG4J2-1203 Added Pattern encoding for CRLF only
Added a Pattern encoding format limited to just CRLF for use cases
where you do not want full HTML or JSON encoding, but do want to
protected against CR and/or LF injection attacks in logs.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rturner-edjuster/logging-log4j2 LOG4J2-1203
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/logging-log4j2/pull/122.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #122
----
commit 1c567fc0fcc709cbcd0591423a0fb0f733c4c25c
Author: Robert Turner <rtur...@e-djuster.ca>
Date: 2017-11-02T00:53:24Z
LOG4J2-1203 Added Pattern encoding for CRLF only
Added a Pattern encoding format limited to just CRLF for use cases
where you do not want full HTML or JSON encoding, but do want to
protected against CR and/or LF injection attacks in logs.
----
> Allow filtering of line breaks in layout pattern
> ------------------------------------------------
>
> Key: LOG4J2-1203
> URL: https://issues.apache.org/jira/browse/LOG4J2-1203
> Project: Log4j 2
> Issue Type: New Feature
> Components: Pattern Converters
> Affects Versions: 2.4.1
> Reporter: Mitth'raw'nuruodo
> Priority: Minor
> Fix For: 2.0-rc2
>
> Attachments:
> 0001-LOG4J2-1203-Added-Pattern-encoding-for-CRLF-only.patch
>
>
> Unless specific steps are taken to filter log inputs, there may be a risk of
> CRLF injection, allowing an attacker to forge log entries:
> https://cwe.mitre.org/data/definitions/93.html
> This is not a critical vulnerability, but manually
> escaping/encoding/sanitising every instance of logging in a large application
> is impractical. Most applications have no need to output un-filtered line
> breaks, so they would benefit from a global option.
> Could the list of pattern converters be extended to include a modifier to say
> that whitespace should be normalised (as per Commons Lang
> {{StringUtils.normaliseSpace}})? Eg {{%_m}}
> Alternatively, it would be simple to implement a wrapper that would apply
> normalisation to the output of another layout, but it would be more difficult
> to configure such a wrapper in XML, and it would affect the entire log
> output, effectively obliterating all padding modifiers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
