5 ms·

How could someone working in a security context in modern times be using non-parameterized queries? I know the answer is along the lines of "because PHP" but I

How could someone working in a security context in modern times be using non-parameterized queries? I know the answer is along the lines of "because PHP" but I just can't believe it. This really makes me paranoid regarding other security SaaS.

tptacek 7y ago
It's an old open source project that isn't really actively developed. But also: I'd resist the inclination to believe that security product companies are especially good at building secure software.
- carterehsmith 7y ago
  >> It's an old open source project that isn't really actively developed. Is it actively used?
claar 7y ago
"Because PHP" isn't the answer. PHP has had parameterized queries forever, and modern PHP looks little like the patch linked. :(
- toast0 7y ago
  For some version of forever that, to my recollection, doesn't include working with mysql 4.0. (Which was a long time ago, but still, Perl has had parameterized queries since forever via DBI, even on databases that didn't supprt them).
aneutron 7y ago
"because PHP" is absolutely not the answer. I haven't touched PHP since 5.5, but even since then, PHP had a very solid SQL interface (mysqli and most importantly, PDO), which offer a very beautiful and fully functional interface to parametrized queries à la JDBC. And even then, the PHP documentation was ALWAYS telling people "PLEASE FOR THE LOVE OF EVERYTHING THAT IS HOLY MOVE TO PDO AND STOP USING NON-PARAMETRISED APIs" But the problem is that with PHP, a LOT of the problems are usually resolved by programmers using the age old "copy pasta from a stackoverflow thread that's 10 years old". However, I do concede that for someone who's in a security context, it is absolutely narrow minded to allow ANYTHING beyond parametrized queries.
pdeuchler 7y ago
Because outside of the bubble of the top 1% of the top 1% of security teams actual software engineering knowledge is barely existent
namibj 7y ago
No parametrized PHP driver for Postgres allows pipelining queries. This is important if your talking to something non-vanilla-PG that has internal pipelining abilities to mostly elide internal latency from the transaction duration.

tptacek 7y ago

It's an old open source project that isn't really actively developed. But also: I'd resist the inclination to believe that security product companies are especially good at building secure software.

carterehsmith 7y ago
>> It's an old open source project that isn't really actively developed. Is it actively used?

claar 7y ago

"Because PHP" isn't the answer. PHP has had parameterized queries forever, and modern PHP looks little like the patch linked. :(

toast0 7y ago
For some version of forever that, to my recollection, doesn't include working with mysql 4.0. (Which was a long time ago, but still, Perl has had parameterized queries since forever via DBI, even on databases that didn't supprt them).

aneutron 7y ago

"because PHP" is absolutely not the answer. I haven't touched PHP since 5.5, but even since then, PHP had a very solid SQL interface (mysqli and most importantly, PDO), which offer a very beautiful and fully functional interface to parametrized queries à la JDBC. And even then, the PHP documentation was ALWAYS telling people "PLEASE FOR THE LOVE OF EVERYTHING THAT IS HOLY MOVE TO PDO AND STOP USING NON-PARAMETRISED APIs" But the problem is that with PHP, a LOT of the problems are usually resolved by programmers using the age old "copy pasta from a stackoverflow thread that's 10 years old". However, I do concede that for someone who's in a security context, it is absolutely narrow minded to allow ANYTHING beyond parametrized queries.

pdeuchler 7y ago

Because outside of the bubble of the top 1% of the top 1% of security teams actual software engineering knowledge is barely existent

namibj 7y ago

No parametrized PHP driver for Postgres allows pipelining queries. This is important if your talking to something non-vanilla-PG that has internal pipelining abilities to mostly elide internal latency from the transaction duration.