Fuzzing Go APIs for SQL Injection • Hacker News Board

Re: Fuzzing Go APIs for SQL Injection

#21

Post by sa46 » Thu, Sep 01, 2022, 4:02 AM UTC

spullara wrote: post #3

People are still constructing SQL statements using user provided data? Have they never used prepared statements before?

Prepared statements (in Postgres) don't work for:

- 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.

Re: Fuzzing Go APIs for SQL Injection

#22

Post by dancosta0601 » Thu, Sep 01, 2022, 5:30 AM UTC

andrei wrote: post #9

KingOfCoders wrote: post #7

Is there a open source fuzzing framework for Go?

As of go 1.18, fuzzing is built into the toolchain itself, and is what we're using in this post. We go over the basics here [0], if you'd like to start at the beginning [0]: https://blog.fuzzbuzz.io/go-fuzzing-basics/

Thanks!

Re: Fuzzing Go APIs for SQL Injection

#23

Post by spullara » Thu, Sep 01, 2022, 7:40 AM UTC

sa46 wrote: post #21

spullara wrote: post #3

People are still constructing SQL statements using user provided data? Have they never used prepared statements before?

Prepared statements (in Postgres) don't work for: - 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.

Then you can't allow users to provide them. They must be constructed with constraints.