0

In C#, assertions can be stripped out by the compiler by switching from debug mode to release mode. From a security (and UX) standpoint, this is a good thing in order to avoid exposing a stacktrace to the end-user, as a stacktrace may lower user-confidence in the stability of the app, and a stacktrace could expose vulnerabilities which can be exploited. Further, a stacktrace could give some information that can help hackers reverse-engineer the software.

After looking at Java assertions, it appears that no such capability exists. That is, assertions remain in the compiled bytecode, and there are no command-line options to the Java compiler to strip them away. Rather, we see that the Java runtime permits the enabling of assertions, something which could be done by a malicious user attempting to glean stacktrace information. Also, I've even seen some encourage the idea that assertions should fail dramatically to spit out an AssertionError and a stacktrace. Or simply, people are neglecting to talk about the security aspects of letting an application fail like this.

My initial assessment is that the assertions in Java pose a security risk, even if they provide advantages for debugging or maintenance.

Should we stay away from using assertions in Java for security-critical applications; or if there is a proper, and secure, way include assertions, how should it be done?

Edit for Clarity: I'm assuming here that the Java application is being deployed to the end-user as a desktop application. That is, the user downloads/installs the application. That being said, it is my understanding that the user is able to run an executable jar while enabling assertions with something to the effect of: 
java -ea -jar "MyJar.jar"
Nicholas Miller
  • 4,205
  • 2
  • 39
  • 62
  • 2
    `AssertionError` can be (and should be) handled gracefully and not allowed to be propagated up to the user. Your linked answer is still valid for general code, but there should still be global error handler that makes sure errors are properly logged. – tsolakp Jan 24 '18 at 18:23

2 Answers2

1

Assertions don't make Java programs any less secure than they already are. Not that it would be a "feature" of Java, as any program written in any language running on your computer is insecure, unless you can take advantage of something like TPM (and even then it's not completely secure, unless you believe the marketing people).

You're not obligated to show the stacktrace to a user, but that has very little to do with security. Writing it to a log is a lot cleaner. You're not obligated to use assertions either, I think it might be less common in the Java ecosystem compared to for example C#.

The stacktrace itself provides very little useful information in a desktop environment¹, as you already have full access to the code anyway. There are dozens of easier ways to glean information than try trickery with assertions. For one you could just decompile the classes. Now you might think "I'll obfuscate it, at least it will make it a bit harder", but that's the equivalent of saying "I'll build a very low fence, at least it will keep babies away". It's not better than nothing, it is nothing, but it can make you think you have some level of protection and that's a security risk.

Either you have information that needs to be secure and you have to use effective methods, or you have information that isn't important and you don't need to secure it. The scale is binary in that way although the secure end has different flavours and requirements, usually with fancy government names.

¹ In a web environment showing the stacktrace to a user may be a security risk, as it can show information about libraries being used and provide an attack vector through library bugs. That's why you don't see stacktraces in production, unless someone screwed up really bad.

Kayaman
  • 72,141
  • 5
  • 83
  • 121
1

Rather, we see that the Java runtime permits the enabling of assertions, something which could be done by a malicious user attempting to glean stacktrace information.

If a user is able to enable assertions in the JVM running the application whose security is in question, they already have a level of access that allows them to achieve even more consequential exploits.

It is true that exposing stack traces to an end user can have security implications, but whether stack traces are exposed or not in this way is something the application designers have control over.

Should we stay away from using assertions in Java for security-critical applications; or if there is a proper, and secure, way include assertions, how should it be done?

I think one good argument for avoiding the use of assertions for security reasons is that the programmer may accidentally use an assertion condition having side effects. If the program is developed and tested with assertions enabled, but released in an environment where they are not, the behavior of the program will be different. This might introduce bugs that could pose security vulnerabilities.

Mark Maurice Williams
  • 217
  • 2
  • 5
  • 1
    If the malicious user knows how to enable assertions, he's going to know plenty of easier ways to get information out of the program. Enabling assertions would be an incredibly inefficient way to get irrelevant information. – Kayaman Jan 24 '18 at 17:55
  • @Kayaman My OP assumed this was for desktop applications (now edited). Given that the code is obfuscated, in what ways would it be more efficient to reverse-engineer? – Nicholas Miller Jan 24 '18 at 18:37
  • 1
    @NickMiller of course it's for desktop applications, how would you enable assertions on a web app? Obfuscation is not a real security mechanism, it's the most basic form of security by obscurity and keeps away only the most incompetent attackers. You're overestimating the security risk of assertions while ignoring all the other, more realistic security risks. – Kayaman Jan 24 '18 at 18:40
  • @Kayaman I agree that obfuscation isn't *truly secure*. Though, I'm looking at this from the perspective of slowing down an attack to the point that it becomes infeasible. Is it true that giving the stacktrace offers little to no advantage to attackers since they already can see the obfuscated source? – Nicholas Miller Jan 24 '18 at 18:51
  • 1
    @NickMiller Either you're in a situation where obfuscation is unnecessary because there's nothing worth stealing, or you're in a situation where it won't hinder the attacker. Obfuscation is not "better than nothing", it's actually worse because it can give a false sense of safety. Very common for inexperienced (security-wise) people to be impressed with the idea of obfuscation though, so this isn't a new viewpoint to me. However if you have access to the program running on your computer, you have plenty of tools to get into far more useful information than a stacktrace. Obfuscated or not. – Kayaman Jan 24 '18 at 18:57
  • It's been a few years since I've last had to teach someone that obfuscation is a mere fallacy. That's the problem, to a layperson it seems at least *slightly* usable. You should try modifying/"breaking" an obfuscated program to see how easy it actually is, at least if you have the necessary skills. Sorry Mark, didn't mean to hijack your answer's comment section. – Kayaman Jan 24 '18 at 19:05
  • The large benefit I see from obfuscation is that member names/var names are lost, I understand that deobfuscators can easily reverse the algorithms used by obfuscators; but afaik, it is impossible to reproduce the original names. I've also seen that obfuscation can be used to *help* detect piracy via watermarking. It's not 100% foolproof, though, I'd expect it to prove useful. – Nicholas Miller Jan 24 '18 at 19:49
  • @NickMiller no offense, but you just don't have the experience. Retrieving original naming is irrelevant to the attacker, so what you thought was an advantage is actually nothing. It's one of those cases where common sense lies to you. You expect it to be of *some* use, but when you're actually examining it closely you can easily notice that it doesn't give any of the (even small) benefits you thought it did. There is the danger of a false sense of security though. Don't let feelings get in the way of information security. – Kayaman Jan 24 '18 at 20:12
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/163828/discussion-between-nick-miller-and-kayaman). – Nicholas Miller Jan 24 '18 at 20:24