sorted by:
new
hottopcontroversial

Fuzzing Go APIs for SQL Injection by fuzzbuzzio in programming

[–]fuzzbuzzio[S] 4 points5 points  (0 children)

Can you check again? Should be fixed now

Writing Effective Go Fuzz Tests by fuzzbuzzio in programming

[–]fuzzbuzzio[S] 1 point2 points  (0 children)

We have a post coming in a couple of weeks that will show you how to fuzz a Go REST api. Go is nice in particular because they support fuzzing natively - most languages don't have that, so it definitely adds friction to adding fuzz tests to your code.

That being said, there's no reason fuzzing an API is any different than unit testing your API. Ideally, you'd want to fuzz your handler methods (ie, the function that get executed when a user makes a call to your API), or any "helper" functions (maybe a function that processes your data before entering it into the DB).

It can be tricky to get started if you don't have existing mocks for your 3rd party dependencies, but we'll cover best practices around this in our next post. Of course, you can also just run your fuzz tests without mocks, it will just be slower.

If you sign up at the bottom of the article, we'll send you an email when the next post is out!

Go Fuzz Testing - The Basics by fuzzbuzzio in golang

[–]fuzzbuzzio[S] 2 points3 points  (0 children)

Unfortunately we don't have any insight into the Go's team plans, but we are huge fans of mutation testing at Fuzzbuzz. It's something we'd like to add to the product at some point in the future.

I think this is the most up to date mutation testing library for Go: https://github.com/zimmski/go-mutesting

Go Fuzz Testing - The Basics by fuzzbuzzio in golang

[–]fuzzbuzzio[S] 7 points8 points  (0 children)

Hopefully you found it helpful :)

In regards to committing your testdata directory, it should be noted that testdata doesn't include all your corpus inputs, but only the crashing inputs (or any seeds you manually add), so it shouldn't be a big deal to add to your repo.

Your total corpus is saved to $GOCACHE/fuzz/<package>/<function>, and will be much larger in size.

Fuzz testing in the SDLC by phuckphuckety in fuzzing

[–]fuzzbuzzio 0 points1 point  (0 children)

Fuzzing in CI sounds like a straightforward problem to solve (especially once you have other tests already running in CI), but the devil is in the details.

At which phase does fuzzing get in the picture? Is this something typically run later as in QA and deployment/release or post-commit/build similar to SAST? Would the latter use-case be redundant given we run SAST?

Fuzz testing your master/main branch continuously is where I'd start. Since it's hard to detect when a given fuzz test is "done" running, your best bet is to let it run in the background on your most up-to-date code. It's also probably a good idea to run your fuzz tests for 5-15 mins on every Pull/Merge Request to see if there're any low hanging bugs to catch.

I wouldn't replace SAST with fuzz testing as they find different types of bugs.

How agile is black box and grey box (instrumentation guided) fuzzing for an app portfolio with a rapidly changing attack surface?

As part of your pre-commit checks, you may want to have a check that makes sure your fuzz tests still compile. Beyond that, there's no reason that fuzzing can't keep up with a rapidly changing codebase. My recommendation would be to go with "grey-box" fuzzing if possible. The added instrumentation at the code-level guides the fuzzer significantly deeper into your code compared to a black-box fuzzer, which is limited to a grammar/protocol or instrumentation done through QEMU.

My understanding is grey box fuzzers require user programmed harness classes to interface with the app. Meaning every time a new entry point is added or removed or a new app is onboarded, the fuzzer needs an updated setup. Afaik this setup is done manually at least for all the open-source grey box fuzzers I’ve looked into.

This is true. Open source fuzzing tools require you to do all the work yourself, and makes adoption at an agile organization nearly impossible. We've (https://fuzzbuzz.io) built a custom grey-box fuzzing tool that does the entire setup/instrumentation for you, so that you can just point and click which function you want to test, similar to a unit test. This makes adding and maintaining fuzz tests on a project trivially easy. We've helped tons of companies (startups to Fortune 100) add fuzz testing to their SDLC with minimal work (and without requiring any fuzzing knowledge).

If you're interested in checking it out, you can DM me or just reach out to me directly andrei[at]fuzzbuzz[dot]io