Re:Go programming language secure coding practices guide
by stcredzero on Tuesday April 25, 2017 @06:01PM
(#14198515)
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!
Re:Go programming language secure coding practices guide
by tptacek on Tuesday April 25, 2017 @06:10PM
(#14198589)
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.
Re:Go programming language secure coding practices guide
by nawre on Tuesday April 25, 2017 @07:43PM
(#14199289)
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.
Re:Go programming language secure coding practices guide
by stcredzero on Tuesday April 25, 2017 @08:12PM
(#14199431)
As far as I can see, the last part of your assertion is false. For their username, you need to include a trailing slash.
Re:Go programming language secure coding practices guide
by floatboth on Tuesday April 25, 2017 @06:30PM
(#14198744)
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
Re:Go programming language secure coding practices guide
by mohaine on Tuesday April 25, 2017 @08:41PM
(#14199565)
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.
Re:Go programming language secure coding practices guide
by tyingq on Wednesday April 26, 2017 @07:46AM
(#14202193)
It happens. https://bugs.mysql.com/bug.php?id=73056
Re:Go programming language secure coding practices guide
by TazeTSchnitzel on Tuesday April 25, 2017 @06:19PM
(#14198655)
PHP's PDO database abstraction layer actually escapes by default under the hood, but it presents a prepared statement interface.
Re:Go programming language secure coding practices guide
by tyingq on Wednesday April 26, 2017 @12:47AM
(#14200498)
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.
Re:Go programming language secure coding practices guide
by Zikes on Wednesday April 26, 2017 @12:53AM
(#14200519)
> It's so widespread that there are multiple libraries that tout this as a feature!
Which libraries?
Re:Go programming language secure coding practices guide
by literallycancer on Tuesday April 25, 2017 @07:32PM
(#14199205)
AFAIK prepared statements don't let you change which table to use them for dynamically? Or am I misunderstanding something?
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.