Fortify SCA scan reports Log Forging issue while reading environment variables

Question

I used System.getenv("envVariableName") and it threw me a Log Forging issue. I, even, tried encoding the returned String using ESAPI encoder but it didn't help.

My code snippet:

String envValue = encode(System.getenv("envVariableName"));

String encode(String message) {
        if (message != null) {
            String clean = message.replace('\n', '_').replace('\r', '_');
            if (ESAPI.securityConfiguration().getLogEncodingRequired()) {
                clean = ESAPI.encoder().encodeForHTML(message);
                if (!message.equals(clean)) {
                    clean += " (Encoded)";
                }
            }
            return clean;
        }
        return message;
    }

Any suggestion with regard to what I'm missing would be appreciated.

score 1 · Answer 1 · answered May 05 '19 at 01:29

Fortify (used to a least) recognized ESAPI's encoders as removing 'web' taint flags, but I think that was only in the context of Fortify's XSS rules. I don't think think that they have done that in the context of Log Forging, although I'm pretty sure they recognize ESAPI's logging as providing "safe logging" though.

If I understand your desire here, you don't simply wish to mark this particular instance as "Not an Issue" and suppress it, but instead, you want it to not recognize this pattern as Log Forging instances in the first place. Unfortunately, you can't really modify HP (now Microfocus) Fortify rules. (Their rule packs are even encrypted, so short of running AWB under a debugger, you can't even view their rules.) If you decide that "environment variables" are "trusted", I suppose you could set up and apply a AWB filter set that would ignore instances where the only taint flag on the sink is "environment variable". (Or do that any only apply it to this Log Forging category.)

But in general, you are either going to have to live with the noise (Fortify generates a lot of false positives) or you are going to have to manually vet each of the instances and suppress the false positives as "Not an Issue". That's the usual way of working, although sometimes that function is limited to AppSec specialists.

Hope that helps.

score 0 · Answer 2 · answered Apr 26 '19 at 12:41

0

The line appointed by Fortify is really on String envValue = encode(System.getenv("envVariableName"));?

The Log Forging issues normally occurs when you write some information to a log from a untrusted source: https://vulncat.fortify.com/en/detail?id=desc.dataflow.java.log_forging#C%23%2FVB.NET%2FASP.NET

answered Apr 26 '19 at 12:41

Raphael Hagi

88
6

Yeah, because Fortify reports Log Forging issue even in case of data entering an application from an untrusted source; in this case, the values read from environment variables. Anyway, I'm also facing this issue with logs. If you have a solution for that, it'd still be helpful. – Aman Agarwal Apr 27 '19 at 13:20
If you really trust about this source, you can mark this as false positive. But, check this thread: https://stackoverflow.com/questions/30537359/cant-resolve-log-forging-fortify-issue – Raphael Hagi Apr 29 '19 at 13:25

score 0 · Answer 3 · answered Apr 29 '19 at 02:36

0

Question: If you are already using ESAPI, then why not just use ESAPI's logging since it provides "safe logging" as in protecting against Log Forging attacks?

answered Apr 29 '19 at 02:36

Kevin W. Wall

1,347
7
7

It is on the requirement basis that I can't use EASPI logging. And as I mentioned I'm looking for a solution where Fortify could see the input data as a trusted one. Do you have a suggestion for that? – Aman Agarwal Apr 29 '19 at 06:16
Answering as a new answer, below, because my reply is too long. – Kevin W. Wall May 05 '19 at 01:25

Fortify SCA scan reports Log Forging issue while reading environment variables

3 Answers3