Static code analysis issues preventing deployment in production. about ecrnow HOT 5 CLOSED

Updates performed.

from ecrnow.

The path manipulation issues related to the attachment filename have not been addressed. I believe we talked about checking to see whether the file name (DirectResponseReceiver.java:103) contained either path slashes, forward or back. But upon further reflection, as you are writing to a file and then reading it back in, you should probably just generate the name used to guarantee uniqueness and prevent concurrency issues if multiple requests arrive with the same name.

Also with the introduction of password encryption the algorithm chosen has been flagged as weak. Search for "Weak Encryption: Insecure Mode of Operation" in the attached workbook, it has recommendations for how to address.

ecrnow DeveloperWorkbook.pdf

from ecrnow.

The latest changes to address the encryption improve the related 2 issues from critical to high. However, now the initialization vector is predictable and thus still insecure.

The code

  byte[] iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
  IvParameterSpec ivspec = new IvParameterSpec(iv);

should be changed to something like

  SecureRandom random = new SecureRandom();
  byte[] iv = random.generateSeed(16);
  IvParameterSpec ivspec = new IvParameterSpec(iv);

from ecrnow.

The new function, getRandomString in ApplicationUtils is now being flagged for insecure random. I am thinking the simplest way to create a random file name is to use UUID.randomUUID() as part of it.

from ecrnow.

The latest updates address the issues reported by HPE Fortify

from ecrnow.