Hacker News new | past | comments | ask | show | jobs | submit login

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.



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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: