11–16 of 16 posts
Seems in my mind to be a nice complement to achieving code-coverage with testing i.e. whereas unit/integration testing might test the various code paths with a few good/bad values, this then throws every possible input value at them to see what breaks.
This fuzzing is interesting stuff. Does anyone know of an in-process or otherwise lib for the JVM? Findbugs is mentioned in here but I'm not sure if that does fuzzing (maybe a plugin?). Seems in my mind to be a nice complement to achieving code-coverage with testing i.e. whereas unit/integration testing might test the various code paths with a few good/bad values, this then throws every possible input value at them t…
I'm new to fuzzers and fuzz testing in general so I apologise for my ignorance about the purpose of fuzzing. My understanding is that fuzzing tests the user facing side (which is what is important for most programs). Does there exist similar tooling for testing the system-facing side (i.e. the stack below your application) to check your applications error handling, for example and uncover corner cases. What I'm getti…
It seems that wrapping select()/read()/write() to have random readability/writability/closing seeded by a fuzz input might exercise those code paths. I'm yet to implement it though - be interested to hear of prior work. Getting the fuzz input corpus to correlate to program actions might be problematic.
This fuzzing is interesting stuff. Does anyone know of an in-process or otherwise lib for the JVM? Findbugs is mentioned in here but I'm not sure if that does fuzzing (maybe a plugin?). Seems in my mind to be a nice complement to achieving code-coverage with testing i.e. whereas unit/integration testing might test the various code paths with a few good/bad values, this then throws every possible input value at them t…
To put it another way - PIT runs your unit tests against automatically modified versions of your application code. When the application code changes, it should produce different results and cause the unit tests to fail. If a unit test does not fail in this situation, it may indicate an issue with the test suite.
This fuzzing is interesting stuff. Does anyone know of an in-process or otherwise lib for the JVM? Findbugs is mentioned in here but I'm not sure if that does fuzzing (maybe a plugin?). Seems in my mind to be a nice complement to achieving code-coverage with testing i.e. whereas unit/integration testing might test the various code paths with a few good/bad values, this then throws every possible input value at them t…
Not exactly a fuzzer in the sense of afl but there is EvoSuite[1]. It automatically generates JUnit tests that try to satisfy a coverage criterion. [1] http://www.evosuite.org/
This notes that they disabled reading config files in order to own life as the default setup. I assume that with more time it would be wise to try and fuzz as many configured options as possible as well?
Even simpler, shouldn't the configuration be part of the fuzzed input?
It might be a good idea to check the parser for bugs but these aren't real security issues.