Un tuto simple parlant de l''injection CRLF avec les loggers en Kotlin/Java.
Penser à ajouter la dépendance suivante pour se prémunir de cela avec LogBack :
<dependency>
<groupId>org.owasp</groupId>
<artifactId>security-logging-logback</artifactId>
<version>1.1.6</version>
</dependency>
(à voir avec ce que propose la 1.4.4 de LogBack sortie récemment).
Edit
Une autre façon de se protéger du problème est de se servir de la fonction replace de logback en lui demandant d'effectuer un search & replace de tous les caractères de type CR/LF by une chaîne connue (ici {EOL}) qui permettra de détecter l'injection de nouvelles lignes dans les logs :
<included>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%replace(%msg){'[\r\n]', '{EOL}'}</pattern>
</encoder>
</appender>
<root level="INFO">
<appender-ref ref="STDOUT" />
</root>
</included>
Pour mon exemple, je ne vais considérer que l'API proposée par SLF4J qui a un niveau de log en moins que celle de Log4j2 (le fatal) mais qui, à mon sens, ne sert à rien puisque logger le fait qu'une application se soit crashée est stupide... Puisqu'on le verra immédiatement qu'elle se soit arrêtée.
Reprenons :
ERROR
À ce niveau de log, il faut enregistrer les actions qui n'ont pas pu aboutir (typiquement une exception). Il faut savoir qu'une succession d'actions n'ayant pas abouties conduit en général à un crash applicatif, d'où le niveau error.
WARNING
À ce niveau de log, il faut enregistrer les événements qui sont incohérents mais vis-à-vis desquels l'application a pu retomber sur ses pâtes et donc poursuivre le traitement. Une succession de warnings trop importante engendre en général une erreur.
INFO
À ce niveau de log, il faut enregistrer l'activité des utilisateurs. Il ne s'agit pas de logs contenant l'état de l'application en elle-même mais ce que les utilisateurs ont essayé de faire avec l'application.
DEBUG
À ce niveau de log, il faut enregistrer l'activité technique de l'application (enregistrement sur le disque, ouverture/fermeture des connexions à la base, etc). Ce niveau de logs est à destination des admin-sys exclusivement pour leur permettre d'identifier un problème de configuration / comportement.
TRACE
À ce niveau de log, il faut enregistrer l'activité algorithmique de l'application, typiquement comment se comporte la mémoire, les threads, la création des objets, la validation / invalidation de contrôles conditionnels (if-else). Ce niveau est à destination des développeurs et uniquement eux pour leur permettre d'identifier l'origine d'un bug en production.