Is capturing Nullpointerexception bad practice?

Asked

Viewed 157 times

6

I’ve been a little uneasy about security issues and vulnerabilities lately, and in my research, I came up with an article that intrigued me.

According to the OWASP:

Description It is generally a bad Practice to catch Nullpointerexception.

Programmers typically catch Nullpointerexception under three Circumstances:

1 - The program contains a null Pointer dereference. Catching the Resulting Exception was easier than Fixing the underlying problem.

2 - The program explicitly throws a Nullpointerexception to Signal an error condition.

3 -The code is part of a test Harness that Supplies Unexpected input to the classes under test. Of These three Circumstances, only the last is acceptable.

That is, according to this text, the only acceptable situation to catch NullPointerException is in test cases, where the input can be something unexpected.

Why is it not a good idea to capture NullPointerException?

Since this is not a good idea, how should I proceed if this exception is something plausible within a scope?

Like NullPointerException may be a threat to my system?

security-guard exception nullpointerexception

  • Bad practice regarding something specific?

  • 1

    Apparently, OWASP considers the capture of NullPointerException bad security practice. It even says it’s a mistake to capture such an exception

  • Related: Best practices with Java exception handling

  • I should put that in the title?

  • 1

    The first two questions are answered in @bigown’s reply at this link.

  • Really enlightening his reply, thank you very much

Show 1 more comment

2 answers

8


In general it is yes. This usually occurs by a programming error. If there is an expectation that an information may be null, test before accessing it. This is the only acceptable practice in almost all situations. I’d say all within normal range, but I’m being cautious because there might be some useful situation. The exceptions are because of testing or solving a problem of something third party that you use and mistakenly throws the exception. For me this is not even acceptable, if something is so bad, or fix or change supplier because it is serious.

Do you think it’s plausible? You have to demonstrate why it is. It’s probably a valuation error.

If there’s this programming problem there’s something wrong with the code, or the programmer has no idea what he’s doing. This in itself is already a danger. I do not see a direct security problem, but perhaps they classify it as such by the indirect effect. For example, if the application breaks it may be that it has been poorly done at another point and leaves something open that creates the vulnerability. It’s not NPE’s problem, it’s allowing another failure to happen.

On the other hand, a general exception at some point of exit of the application must capture all exceptions, even those of programming to handle the standard output, since it exposes internal application data that can be used to exploit some vulnerability. Note that this is not treating the NPE but treating what cannot be treated, only "makeup". Ideally no programming errors should occur in production.

Anyway, just as good practices are bad, so are bad practices. Anyone who says something is bad should say because, otherwise if you can’t determine it on your own or another source, disregard the statement. In this case until you find out why, do not treat it as a security problem and only programming.

if (objeto != null) {
    //faz o que tem que fazer
}

I put in the Github for future reference.

If it can, and must do so before taking exception, why will it happen to treat it? It makes no sense.

Some useful questions:

  • So beyond the issue of capturing exceptions in general, I shouldn’t assume that capturing this exception will generate some kind of vulnerability to my system?

  • Depends on the exception, this does not cause directly.

2

There are two main types of exception: verifiable and unverifiable. The checkboxes (Exception) are the ones that Java forces you to deal with because the user must be able to recover from the problem. The unverifiable ones (Runtime) are those that leave the state of the system unrecoverable and therefore do not need to be treated. Nullpointer in Java is an unverifiable exception because if it were verifiable virtually every method would have to cast this exception. This doesn’t mean that it doesn’t need to be treated, but it also doesn’t mean that you should add treatment every time. The ideal is to treat specific and not so generic exceptions, as the specific ones are predicted and therefore allow the user to recover from the error. What is a threat to the system is to display the stacktrace of an unforeseen exception for the user. What needs to be done is just log the exception to the server and display a neutral screen for the user who will not be able to recover from the unforeseen exception.

  • 3

    And how does that apply to safety rules?

  • Security issues would expose implementation information in a stacktrace to users or fail to log an exception to it. In a web system you could use interceptors that would log the exceptions on the server and could notify responsible for the error. The important thing is always to identify what kind of exception may allow recovery by the user, so that the system does not remain in an inconsistent state. The best way to do this is by creating specific exceptions so that their treatment is appropriate.

  • 2

    So a stacktrace could pose a security risk to the application?

  • When you expose the internal structure of your application to a user who can for example verify that you use a Servlet, ejb, service, and thereby exploit vulnerabilities of these technologies.

  • 1

    @diegofm it is correct at this point, only it is not well in context, because capturing an NPE in thesis would avoid exposing the ST (unless the program capture and have it printed :). In fact it is the opposite, nay capturing NPE in some way may expose the application, but should not specifically capture it, it should capture generic exceptions as a last resort of problematic code, only for log in for you to know that you have to fix it and show the user something cute without exposing anything. But the capture should be at the application entry point, main() for example.

  • 1

    When I speak capture is in this sense to expose the content of the exception. What is not recommended is to capture it in a generic way even as Nullpointerexception.

Show 1 more comment

Browser other questions tagged security-guard exception nullpointerexception

You are not signed in. Login or sign up in order to post.