DLo611921 (Community Member) asked a question.

CWE-117: Mitigation by setting encoding on logging files via log4j's configuration

I have CWE-117 being identified in multiple locations within different applications. I understand that owasp encoding the log outputs could remediate the flaw. I'm able to set up encoding of the logs through log4j's configuration XML, but Veracode doesn't seem to pick that up as a remediation.

 

I'd like to know if the solution with log4j's configuration sufficient for me to mitigate the flaws. Doing so would prevent me from having to make plenty of code changes throughout each application. This would save time remediating the flaws and without having to encode log outputs when we develop new features.

 

I'm also open to other solutions as well.


  • Hi @DLo611921 (Community Member)​ ,

     

    Encoding or removing CR and LF characters will remove risk presented by CWE 117 flaws, however it cannot be automatically detected by Veracode Static Analysis.

    If you chose this remediation you will need to either mitigate all instances of CWE 117 or request that your security team create a separate policy that excludes CWE 117 for your application.

     

    The only other options that we are able to automatically detect are:

    1. Not using dynamic data in log statements.
    2. Using integers or other primitive data types incapable of containing a CR or LF character.
    3. Use of a Supported Cleansing Function on all dynamic data before it is provided to a logging statement: https://help.veracode.com/reader/4EKhlLSMHm5jC8P8j3XccQ/IiF_rOE79ANbwnZwreSPGA .
    4. Directly using ESAPI Logger ( https://www.javadoc.io/doc/org.owasp.esapi/esapi/latest/org/owasp/esapi/class-use/Logger.html ).
    5.  

    Alternatively you may also consider using a custom cleansing attribute ( https://community.veracode.com/s/question/0D52T00004ymJzySAE/veracode-custom-cleansers ).

     

    Please let me know if you have any remaining questions or concerns.

     

    Thank you,

    Boy Baukema

    Expand Post
    Selected as Best
  • Robert (Community Member)

    What I did to save lots of time was implement a "wrapper" logger, that simply wraps the log4j interface and annotated every method with the @CRLFCleanser annotation. This avoids having to mark everything manually.

     

    I've attached the source file to save other people some time if they want to use the same approach.

    Expand Post
    • NNagarajan832135 (Community Member)

      Can you tell me on how to implement the annotated logger into our application code.

      • Robert (Community Member)

        The first step is fairly obvious, which is include the file from above in your project and change the package name to suit your needs. Then, in any file you want to use it, do something like the following (and otherwise it's just log4j usage for everything else):

         

        package my.package.parent;

         

        import my.package.util.AnnotatedLogger;

         

        public class MyClass {

         

        private static final AnnotatedLogger LOG = AnnotatedLogger.getLogger();

         

        public void doSomething() {

        // ...

        LOG.debug("My log statement");

        // ...

        }

        }

         

         

        Expand Post

Topics (4)

No articles found
Loading

Ask the Community

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