How to guard against Resource exhaustion and other vulnerabilities?

Question

We happened to use IBM appscan http://www-01.ibm.com/software/awdtools/appscan/

against our java codebase, and it returned around 3000 high severity vulnerabilities.

Most of them happen to be System Information Leak, which it thinks is happening when we print stack traces in the catch blocks, but we only print the filename and line number it is happening, enabling us to debug the code better.

And some are about SQL injection, input validation etc.

But, my question was about Resource exhaustion (file descriptor, disk space, sockets, ...), and it lists all instances of java.io.BufferedReader.readLine as places for possible external attacks.

       InputStream ins=conn.getInputStream();

      String inputLine;

      if (!preserveLinefeeds) {
         BufferedReader in = new BufferedReader(new InputStreamReader(ins));
         while ((inputLine = in.readLine()) != null)
            pr.readThreadResponse+=inputLine;
         in.close();
         ins.close();
      } 

conn is a HttpURLConnection object.

How do I add safegaurds in the code to prevent this?

Answer 1

Any time you open a stream, ensure that a finally block closes the stream when finished.

If an IOException is thrown while reading from the stream in your code the stream will not be closed, hence the warning

Java 7 makes this easy with the try with resources construct. In java 6 or earlier you need to replicate with lots of boilerplate, eg

InputStream ins = null;
try {
  ins = conn.getInputStream();
  ...
} finally {
  IOUtils.closeQuietly(ins);
}

Using the IOUtils class from Apache Commons

You can write your own closeQuietly if you don't want to add the dependency

Answer 2

If AppScan is indicating a Denial of Service vulnerability associated with the readLine, it is probably not due to any concern over the failure to close the stream (however important this may be), but rather due to the unbounded nature of readLine. Since readLine continues to read input until a newline or CR-LF is read, if the input source is not trusted, you could potentially be fed an inordinately large amount of data without the expected CR-LF, resulting in a memory exhaustion condition.

To resolve this you could either ensure (through mechanisms outside your app) that the input size is limited to something safe and reasonable (although AppScan, Fortify and other tools will continue to complain about the readLine) or, better yet, you could replace your readLines with a bounded read routine that sets an absolute maximum on the number of characters that will be read into the buffer.