11

If you are assessing an application as a part of pentesting exercise, how do you deal with broken site functionality? Should the issues be ignored?

Is keeping functional bugs in a system safe?

h4ckNinja
  • 3,006
  • 15
  • 24
one
  • 1,781
  • 3
  • 18
  • 45

3 Answers3

20

Broken functionalities in a web application are not a security threat per se, but they might be one. For you as a penetration tester, look out for:

  • Information leakage about the system (stacktraces, version numbers, error messages, file paths, ...) as they might help an attacker
  • Missing security features (if the functionality to change the password is broken, then you should include this in your report)
  • System crashes (DoS)
  • And generally any unexpected behaviour.

As each and every line of code (and therefore each feature, whether working or not) increases the attack surface of the application, the client should avoid to deploy (partly) broken features to their servers.

Lukas
  • 3,138
  • 1
  • 15
  • 20
2

If the application lacks requirements, for example: there should have been a password reset option, then best you can do is report this to your client, but this certainly is not your work.

When the application meets the requirements for this stage, and is production ready, then anything you find is a vulnerability and should be patched before release.

If you are helping out with vulnerability analysis in the early development stages (development branches) you should intervene as soon as possible to prevent further development on top of a weakened base.

Yorick de Wid
  • 3,346
  • 14
  • 22
1

Really very much depends on the kinds of functional bugs you are experiencing. Two examples

1) The application is supposed to show some module or panel with additional data, but this isn't appearing. Fairly likely in itself to be benign, although issues anywhere could be indicative of a higher likelihood of unrelated security issues. After all, if the coders can't even maintain a high standard with respect to the visible functional requirements, what's their standard going to be like with requirements like security that are invisible to the business?

2) You get a database error when the user enters %*^&#$ into an online form. This is likely to warrant further investigation, and could indicate dangerous lack of validation or input sanitization.

I would add that any time an application crashes or behaves in an unexpected way, this is because the application has gotten into an unforeseen (and often undefined, unpredictable) state. This does not necessarily increase the attack surface, however the fact that it has become unpredictable means that (to all intents and purposes) the attack surface has effectively increased until deeper knowledge about it's behavior is obtained and the implications of the issues are better understood.