1

I'm attempting to learn more about secure coding in Java, and was tasked with making my code more compliant. If dealing with sensitive file data in the example program I've created below how can I make sure that the data will not linger after execution in the memory?

I'm mainly wondering if there is a need to clear the memory at all with the program as is.

I have been reading multiple posts, however I have not found a straight forward explanation as of yet. If you would take a different approach to read a line from a file in a safer way please feel free to let me know. After reading so many sources I'm beginning to feel a little lost. Any help for a newcomer would be greatly appreciated!

import java.io.*;

public class Data {

private static final String file = "fileData.txt";

public static void main(String[] args) throws IOException {

   BufferedReader br = new BufferedReader(new FileReader(file));

   String data = null;

   try {
      // Read from the file
      data = br.readLine(); 

      // closing BufferedReader
      br.close();


      // Printing a line from file
      System.out.println(data);          
    }
    //define catch to handle the IOException
    catch (IOException e) {
       e.printStackTrace(); // Print Stack Trace for further analysis
    }
}

}

carmen90
  • 13
  • 3
  • It is not clear what you want. Please try to describe it better. – mentallurg May 24 '20 at 17:09
  • Hi there, tried to elaborate a bit more. This is for an assignment where we try to make our code more secure when reading sensitive data from a file. I'm wondering if I need to manually clear the buffer to prevent any remnants of data which may be left over after execution which a malicious user could get a hold of. – carmen90 May 24 '20 at 17:20
  • The question is still *too broad*. Think of following: 1) FileReader wraps InputStreamReader which has byte buffer and byte cache, both can contain sensitive data. 2) Every *readLine()* creates a new line which internally contains an array of characters which can be a sensitive info. In both cases 1) and 2) data remain in memory until garbage collected, means, a memory dump of your application will contain these data... – mentallurg May 24 '20 at 17:39
  • ... 3) You are writing data to the system output stream. This is even worse. If your application forwards system output to a file, then sensitive data will remain in the file even after application completed. Now try to explain what you need again. – mentallurg May 24 '20 at 17:39
  • I guess in simple terms how I can I clear the memory after reading from the file? – carmen90 May 24 '20 at 17:46
  • 1
    In Java you have almost no control on memory. It makes no sense to discuss if *br.close()* will clean up memory, because you writing data to the file. I have impression that you don't really understand that. In my opinion, it makes no sense to talk about secure coding if you don't understand the basics of Java. I'd suggest that you fist analyze the source code of the classes that are used here: String, FileReader, BufferedReader, how *readLine()* is working. Ask yourself: Where is memory allocated, where you can control memory usage, where you cannot. – mentallurg May 24 '20 at 19:15
  • ... Also read about memory model, memory usage in Java, about how the garbage collector works (pay attention to what Java version you are using and what is specifics of garbage collector in this version). – mentallurg May 24 '20 at 19:17
  • 1
    A little condescending, but thanks for your input. I'll continue reading about the memory model, and exactly how the BufferedReader & FileReader work. – carmen90 May 24 '20 at 19:55
  • If you are interested not in specific problem of handling sensitive data in memory, but you are interested in general in secure coding: The risks related to memory handling are relatively slow compared to the others. For web applications, the problems related to memory handling are not even in the OWASP top 10 (https://owasp.org/www-project-top-ten/). The most of these risks are relevant also for pure backend applications. Besides these 2 big areas, the share of Java in other areas is relatively small... – mentallurg May 24 '20 at 20:48
  • ... Means, it *might* be that you are investing your efforts into the problem that have relatively little importance compared to the other security problems. That's why your satisfaction (after you studied that deeply) *might* be not so big as you expect. Nevertheless, understanding of Java basic classes is an advantage in any case. – mentallurg May 24 '20 at 20:54

1 Answers1

1

You're fighting for a lost cause, I'm afraid.

Even if you zeroize the buffer used by BufferedReader (which you would have to access via reflection since it's private) there's no guarantee the JVM hasn't made a copy of it while compacting memory.

To quote Thomas Pornin's answer to a related question:

If your security model and context call for zeroing keys, then you should not use Java at all (or just about anything but C and assembly).

dnault
  • 8,340
  • 1
  • 34
  • 53