Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
doubleback
Doubleback provides round-trip parsing and printing of 64-bit double-precision floating-point numbers using the Ryu algorithm implemented in multiple programming languages. Doubleback is biased towards "human-friendly" output which round-trips consistently between binary and decimal.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
At simplest and most straight forward level fuzz testing is pretty simple to get started with. Collect some input(API calls, files, etc.), pass it to fuzzer(for example radamsa[0]), throw it at program and observe...
Ofc, depending on system collecting input and sending it to system might be bit more complicated. Hardest part is often the observing and finding that an error happens.
Not that this gets you full coverage, for more complex things like protocols something custom that takes lot more effort is probably needed.
[0] https://gitlab.com/akihe/radamsa
[1]: https://guidovranken.com/2019/05/14/differential-fuzzing-of-...
Microsoft’s OneFuzz is tackling some of these issues
https://github.com/microsoft/onefuzz
The biggest problem with fuzzing when it comes to “developer friendliness” isn’t just how to setup the fuzzer and the fact that you need to often write quite a bit of additional code to support fuzzing but that the results aren’t easily consumable.
Getting a fuzzer to cause a crash or some unhandled exception isn’t particularly difficult understanding the actual implication of such crash is where these tools “fail”.
SAST / DAST tools with all their issues such as false positives and relatively limited coverage at least provide actionable results.
Fuzzing not only requires a much higher understanding of the code itself and of its execution but the results are often useless for many developers.
Basically it doesn’t help you breach the gap between seeing a BSOD or a kernel panic and getting a working zero day.
The link below is a relatively simple example of differential fuzzing between implementations in different programming languages using AFL. It works by reading and writing to a second process it spawns and aborting on differences. Before writing this, I could not find any working examples of this technique, although I'm sure they are out there, somewhere.
https://github.com/ironmeld/doubleback/blob/main/src/c/tests...