Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: wordsmithing

The java.io.InputStream class is abstract; programs thus require a wrapper such as BufferedInputStream that provides a concrete implementation of the InputStream. Java input classes such as Scanner and BufferedInputStream facilitate fast, non-blocking I/O by buffering the an underlying input stream. Programs can create multiple wrappers on an InputStream. Programs that use multiple wrappers around a single stream, however, can behave differently unpredictably depending on whether the InputStream allows wrappers allow look-ahead. An adversary can exploit this difference in behavior by, for example, redirecting System.in (from a file) or by using the System.setIn() method to redirect System.in. Redirecting input from the console is a standard practice on UNIX based platforms; it is less common on other platforms such as Windows, where console programs are considered largely outmoded. In general, any input stream that supports non-blocking buffered I/O is susceptible to this form of misuse.

Do not create multiple wrappers that buffer input from a single InputStreamAny input stream may not have more than one buffered wrapper created over it. Instead, create and use only one wrapper, either by passing it as an argument to the methods that need it or by declaring it as a class variable.

...

Code Block
bgColor#FFCCCC
public final class InputLibrary {
  public static char getChar() throws EOFException {
    BufferedInputStream in = new BufferedInputStream(System.in); // wrapper
    int input = in.read();
    if (input == -1) {
      throw new EOFException();
    }
    // Down casting is permitted because InputStream guarantees read() in range  
    // 0..255 if it is not -1
    return (char)input; 
  }

  public static void main(String[] args) {
    try {
      // Either redirect input from the console or use 
      // System.setIn(new FileInputStream("input.dat")); 
      System.out.print("Enter first initial: ");
      char first = getChar();
      System.out.println("Your first initial is " + first);
      System.out.print("Enter last initial: ");
      char last = getChar();
      System.out.println("Your last initial is " + last);
    } catch(EOFException e) {
        System.out.println("ERROR");
        // foward to handler
    }
  }
}
Implementation Details (POSIX)

This program was compiled with the command javac InputLibrary.java on a system with under Java 1.6.0. When run from the command line with java InputLibrary, the program successfully takes two characters as input and prints them out. However, when run with java InputLibrary < input, where input is a file that contains identical redirected to standard input, the program throws an EOFException because the second call to getChar() finds no characters to read upon encountering the end of the stream.

It may appear that the mark() and reset() methods of BufferedInputStream could be used to replace the read bytes. However, these methods provide look-ahead by operating on the internal buffers of the BufferedInputStream rather than by operating directly on the underlying stream. Because the example code creates a new BufferedInputStream on each call to getchar(), the internal buffers of the previous BufferedInputStream are lost.

Compliant Solution (Class Variable)

Create and use only a single BufferedInputStream on System.in. This compliant solution ensures that all methods can access the BufferedInputStream by declaring it as a class variable.

Code Block
bgColor#ccccff
public final class InputLibrary {
  private static BufferedInputStream in = new BufferedInputStream(System.in);

  public static char getChar() throws EOFException {
    int input = in.read();
    if (input == -1) {
      throw new EOFException();
    }
    in.skip(1); // This statement is to advance to the next line
                // The noncompliant code example deceptively
                // appeared to work without it (in some cases)
    return (char)input; 
  }

  public static void main(String[] args) {
    try {
      System.out.print("Enter first initial: ");
      char first = getChar();
      System.out.println("Your first initial is " + first);
      System.out.print("Enter last initial: ");
      char last = getChar();
      System.out.println("Your last initial is " + last);
    } catch(EOFException e) {
        System.out.println("ERROR");
    }
  }
}
Implementation Details (POSIX)

This program was compiled with the command javac InputLibrary.java on a system with under Java 1.6.0. When run from the command line with java InputLibrary, the program successfully takes two characters as input and prints them out. Unlike the NCCE, this program also produces correct output when run with java InputLibrary < a file redirected to standard input.

Compliant Solution (Accessible Class Variable)

When If a program intends to use the library InputLibrary in conjunction with other code that requires user input and that consequently needs another buffered wrapper around System.in as well as this class InputLibrary, the program must use the same buffered wrapper as does the librarythis class, rather than creating and using its own additional buffered wrapper. The Consequently library InputLibrary must return an instance of make available a reference to the buffered wrapper to support this functionality.

Code Block
bgColor#ccccff
public final class InputLibrary {
  private static BufferedInputStream in = new BufferedInputStream(System.in);

  // Other methods

  static BufferedInputStream getBufferedWrapper() {
    return in;
  }

  // ...other methods
}


// Some code that requires user input from System.in
class AppCode {
  private static BufferedInputStream in;
  
  AppCode() {
    in =  InputLibrary.getBufferedWrapper();
  }

  // Other...other methods
}

Note that reading from a stream is not a thread-safe operation by default; consequently, this scheme may not work well in multi-threaded environments. Explicit In such cases, explicit synchronization is required in such cases.

Risk Assessment

Creating multiple buffered wrappers around an InputStream can cause unexpected program behavior when the InputStream is re-directed.

...