【Java编码准则】の #01限制内存中敏感数据的生命周期

当竞争对手的应用程序与我们的应用程序执行在同一个系统上时,我们的应用程序在内存中的敏感数据是非常easy被竞争对手获取的。假设我们的应用程序符合以下几种情况之中的一个,那么竞争对手能够获取到我们应用的敏感数据:

1)应用程序使用对象来存储敏感数据,并且在对象使用完后。对象的内容没有被清除或者对象没有被垃圾回收;

2)在操作系统执行内存管理任务或者执行休眠等功能时。应用程序的内存分页将被置换到磁盘上保存;

3)持有存储了操作系统缓存或者内存中敏感数据的buffer对象(比如BufferedReader)。

4)基于反射的控制流。使得竞争对手能够使用规避措施逃过敏感变量生命周期的限制;

5)在调试信息/日志文件/环境变量或者线程和core dumps等方面泄漏了敏感数据。

包括敏感数据的内存在数据使用后没有及时清空,非常easy导致敏感数据的泄漏。

为了限制这样的风险。应用程序必须尽量减小敏感数据的生命周期。

完美的防止内存数据的泄漏要求底层操作系统和Java虚拟机的支持。比如假设将内存数据置换到磁盘上是存在安全问题的,那么一个安全的操作系统就须要禁用数据的置换和系统的休眠。

[不符合安全要求的代码演示样例]

以下代码从控制台读取用户的username和password并将password保存在一个String对象中,这导致在垃圾回收器回收String所占用的内存之前,password处于泄漏状态。

import java.io.Console;
import java.io.IOException;

public class Password {

	public static void main(String[] args) throws IOException {
		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 true
	private static final boolean verify(String username, String password) {
		return true;
	}

}

[符合安全要求的解决方式]

这个解决方式使用Console.readPassword()函数从控制台中获取password

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 Console.");
			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 password
		Arrays.fill(password, ' ');

	}

	// dummy verify method, always returns true
	private static final boolean verify(String username, char[] password) {
		return true;
	}

}

函数Console.readPassword()使得返回的数据是字节数组类型,而不是String对象。因此。开发人员能够在数组数据使用完了之后清空数据,这个函数同一时候禁止了password在控制台上面的显示。

[不符合安全要求的代码演示样例]

以下的代码使用BufferedReader对象包装InputStreamReader对象,这导致敏感数据能够直接在文件里读取到。

	void readData() throws IOException {
		BufferedReader br = new BufferedReader(new InputStreamReader(new FileInputStream("file")));

		// read from file
		String data = br.readLine();
	}

BufferdReader.readLine()函数将敏感数据以String对象的形式返回,这个对象在敏感数据用完之后还会存活非常长的时间。

而BufferedReader.read(char[], int, int)函数能够将敏感数据读取到一个char数组中。只是这须要开发人员在使用完敏感数据后手动清除。类似的,假设使用BufferedReader来包装FileReader对象。也会存在相同的安全问题。

[符合安全要求的解决方式]

以下的代码使用直接分配的NIO buffer来从文件里读取敏感数据。在数据使用完后。能够马上清除它,并且敏感数据不会缓存在多个位置,仅存在于系统内存中。

	void readData() {
		ByteBuffer bb = ByteBuffer.allocateDirect(16*1024);
		try (FileChannel rdr = (new FileInputStream("file")).getChannel()) {
			while(rdr.read(bb) > 0) {
				// do something with the buffer
				bb.clear();
			}
		} catch(Throwable e) {
			// Handle error
		}
	}

须要注意的是,必须手动清除buffer里面的数据,由于这部分数据垃圾回收器是不会进行回收的。

——欢迎转载,请注明出处 http://blog.csdn.net/asce1885 。未经本人允许请勿用于商业用途。谢谢——

时间: 2024-10-16 21:37:02

【Java编码准则】の #01限制内存中敏感数据的生命周期的相关文章

【Java编码准则】の #00限制敏感数据的生命周期

当竞争对手的应用程序与我们的应用程序运行在同一个系统上时,我们的应用程序在内存中的敏感数据是很容易被竞争对手获取的.如果我们的应用程序符合下面几种情况之一,那么竞争对手可以获取到我们应用的敏感数据: 1)应用程序使用对象来存储敏感数据,而且在对象使用完后,对象的内容没有被清除或者对象没有被垃圾回收: 2)在操作系统运行内存管理任务或者执行休眠等功能时,应用程序的内存分页将被置换到磁盘上保存: 3)持有存储了操作系统缓存或者内存中敏感数据的buffer对象(例如BufferedReader): 4

【Java编码准则】の #02不要在客户端存储未加密的敏感信息

