Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fuzzing Go APIs for SQL Injection

blog.fuzzbuzz.io

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Fuzzing Go APIs for SQL Injection

#11

Post by oefrha »

spullara wrote: post #3

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

Looks more like a contrived example to me:

  h.db.Exec(fmt.Sprintf("insert into users(name, email, phone_number) values ('%s', '%s', '%s');",
       request.Name, request.Email, request.PhoneNumber))
Any database driver including database/sql will support

  h.db.Exec("insert into users(name, email, phone_number) values (?, ?, ?);",
       request.Name, request.Email, request.PhoneNumber)
which is shorter and more natural. They’re throwing in a fmt.Sprintf in there for no reason other than forcing a tired old SQL injection.

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

Re: Fuzzing Go APIs for SQL Injection

#12

Post by evmunro »

oefrha wrote: post #11
spullara wrote: post #3

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

Looks more like a contrived example to me: h.db.Exec(fmt.Sprintf("insert into users(name, email, phone_number) values ('%s', '%s', '%s');", request.Name, request.Email, request.PhoneNumber)) Any database driver including database/sql will support h.db.Exec("insert into users(name, email, phone_number) values (?, ?, ?);", request.Name, request.Email, request.PhoneNumber) which is shorter and more natural. They’re thro…

You're right, it's likely that almost nobody is using `fmt.Sprintf` to build SQL queries in production.

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.

Re: Fuzzing Go APIs for SQL Injection

#13

Post by jrockway »

oefrha wrote: post #11
spullara wrote: post #3

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

Looks more like a contrived example to me: h.db.Exec(fmt.Sprintf("insert into users(name, email, phone_number) values ('%s', '%s', '%s');", request.Name, request.Email, request.PhoneNumber)) Any database driver including database/sql will support h.db.Exec("insert into users(name, email, phone_number) values (?, ?, ?);", request.Name, request.Email, request.PhoneNumber) which is shorter and more natural. They’re thro…

It doesn't really matter that it's contrived. It's hard to show the value of something in a large system, because 90% of the blog post will be understanding that large system. So you have to pick something that is immediately obviously wrong, and let the reader make the jump to how this would actually be useful in the context of their own larger system.

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.

Re: Fuzzing Go APIs for SQL Injection

#14

Post by henvic »

spullara wrote: post #3

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

I'm afraid that even on the Go ecosystem you'll find people relying on ORMs that doesn't even use server-side prepared statements, but escapes queries ¯\_(ツ)_/¯

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

Re: Fuzzing Go APIs for SQL Injection

#15

Post by oefrha »

evmunro wrote: post #12
oefrha wrote: post #11

Earlier quoted context omitted.

Looks more like a contrived example to me: h.db.Exec(fmt.Sprintf("insert into users(name, email, phone_number) values ('%s', '%s', '%s');", request.Name, request.Email, request.PhoneNumber)) Any database driver including database/sql will support h.db.Exec("insert into users(name, email, phone_number) values (?, ?, ?);", request.Name, request.Email, request.PhoneNumber) which is shorter and more natural. They’re thro…

You're right, it's likely that almost nobody is using `fmt.Sprintf` to build SQL queries in production. 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.

I’m talking about HTML templating, not templating SQL statements.

Re: Fuzzing Go APIs for SQL Injection

#16

Post by intelVISA »

andrei wrote: post #2

A lot of folks we talk to think fuzzing is only useful for finding memory leaks in C++ programs, so we wanted to show how adding a single fuzz test to your API can find SQL injection and other logic bugs. Would love to hear others' experience with Go fuzzing now that it's been out for a few months.

Fuzzing everything is absolutely essential imo.

Re: Fuzzing Go APIs for SQL Injection

#18

Post by pjmlp »

KingOfCoders wrote: post #8
spullara wrote: post #3

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

Yes, it feels dated since JDBC brought prepared statements into the mainstream literally decades ago. Though I have seen this still happening from marketing hiring external marketing agencies to write some small apps for them, e.g. a web game for grabbing email addresses. Hopefully they don't have access to your main database (though I have seen this in startups too, because fast,fast,fast).

ODBC, ADO and Perl DBI did it even earlier.

Re: Fuzzing Go APIs for SQL Injection

#19

Post by DylanSp »

andrei wrote: post #4
spullara wrote: post #3

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

It's much more common than you may think - especially at larger organizations where engineers go "off-script" frequently. 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.

It's fairly obvious that it's a contrived example, though, which means it's not much of a motivating example for fuzz testing. I'd think it'd help to have a non-obvious bug that's triggered by an unusual set of inputs; that would show the value of fuzz testing mich better. (Admittedly, this is easier said than done)

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

Re: Fuzzing Go APIs for SQL Injection

#20

Post by KingOfCoders »

pjmlp wrote: post #18
KingOfCoders wrote: post #8

Earlier quoted context omitted.

Yes, it feels dated since JDBC brought prepared statements into the mainstream literally decades ago. Though I have seen this still happening from marketing hiring external marketing agencies to write some small apps for them, e.g. a web game for grabbing email addresses. Hopefully they don't have access to your main database (though I have seen this in startups too, because fast,fast,fast).

ODBC, ADO and Perl DBI did it even earlier.

Agree, my first database driven website was with DBI (also writing the German Strato web and mail plattform) in the 90s with Hughes mSQL and Delphi ODBC, my feeling though was JDBC brought database driven websites to the mainstream.
Post reply on HN