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.

Ask Yourself Whether

If you answered yes to any of these questions you are at risk.

Recommended Secure Coding Practices

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.

Sensitive Code Example

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
  }
}

Exceptions

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.

See

Deprecated

This rule is deprecated, and will eventually be removed.