'Heap Check' Vulnerability

php editor Yuzai today brings you a java question and answer about the "heap check" vulnerability. In the software development process, heap checking is a common security vulnerability that can be easily exploited by hackers for malicious attacks. Through the Q&A format of this article, we will give you an in-depth understanding of the definition, principles and prevention methods of heap inspection vulnerabilities, helping you better protect the security of your software system.

Question content

I need to pass a password to the call. If I do this

byte[] datasourcepasswddecoded = base64.getdecoder().decode(datasourcepasswdencoded);
string datasourcepasswd = new string(datasourcepasswddecoded);
hikaridatasource.setpassword(datasourcepasswd);

When fortify scanned this code, it was reported that the code had a "heap check" vulnerability due to assigning passwords to strings.

fortify will not complain about the original code:

hikaridatasource.setpassword(env.getproperty("spring.datasource.password"));

Even though env.getproperty() does return a string.

fortify recommends:

private JPasswordField pf;
...
final char[] password = pf.getPassword();
// use the password
...
// erase when finished
Arrays.fill(password, ' ');

But how to use char[] as password when the function requires a string?

Solution

Yes... Base64 encoding the password is not protective at all. Any hacker with half a brain knows how to identify and decode base64. So your "weird base64 stuff" doesn't help.

But on the other hand, your vulnerability scanner pointed out a problem that is relatively difficult to exploit, and probably cannot be solved anyway.

At some point in the application (its dependencies or somewhere) the password will be converted to Java String...because some APIs require String. At this point, whether the scanner tells you or not, you have a "heap check" vulnerability. For example, if the data source uses JDBC, the password needs to be passed as a parameter to the DriverManager.connect call. connect There are 3 overloads... but they all require passing the password as a clear text string. Solving this problem is impractical.

^{(Apparently, the so-called fix suggested by Fortify apparently doesn't work. And it doesn't notice that your call to setPassword(env.getProperty("spring.datasource.password")) is It's just that what you're currently doing is "bad". It's "performance safety"...)}

The most practical solution is to tell the scanner that this is a "false positive". Then take steps to prevent hackers from attaching a debugger, checking RAM, core dumps, swapping disks, etc., and searching the heap for a String object that might represent a password.

There is also a "nasty" solution that requires smashing through the type abstraction of the String object and overriding its backing array. But this approach is fragile.

The representation of
• String has changed many times during the life of Java, and each change may break your String overriding code.
• In some cases, the backing array of String is shared with other String objects, and destroying the backing array will damage these objects.
• There is a problem with finding all situations where a password String may have been copied or inserted into another String object.

Unless you are dealing with confidential information, this is (IMO) overkill. If you are handling confidential information, please secure your platform before taking these steps. (And don’t rely on stupid security scanning software for security audits!)

The above is the detailed content of 'Heap Check' Vulnerability. For more information, please follow other related articles on the PHP Chinese website!