10 ms·
In PHP's case, Stack Exchange is not necessary to get SQL injected tutorials. The official docs for _years_, if not decades, included them. The docs for how you
by kadoban 5y ago
In PHP's case, Stack Exchange is not necessary to get SQL injected tutorials. The official docs for _years_, if not decades, included them. The docs for how you were supposed to do SQL were just full of the antipattern of building queries by string formatting and concatenation. I wouldn't be surprised if some dark corner of the docs still had those available.
- nine_k 5y ago"Else you are not getting the authentic php4 experience!" /s PHP has been in a poor shape for many, many years. It started shaping up in last rather few years, and there is a large backlog to tackle, colossal if you include all the numerous tutorials and Q&As from getting copy-pasted since 2000.
- mschuster91 5y agoThe language never was the problem, not since PHP 5.1 at least (which introduced PDO) and that is 16 years ago. The problem always was the ecosystem that took decades to update and the fact that Google's search is algorithm-ranked and not supposed to be curated by humans, which would have kicked out at least the most horribly insecure stuff.
- jeltz 5y agoI disagree. As someone who has used PDO a lot it still makes it unnecessarily hard to use parametrized queries compared to the libraries available in most other languages, even C (at least for PostgreSQL). The pgsql library for PHP is also pretty good, better than PDO.
- habibur 5y agoBut, you need to write the hard thing once. In a 10 line wrapper function and then call that function from everywhere. sql_query($db,$sql,$params); Problem solved. I guess every PHP developer writes a bunch of these wrapper functions for common sql tasks before he starts his work.
- porker 5y agoOr installs Doctrine DBAL which handles it all for you. At the cost of some performance, but the ease-of-use with a highly-tested and relied-upon library normally outweighs that.
- Cthulhu_ 5y agoYup, make it work (securely!) before making it fast; you can't diagnose performance if your code isn't working as it should in the first place (and SQL injection safety is a non-functional requirement; you can't consider code working if there's that weakness). In practice, bad database design or access (like the n+1 problem) will weigh heavier than the overhead added by a library like Doctrine. Or, it should, if Doctrine adds THAT much overhead it's a problem.
- arp242 5y agoThis is the most PHP comment in this thread yet; "yeah, I know this very basic API is inadequate and broken, but you can just write a wrapper, everyone is writing the same wrappers anyway!" Is PHP supposed to be a high-level language or what? Hell, I'd consider it a very flimsy excuse even in C (in most contexts anyway).
- tored 5y agoAlready answered in this thread. There is nothing hard or wrong about the API. It is just lots of misunderstandings and commentators not looking things up before commenting. $stmt = $pdo->prepare('INSERT INTO user (email) VALUES(?)'); $stmt->execute([$email]); https://news.ycombinator.com/item?id=27954454 https://news.ycombinator.com/item?id=27954454
- tored 5y agoYou can do parametrized queries in two lines of code with PDO. I wouldn't classify that as "unnecessarily hard", sure you could split in half to one line of code, for that you need to write your own wrapper function.
- toast0 5y agoI mean, PDO wasn't great (in contrast to perl's DBI which was pretty good and offered parameterized queries even if the underlying interface didn't), so it made sense to prefer mysql_query. But mysql_query didn't do parameters, and mysqli did, but only it you ran a new enough version of MySQL. I wouldn't call it a language failure per se, but a problem with the libraries that shipped with the language. That distinction may not make a difference. Bad examples that stuck around don't help either, of course.
- kadoban 5y agoLong after PDO was a thing, the official docs still included the old insecure jank. Is your contention that Google is to blame for indexing them?
- acdha 5y agoPDO was slower, the interface - critically - tons of examples still either made prepared statements a side note or actively encouraged string concatenation, and it preserved the flaws of the previous interfaces like ignoring errors and warnings (silent is no longer the default in PHP 8). I no longer consider myself part of the PHP community (started around 1999), in part due to the low priority reliability and security had. It was exhausting having to vet code so frequently because even experienced developers forgot all of the rakes in the grass.
- deleted 5y ago[deleted]
- sellyme 5y ago> The docs for how you were supposed to do SQL were just full of the antipattern of building queries by string formatting and concatenation This is still to this day the recommended way to construct a "WHERE foo IN (a,b,c,...)" query in PHP. It's insane that there's no way to pass an array of values into a parameterised query for that use case.
- path411 5y agoWhat do you mean? You can Google php parameterize query and get atleast 2 different methods of doing this. You shouldn't ever touch string concat in any language when doing queries
- sellyme 5y ago> You can Google php parameterize query and get atleast 2 different methods of doing this There's no way of doing this with a single parameter. You need to parameterise every single individual item in the IN clause to do it that way, which is a horrific solution when it's of a completely unknown length. Still better than string concatenation in many cases, but that the language has no in-built way of doing it is one of the many reasons PHP code is so often vulnerable to injection attacks. There's so much friction to writing secure code.
- ec109685 5y agoBetter is to concatenate question marks and then pass the params as an array.
- tored 5y agoYes, something like this $user_ids = [1, 6, 46, 3, 17]; $count = count($user_ids); $in = '(' . implode(', ', array_fill(0, $count, '?')) . ')'; $sql = "SELECT user_id, email FROM user WHERE user_id IN {$in}"; $stmt = $pdo->prepare($sql); $stmt->execute($user_ids); var_dump($stmt->fetchAll());
- throwawayboise 5y ago
- nkozyra 5y ago> I wouldn't be surprised if some dark corner of the docs still had those available. It's not exactly a dark corner, but at least there's red boxes all over the place. Back in the 5.x early days it had disclaimers but clearly not enough to discourage people from keeping unsafe code in place.
- tyingq 5y agoTo be fair to PHP, a lot of other languages had bad examples around as well. Pretty much every language has a way to do string interpolation on untrusted input and pass it to to a database .
- kaba0 5y ago> Pretty much every language has a way to do string interpolation on untrusted input and pass it to to a database Otherwise they would not be Turing complete.. but defaults/easiest route does matter very much in this case.
- SilverRed 5y agoAnd the default docs and tutorials. If you look at Ruby on Rails. The way every tutorial will show makes it impossible to get an sql injection. Then as you gain more skill you will eventually find the function that lets you run a string query but no guide or tutorial shows you this so it is less likely you will use it without understanding.
- codedokode 5y agoRuby and Rails tutorial is not a Ruby tutorial. The ancestor comment talked about language tutorials, not framework tutorials.
- kaba0 5y agoJDBC does have an option to pass parameters without doing string interpolation and I would not consider it a framework.
- tyingq 5y agoI don't mean going through hoops. String interpolation is easy in most languages. See https://news.ycombinator.com/item?id=27958651 https://news.ycombinator.com/item?id=27958651 for example.
- flomo 5y ago
- mike_d 5y ago> The official docs for _years_, if not decades, included them. The docs for how you were supposed to do SQL were just full of the antipattern of building queries by string formatting and concatenation. PHP directly exposed the libmysqlclient C library. Any language that provides the ability to send a raw SQL query (hint: almost all of them) has documentation you can copy and paste to introduce an injection vulnerability. You'll find injection vulnerable examples in the MySQL docs themselves: https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-query.html https://dev.mysql.com/doc/c-api/8.0/en/mysql-real-query.html
- iamgopal 5y agoMySQL docs shouldn’t worry about injection.
- mike_d 5y agoSo why should Perl, Go, PHP, or Rust?
- cerved 5y agobecause it's serious if it's a web server?
- deleted 5y ago[deleted]
- thallium205 5y agoBecause not everything that uses MySQL is a web server?
- iamgopal 5y agoBecause those language are usually used at application level, and application does need to worry about wrong input. Databases doesn’t need to worry about if some correct security level input ask to delete the database , it should delete it, not to question the input , but at application level , that is not acceptable. How much simpler can this get ?
- mlang23 5y agoIn defense of PHP, this is probably due to simplicity. PHP got many people started with server side web development, and docs were supposed to be "simple". The thinking back then probably was "if we make the example more complicated, we will loose people", which was probably even true for the target audience.
- prox 5y agoWhen I started like this, I always followed up with a google query for securing what I did. Not the best way to learn, but as you say, it got you started.
- pdimitar 5y agoI don't see this as a defense, I am seeing it as a way to reach to more programmers, and basic security practices be damned in the process. I have to wonder: what did these people have to gain if PHP got popular (which it did)? That's an egotistical way of popularizing your language.
- tored 5y agoNow do C.
- pdimitar 5y agoI know right. That's why I'm not doing C anymore, for 10+ years now.
- tored 5y agoWas Dennis Ritchie egotistical for popularizing C? He would have known all the security flaws in it, right?
- pdimitar 5y agoVery disagreed with your analogy. By the time those PHP tutorials were written, SQL injection attacks were already known. So not sure what you're trying to push here but I refuse to participate.
- ssully 5y agoMy first job while in school was doing web development with a LAMP stack. I had zero PHP experience, so it was 100% learning on the job and my learning resources were basically the official docs, a PHP book (can't remember which) I got at a book store, and stackoverflow. PHP has a very forgiving design; it makes it very easy to get any trash code up and running. It really is great for newbies to get their hands dirty. I look back fondly on that first job, but boy did I have to unlearn a lot of bad lessons from those days.