当构建CS模式的应用程序时,在客户端侧存储敏感信息(例如用户私要信息)可能导致非授权的信息泄漏. 对于Web应用程序来说,最常见的泄漏问题是在客户端使用cookies存放服务器端获取的敏感信息.Cookies是由web服务器创建的,它具有一个指定的有效时间,保存在客户端.当客户端连接上服务器端时,客户端使用cookies中存储的信息向服务器端进行认证,通过后服务器端返回敏感信息. 在XSS攻击下,Cookies不能保证敏感信息的安全.无论是通过XSS攻击,还是直接对客户端的攻击,攻击者一旦获取到

【Java编码准则】の #13使用散列函数保存密码

明文保存密码的程序在很多方面容易造成密码的泄漏.虽然用户输入的密码一般时明文形式,但是应用程序必须保证密码不是以明文形式存储的. 限制密码泄漏危险的一个有效的方法是使用散列函数,它使得程序中可以间接的对用户输入的密码和原来的密码进行比较,而不需要保存明文或者对密码进行解密后比较.这个方法使密码泄漏的风险降到最低,同时没有引入其他缺点. [加密散列函数] 散列函数产生的值称为哈希值或者消息散列,散列函数是计算可行函数,但反过来是计算不可行的.事实上,密码可以被编码为一个哈希值,但哈希值不能被解码成

【Java编码准则】の #13使用散列函数保存password

明文保存password的程序在非常多方面easy造成password的泄漏.尽管用户输入的password一般时明文形式.可是应用程序必须保证password不是以明文形式存储的. 限制password泄漏危急的一个有效的方法是使用散列函数.它使得程序中能够间接的对用户输入的password和原来的password进行比較,而不须要保存明文或者对password进行解密后比較.这种方法使password泄漏的风险降到最低,同一时候没有引入其它缺点. [加密散列函数] 散列函数产生的值称为哈希值

【Java编码准则】の #11不要使用Object.equals()来比较密钥值

java.lang.Object.equals()函数默认情况下是不能用来比较组合对象的,例如密钥值.很多Key类没有覆写equals()函数,因此,组合对象的比较必须单独比较里面的各个类型以保证正确性. [不符合安全要求的代码示例] 下面的代码使用equals()函数比较两个key值,key值即使具有相同的取值也可能会返回不相等,导致结果出错. private static boolean keysEqual(Key key1, Key key2) { if (key1.equals(key2

【Java编码准则】の #11不要使用Object.equals()来比較密钥值

java.lang.Object.equals()函数默认情况下是不能用来比較组合对象的,比如密钥值.非常多Key类没有覆写equals()函数,因此,组合对象的比較必须单独比較里面的各个类型以保证正确性. [不符合安全要求的代码演示样例] 以下的代码使用equals()函数比較两个key值,key值即使具有同样的取值也可能会返回不相等,导致结果出错. private static boolean keysEqual(Key key1, Key key2) { if (key1.equals(k

JAVA面试题:Spring中bean的生命周期

Spring 中bean 的生命周期短暂吗? 在spring中,从BeanFactory或ApplicationContext取得的实例为Singleton,也就是预设为每一个Bean的别名只能维持一个实例,而不是每次都产生一个新的对象使用Singleton模式产生单一实例,对单线程的程序说并不会有什么问题,但对于多线程的程序,就必须注意安全(Thread-safe)的议题,防止多个线程同时存取共享资源所引发的数据不同步问题. 然而在spring中 可以设定每次从BeanFactory或Appl

Spring容器中Bean的生命周期

日出日落,春去秋来,花随流水,北雁南飞,世间万物皆有生死轮回.从调用XML中的Bean配置信息,到应用到具体实例中,再到销毁,Bean也有属于它的生命周期. 人类大脑对图像的认知能力永远高于文字,因此,闲言少叙,书归正传,上图先: 步骤很多,切莫惊慌,我们可以把上面的步骤归纳如下: 1-2:创建实例: 现在假设spring就是个容器,而配置文件中配置的bean属性才是我们真正需要的东西.创建实例就是说,我把配置文件中的bean信息取出来化作一个真正的bean并放到容器中. 3-4:注入依赖关系:

Spring:Spring中bean的生命周期

Spring中,从BeanFactory或ApplicationContext取得的实例为Singleton(单例模式),就是预设为每一个Bean的别名只能维持一个实例,而不是每次都产生一个新的对象使用Singleton模式产生单一实例,对单线程的程序说并不会有什么问题,但对于多线程的程序,就必须注意安全(Thread-safe)的议题,防止多个线程同时存取共享资源所引发的数据不同步问题. 然而在spring中 可以设定每次从BeanFactory或ApplicationContext指定别名并