> It made security testing a nightmare and most of the assertion failures I ran into were completely pointless.
Just to clarify for me, what you're saying is that:
1) instead of asserts for invalid input validation, they should have just returned the appropriate error code
2) so that the fuzzing harness could continue with the run rather than just keep dying?
> It was for embedded firmware, and I always ran tests (including security tests)
You had me going there for a minute. lol. :)
TIA.
Re:Write Fuzzable Code
by Sohcahtoa82 on Sunday September 01, 2019 @08:53PM
(#20855962)
Correct.
Basically, I'd see code that looked like this:
assert(isNumeric(userInput));
if (!isNumeric(userInput)) {
return ERR_INVALID_INPUT;
}
I used to work for a company that used asserts as general error checking and it was awful. It was for embedded firmware, and I always ran tests (including security tests) with debug firmware. Non-debug firmware had asserts disabled. On debug firmware, a failed assert would cause a complete crash with the display showing the source code file and line number of the failed assert.
Some developers were using asserts on simple user input. For example, this firmware had a web server with a REST API. One of the APIs would expect a number as a parameter, and the person doing development added an assert() statement to make sure the API received a number and not letters or other characters.
It made security testing a nightmare and most of the assertion failures I ran into were completely pointless.