Add Weak Random testcases

[davewichers]

Per title

To fix the problem, replace the use of java.util.Random with a cryptographically secure RNG such as java.security.SecureRandom when generating the bytes for rememberMeKey. This preserves existing functionality (random remember‑me tokens) while making them unpredictable to an attacker.

Concretely, within doPost in Benchmark00898.java, change the line that currently creates a new java.util.Random and calls nextBytes so that it uses a java.security.SecureRandom instance instead. Since this class doesn’t currently import SecureRandom, add an import for java.security.SecureRandom at the top of the file. No other logic needs to change: nextBytes(byte[]) exists on SecureRandom with the same signature, and the subsequent ESAPI Base64 encoding and cookie handling remain unchanged.

Specifically:

• Add import java.security.SecureRandom; near the other imports.
• Replace new java.util.Random().nextBytes(bytes); with new SecureRandom().nextBytes(bytes);.

No new helper methods or fields are required; using a local SecureRandom instance is sufficient for this context.

In general, the fix is to replace uses of java.util.Random for generating security-sensitive values with java.security.SecureRandom, which is designed to be cryptographically strong and resistant to prediction. Any token or cookie that enables access or session continuation must be generated using a CSPRNG.

For this specific file, we should:

• Replace new java.util.Random().nextDouble() with a SecureRandom-based token.
• Keep functionality similar (a random-looking string) while changing only the randomness source.
• Because we shouldn’t alter behavior more than necessary, we can keep using a double-derived string if we wish, but it’s cleaner to generate a random byte array and encode it as hex or base64. However, the current code expects a string of digits; to minimize functional change we can still derive from nextDouble() but produced by SecureRandom. The simplest minimal change is: create a SecureRandom instance, call nextDouble(), and use it as before.

Concretely:

• Add import java.security.SecureRandom; near the other imports in Benchmark00899.java.
• Change line 68 from double value = new java.util.Random().nextDouble(); to use SecureRandom, e.g.:
  • java.security.SecureRandom secureRandom = new java.security.SecureRandom();
  • double value = secureRandom.nextDouble();
    This keeps all subsequent uses (Double.toString(value)...) unchanged, while ensuring the randomness source is cryptographically secure.

---