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?
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
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:
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.
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.
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.