Go programming language secure coding practices guide | Hacker News Reader

Go programming language secure coding practices guide

github.com

225 pointsrbanffy17 comments

Taking some random samplings of the content, this appears to be mostly rehashed OWASP Wiki content with some random, incomplete Go snippets. The password hashing content is particularly bad (unsurprising, since OWASP's password hashing content is bad). The sections are inconsistent (for instance: the crypto section recommends "AES", demonstrates [without explaining] AES-GCM, and the data protection section recommends Nacl). Very little of it addresses any kind of pitfall of programming in Go. There are places where the authors seem confused about basic Go data types (for instance, between slices and maps).

I assume this is just a starting point, and I get that bootstrapping a book from OWASP content is a legitimate way to create a starting point; I'd just say: this is definitely an early starting point.

One thing that I've noticed in the Golang community, is that there is some disturbingly large number of programmers there who think it's a very good idea not to use prepared statements and instead to use Input Escaping.

https://www.reddit.com/r/golang/comments/62513u/golang_persi...

The justification? Better performance. Didn't the PHP community go through the exact same thing years ago? (With people finally giving up and going back to prepared statements for safety against SQL injection.)

It's so widespread that there are multiple libraries that tout this as a feature!

I have not noticed this reviewing code for clients, and would be equally disturbed --- anyone suggesting that prepared statements should be avoided in favor of escaping is perpetuating a dangerous falsehood.

The link you posted to support your claim demonstrates exactly the contrary: the person supporting that argument has been downvoted to oblivion until they saw fit to delete their account.

As far as I can see, the last part of your assertion is false. For their username, you need to include a trailing slash.

OMG. How would escaping be faster than prepared statements if prepared statements are literally cached in the database server instead of re-parsing and re-planning every time?! o_0

To be fair, it can be faster if the binds cause the plan to be much more efficient. I've had to remove binds before for this very reason.

Note that this was exactly once in 20 years.

It happens. https://bugs.mysql.com/bug.php?id=73056

PHP's PDO database abstraction layer actually escapes by default under the hood, but it presents a prepared statement interface.

You can turn that off. It was there historically because mysql didn't always support it, and it was slow when it was first rolled out.

Other languages old enough to have been around prior to all this have the same history. Perl, Python, etc.

> It's so widespread that there are multiple libraries that tout this as a feature!

Which libraries?

AFAIK prepared statements don't let you change which table to use them for dynamically? Or am I misunderstanding something?

They don't, but they still offer better speed and security than non prepared statement.

And having to dynamically change a table name is uncommon.

Do you know other resources to learn from besides OWASP for web application security?

Glad to see any doc published that gets developers thinking more about security...

One "trend", or rather bad habit that I've noticed a lot in discussion with other developers recently, and this doc also falls into, is that there seems to more focus on "input sanitisation" rather than "output escaping".

Regardless of what's been done to input, if the result is that you have a string that you need to embed into another string, then you need to know how to escape that appropriately for the context in which it's being used. Whether the data is user generated, or taken from your database, always assume that it's trying to break your app, and always escape it on output.

Direct link to web book: https://checkmarx.gitbooks.io/go-scp/content/

"Don't use Go." FTFY. (Use a language that makes entire classes of security problems impossible, such as memory-safe languages with nothing akin to a "null pointer".)

Reply on news.ycombinator.com