Using command line arguments is security-sensitive. It has led in the past to the following vulnerabilities:
Command line arguments can be dangerous just like any other user input. They should never be used without being first validated and sanitized.
Remember also that any user can retrieve the list of processes running on a system, which makes the arguments provided to them visible. Thus passing sensitive information via command line arguments should be considered as insecure.
This rule raises an issue when on every program entry points (main
methods) when command line arguments are used. The goal is to guide
security code reviews.
If you answered yes to any of these questions you are at risk.
Sanitize all command line arguments before using them.
Any user or application can list running processes and see the command line arguments they were started with. There are safer ways of providing sensitive information to an application than exposing them in the command line. It is common to write them on the process' standard input, or give the path to a file containing the information.
This rule raises an issue as soon as there is a reference to argv, be it for direct use or via a CLI library like JCommander, GetOpt or Apache CLI.
public class Main { public static void main (String[] argv) { String option = argv[0]; // Sensitive: check how the argument is used } }
// === JCommander === import com.beust.jcommander.*; public class Main { public static void main (String[] argv) { Main main = new Main(); JCommander.newBuilder() .addObject(main) .build() .parse(argv); // Sensitive main.run(); } }
// === GNU Getopt === import gnu.getopt.Getopt; public class Main { public static void main (String[] argv) { Getopt g = new Getopt("myprog", argv, "ab"); // Sensitive } }
// === Apache CLI === import org.apache.commons.cli.*; public class Main { public static void main (String[] argv) { Options options = new Options(); CommandLineParser parser = new DefaultParser(); try { CommandLine line = parser.parse(options, argv); // Sensitive } } }
In the case of Args4J, an issue is created on the public void run
method of any class using org.kohsuke.args4j.Option
or
org.kohsuke.args4j.Argument
.
Such a class is called directly by org.kohsuke.args4j.Starter
outside of any public static void main
method. If the class
has no run
method, no issue will be raised as there must be a public static void main
and its argument is already
highlighted.
// === argv4J === import org.kohsuke.args4j.Option; import org.kohsuke.args4j.Argument; public class Main { @Option(name="-myopt",usage="An option") public String myopt; @Argument(usage = "An argument", metaVar = "<myArg>") String myarg; String file; @Option(name="-file") public void setFile(String file) { this.file = file; } String arg2; @Argument(index=1) public void setArg2(String arg2) { this.arg2 = arg2; } public void run() { // Sensitive: This function myarg.toString(); // check how this argument is used } }
The support of Argv4J without the use of org.kohsuke.argv4j.Option
is out of scope as there is no way to know which Bean will be used
as the mainclass.
No issue will be raised on public static void main(String[] argv)
if argv
is not referenced in the method.
This rule is deprecated, and will eventually be removed.