'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 JavaString...because some APIs requireString. 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 theDriverManager.connectcall.connectThere 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 tosetPassword(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 requiressmashingthrough the type abstraction of theStringobject and overriding its backing array. But this approach is fragile.

The representation of
• Stringhas changed many times during the life of Java, and each change may break yourStringoverriding code.
• In some cases, the backing array ofStringis shared with otherStringobjects, and destroying the backing array will damage these objects.
• There is a problem with finding all situations where a passwordStringmayhave been copied or inserted into anotherStringobject.

Unless you are dealing withconfidential 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!