Security assessment techniques for Go projects

Re:Security assessment techniques for Go projects by tptacek on Friday November 08, 2019 @08:31AM (#21481979)

Oh, you are, to the extent that you are when you directly use parameterized queries anywhere (ie, there are corner cases). But unlike Java-world and Python-world and Ruby-world, there aren't really idiomatic mainstream heavyweight database interfaces in Go-world, so if your application is dynamically composing its own SQL queries, which many serious applications end up doing, you can end up with concatenated SQL and the attendant bugs.

I'm not going to go into a fresh Django project optimistic about my chances of finding SQLI, but a database-heavy Go program, that's one of the first things I'm going to take a whack at.

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by pritambarhate on Friday November 08, 2019 @09:37AM (#21482507)

Just putting it out there to spread the word: sqlx[1] and sqlz[2] Go libraries are very good. They take a lot of pain out of mapping Go structs to resultsets and also prevent SQL Injection. sqlx seems to be quite popular but sqlz could do with some love.

[1] https://github.com/jmoiron/sqlx [2] https://github.com/ido50/sqlz

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by jeremyjh on Friday November 08, 2019 @08:48AM (#21482083)

Do you think Go might have better DB libraries if generics ever land? Or what else might be holding it back?

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by tptacek on Friday November 08, 2019 @09:00AM (#21482164)

I don't know. I wrote a code-generating ORM for my own projects, which is what I use. But lack of generics isn't, for example, what makes Go projects hew so closely to net/http and net/http compatible interfaces, rather than the more elaborate interfaces people write in Python and Ruby; there's also just a "less is more" ethos in Go-world.

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by SEJeff on Friday November 08, 2019 @10:34AM (#21483100)

You don't think gorm is mainstream? It isn't the only choice, but is used pretty extensively.

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by henvic on Thursday November 14, 2019 @04:54AM (#21534203)

gorm (or any other ORM for that matter) is no silver bullet and just introduces unwanted complexity in the code.

Now, instead of being able to quickly see a query in one place what commonly happen is people breaking down all things and creating "helper" functions in strange ways to select, limit, order, and any other stuff, and ending up with something so complex you waste a lot of time to understand and only the original writer knows where to find anything. For me, this adds way more issues than any security concerns you might have related to learning SQL properly, too – and if you are using an ORM chances are you already know how SQL works anyways (and you can use static analysis tools to reduce the errors, plus the reduced cognitive load in using vanilla SQL).

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by jgrpf on Friday November 08, 2019 @10:58AM (#21483421)

We use it on all our projects though it really needs improved/additional m:n handling.

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by tptacek on Friday November 08, 2019 @10:41AM (#21483191)

I'm familiar with gorm, but haven't seen it at any of our clients.

[ Parent | on HN ]

Re:Security assessment techniques for Go projects by SEJeff on Friday November 08, 2019 @10:55AM (#21483381)

Fair, perhaps we can fix that with an audit soonish :)

[ Parent | on HN ]