I noticed a certain heuristic I have been using for quite a while now, without realizing it. So today I decided to explore it’s applications and, most importantly, give it a name.
I call it the Instance Heuristic.
Whenever I find a bug, I ask myself where else a similar problem might occur. I think of the bug as an instance of a mistake made because of code reuse, improper use of libraries or frameworks, object oriented programming or even object oriented thinking. Then I try to find other instances of the same mistake.
The Instance Heuristic corresponds to the questions “Where else… (might this occur) and What else.. (might go wrong now that I know of this possibility).
Note that this is kind of similar to the rumble strip heuristic, but then again, entirely different: The rumble strip heuristic deals with thorough investigation of a bug to understand its full impact as opposed to reporting its first symptoms and leaving it at that. The instance heuristic is for finding a different bug that originates from the same “source”. The instance heuristic can pick up where the rumble strip heuristic leaves off, thus complementing the latter.
Using the instance heuristic might even go as far as to span different applications or even projects. You might find a strange bug and check for similar issues in other applications that run on the same framework, are made by the same dev/company or even applications that simply attempt to solve a similar problem.
When I first noticed myself using the instance heuristic, I was running penetration testing for a web application. While trying standard URL manipulation, it became apparent that it was possible to add certain (completely unimportant) fields to the database without being logged in. Further exploration revealed that the site was simply missing authentication functionality for the form that allowed to add this data. I pushed this specific vulnerability as far as I could (the rumble strip heuristic in play here) and reported my findings. Still, it appeared to be impossible to do any considerable harm with this vulnerability.
Then I asked myself what other similar forms exist in the application that might also be missing authentication?
It turned out that, using a similar (but not the same) attack, it was also possible to add administrators.
Without being authenticated.
That is: there were several instances where proper authentication was missing.
Exploratory Testing can be thought of as using what you have learned about a product to help you test better, find important problems faster and to keep learning even more. So I encourage you to learn from any previous issues you or anyone else working on the product have discovered. Then apply that to inform your further work. And, of course, look for other instances of existing bugs.
