3

In Java it's common to see code such as System.getProperty('line.separator') which is used to build Strings used for output, etc. It has been recommended by vulnerability scanners that it is advisable to validate this input by e.g. ensuring it matches \n or \r\n etc.

But I wonder, since Java itself is vulnerable to these within its own PrintWriter.printLn and possibly BufferedWriter.newLine() etc., is it now a best practice to validate System.getProperty('line.separator') within every program that issues new line statements? It seems overkill.

Is there some alternate best practice that would obviate the need to validate all System properties? E.g. is it sufficient as a best practice to review the privileges and commands at the sysadmin level rather than at the developer level? If not, why are vulnerability scanners taking these precautions now?

My impression is that this kind of validation at the code level is overkill in a standard corporate production environment where there are multiple levels of separation of duties and privilege lockdowns among dev/test/prod etc. This is just my opinion however, and I would like to hear others'.

Anders
  • 65,582
  • 24
  • 185
  • 221
blindcodifier9734
  • 205
  • 1
  • 3
  • 5

1 Answers1

3

Ensuring it matches a predefined pattern negates the point of having it.

From the oracle documentation -

Security consideration: Access to system properties can be restricted by the Security Manager.

And also

The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up. The setProperties method changes the set of system properties for the current running application. These changes are not persistent. That is, changing the system properties within an application will not affect future invocations of the Java interpreter for this or any other application. The runtime system re-initializes the system properties each time its starts up.

So to be a risk you have to expect a malicious party to somehow inject a setProperties call into your running application. Unless you pass user input to a "setProperties" call (which is a terrible idea in general) this should not be a problem. If they can inject code then you have far bigger issues. If you are still concerned then use the SecurityManager.

Hector
  • 10,953
  • 4
  • 43
  • 45