If a code inspection tool finds a "heap inspection" vulnerability, is that relevant if the code is for a web app running on a private server?

Question

Recently, at the organization I work for, we've been using a static code inspection tool.

One of the more interesting findings is that private information, such as passwords, may be stored in the heap where it could potentially be intercepted by an application scanning the heap or perhaps a disk swap.

The app being scanned is a web app that runs on a private web server behind a firewall, so I'm wondering if this finding is relevant.

The app is written in C# and the "remediation" suggestion is to store sensitive information in character arrays rather than string objects so that they aren't stored in the heap. I realize it would take up some time to properly remediate this issue, so I wanted to ask if this finding is relevant when the code runs on a private server because presumably, a hypothetical attacker would have to bypass the firewall and run malicious code on the web server to steal data.

Answer 1

In C# and Java, String objects are immutable, so they remain in memory until the GC decides to reuse that memory. A character array is mutable, so it can be overwritten with other (e.g. random or zero) data as soon as the credentials are no longer needed, reducing the time the data is potentially visible to attackers.

So the solution is not just dropping in a mutable type instead of an immutable string, but also requires actively overwriting it as soon as it is no longer needed. There are classes specifically designed for this purpose that make this easy, e.g. SecureString, but also note the disclaimers in the limitations section.

Whether that is relevant to your threat model depends on a lot of factors. For example, it is more relevant if

• the difference between the time the credential data actually needs to be in memory (possibly only a few 100ms while assembling a request) between the uptime of your application (in the case of a web server, perhaps days or months) is large
• the number of credentials that may be loaded into memory during the uptime of your application is greater than the number of credentials used concurrently.
• your application is running in a context where the degree of isolation to other applications is not under your control

Of course, exploiting this vulnerability requires access to the memory, but note that this may be worse if you store coredump-files on crashes, or similar. If such a file leaks, you want it to contain the absolute minimum number of credentials possible. The likelyhood of that happening is up to your judgement... e.g. how likely is it for a server admin of your organisation to send the developer of the application a heap dump via unencrypted mail while debugging some problem?