The Java Coding Guidelines の#01 limit the life cycle of sensitive data in memory

When a competitor's application executes on the same system as our application, the sensitive data in memory of our application is very easy to be obtained by the competitor. If our application meets one of the following scenarios, the competitor is able to obtain sensitive data from our application:

1) Applications use objects to store sensitive data, and after objects are used. The object's contents have not been erased or the object has not been garbage collected;

2) When the operating system performs memory management tasks or performs functions such as hibernation. The memory paging of the application will be replaced on disk to save;

3) A buffer object (such as BufferedReader) that stores the operating system cache or sensitive data in memory is held.

4) Reflection-based control flow. Allows competitors to use evasive measures to escape the limitations of the life cycle of sensitive variables;

5) Leakage of sensitive data in debug information/log file/environment variables or thread and core dumps.

Memory that includes sensitive data is not emptied in time after the data is used, and very easy leads to leakage of sensitive data.

In order to limit such risks. Applications must minimize the life cycle of sensitive data.

The perfect protection against the leakage of memory data requires the support of the underlying operating system and the Java Virtual machine. For example, assuming that there is a security problem in displacing the memory data to disk, a secure operating system will need to disable the displacement of the data and hibernate the system.

[Code Demo sample that does not meet security requirements]

The following code reads the user's username and password from the console and saves password in a string object, which causes the password to be in a leaked state before the garbage collector reclaims the memory occupied by the string.

Import Java.io.console;import Java.io.ioexception;public class Password {public static void main (string[] args) throws IO Exception {Console console = System.Console (); if (console = = null) {System.out.println ("No console."); System.exit (1);} String username = console.readline ("Enter Your user name:"); String Password = console.readline ("Enter Your Password:"); if (!verify (username, password)) {throw new SecurityException ("Invalid Credentials");}} Dummy Verify method, always returns trueprivate static final Boolean verify (string Username, string password) {return T Rue;}}

[Security-compliant solutions]

This workaround uses the Console.readpassword () function to get the password from the console

Import Java.io.console;import Java.io.ioexception;import Java.util.arrays;public class Password {public static void Main (string[] args) throws IOException {Console console = System.Console (); if (Console = = null) {System.out.println ("No Co Nsole. "); System.exit (1);} String username = console.readline ("Enter your user name:"); char[] Password = Console.readpassword ("Enter your password:" if (!verify (username, password)) {throw new SecurityException ("Invalid Credentials");} Clear the Passwordarrays.fill (password, ');} Dummy Verify method, always returns trueprivate static final Boolean verify (String username, char[] password) {return T Rue;}}

The function Console.readpassword () makes the returned data a byte array type, not a string object. So. The developer is able to empty the data after the array data has been used, and this function disables the display of the password on the console at the same time.

[Code Demo sample that does not meet security requirements]

The following code wraps the InputStreamReader object with the BufferedReader object, which causes the sensitive data to be read directly in the file.

void ReadData () throws IOException {BufferedReader br = new BufferedReader (New InputStreamReader (" File "));//read from filestring data = Br.readline ();}

The Bufferdreader.readline () function returns sensitive data as a string object, which can survive a very long time after the sensitive data has been exhausted.

The Bufferedreader.read (char[], int, int) functions are capable of reading sensitive data into a char array. Only this requires the developer to manually clean up after using the sensitive data. Similarly, suppose you use BufferedReader to wrap FileReader objects. There is also the same security issue.

[Security-compliant solutions]

The following code uses the directly allocated NIO buffer to read sensitive data from a file. After the data has been used. It can be cleared immediately, and sensitive data is not slow to exist in multiple locations, only in system memory.

void ReadData () {Bytebuffer BB = bytebuffer.allocatedirect (16*1024); try (filechannel rdr = (new FileInputStream ("file")) . Getchannel ()) {while (Rdr.read (BB) > 0) {//does something with the Bufferbb.clear ();}} catch (Throwable e) {//Handle err or}}

It is important to note that the data inside the buffer must be manually cleared, since this part of the data garbage collector is not recycled.

--Welcome reprint, please indicate the source http://blog.csdn.net/asce1885 . Do not use for commercial purposes without my permission. Thank you--

The Java Coding Guidelines の#01 limit the life cycle of sensitive data in memory