h.db.Exec(fmt.Sprintf("insert into users(name, email, phone_number) values ('%s', '%s', '%s');",
request.Name, request.Email, request.PhoneNumber))
h.db.Exec("insert into users(name, email, phone_number) values (?, ?, ?);",
request.Name, request.Email, request.PhoneNumber)
Now, shitty HTML templating causing injection with unsanitized user input is a lot more realistic, since the golang templating story isn’t great.
Edit: “templating” -> “HTML templating”.
Even then, the approach of "just do it right the first time" is fallible. People have varying degrees of experience, and people have brain farts and type the wrong thing instead of the write thing. Your job as the technical lead is to have some sort of process in place to catch these things before they become security disasters. "Sorry, our junior engineer didn't know about prepared statements," is not something you want to tell your customers whose data was exfiltrated. The current industry standard here would be "cross your fingers and hope for the best", and that's why everyone knows your social security number and have opened 6 credit cards in your name. Fuzzing is another layer of sanity checking, on top of static analysis (where I think this issue should be caught), code reviews, and just typing in the correct code in the first place.
At the end of the day, this just another example of how you could use fuzzing to detect problems that other things missed. That's valuable, as even with 100% code coverage and turning on all the lint checks, software still has bugs. Here's a tool that can help reduce the bug count.
Templating and `fmt.Sprintf` are essentially the same thing in this context - `Sprintf` just gets the point across in fewer lines of code, and allows people to come up with realistic scenarios themselves.
That being said, we wanted to highlight an example of how fuzzing can be applied to a typical (albeit, toy) API to find logic bugs, and figured SQL Injection would be something that resonated with most (all?) developers.
EDIT: I tried using fuzz testing to find the famous issue with integer overflows in binary search [1], but even when restricting the relevant type to uint8, a couple of minutes of fuzzing when running on gitpod.io didn't detect an issue. Repo is https://github.com/DylanSp/fuzzing-for-binary-search-overflo... if anyone wants to play around with it and see if they can get fuzzing to detect a problem. (Go doesn't panic on overflows; a different approach to creating the slice to search might reveal a logic error)
[1] https://ai.googleblog.com/2006/06/extra-extra-read-all-about...
- Dynamically generated queries, like a user specifying a query predicate via a UI.
- Dynamically selecting an identifier, like `SELECT * FROM $1` or `SELECT $1, count(*) FROM foo GROUP BY $1`.
You can use cleverness with types to parse user-provided data into a struct that emits sanitized SQL, but under the hood, there are only strings.
bun, I'm looking at you...
* IMHO there is not even any good reason to use an ORM whatsoever (unless, perhaps, you're building something very very very very very specific that needs to deal with very very very generic data).
Would love to hear others' experience with Go fuzzing now that it's been out for a few months.
We go over the basics here [0], if you'd like to start at the beginning