5 ms·

Your comment doesn't seem "in fairness" at all. Can you tell me which language is impervious to SQL vulnerabilities? Is there some magic language out there tha

Your comment doesn't seem "in fairness" at all. Can you tell me which language is impervious to SQL vulnerabilities? Is there some magic language out there that cleans all external input for you? Pick a language, any language, and you will just about always find that GET and POST variables aren't cleaned for you and rightly so! The language should be a tool to let you do whatever you want and leave it up to the programmer to clean input. Now, if you want to talk about frameworks that's a different story. You picked one site with one tutorial and based off that have basically proclaimed PHP to be an insecure language. For every tutorial that skips over security or has some mistake or vulnerability there are others out there that don't. The one you chose is in PHP but you can find tutorials in any language with the same flaws. We all get it by now. PHP is lame and it's cool to bash it. It has a history of being crappy. Fine, we know. But PHP in past couple of years has begun to address those flaws and has come a long way. Now that it's starting to get better people seem to want to cheer for it to fail. No matter how uncool it is it's still incredibly popular even among people here on HN. It's just that they don't like to talk about it out loud because of the stigma it now has among the language snobs. I mean, come on man. Was this really in fairness or just another cheap and easy shot. An opportunity to pile on. And to address the quote you mention... the web may still have a lot of those old and awful tutorials but that doesn't mean the community hasn't learned. More recent tutorials and information you find online is much better and the community is far more cognizant of PHPs vulnerabilities and are now using best practices far more frequently. It's always fun to bash PHP but let's just give credit where credit is due. It has taken enough steps in the right direction for it to be worthy of people taking notice. EDIT: Also, the tutorial site you linked to is actually quite good. Tutorials are tutorials, not technical manuals. So when you want to show someone how to, for example, take GET or POST input and manipulate it somehow you want to focus on that and not explain every little thing like all the ways your GET or POST array can kill you via XSS or SQL injection. You might mention in passing that you'd better clean your input but unless the article is about sanitizing and escaping inputs itself I don't see why it has an obligation to go into that much depth.

pavel_lishin 14y ago
> Can you tell me which language is impervious to SQL vulnerabilities? That's not the point. The point is that PHP tutorials/books/best practice guidelines repeatedly and consistently do this sort of thing. Even "PHP: The Good Parts" spent most of the chapter on SQL without mentioning security until the very last part, where they sort of waved their hands at it.
- bpatrianakos 14y ago
  Security is important, and I can't say your concern over it is unfounded. But it seems like its coming from PHPs reputation and not PHP as it stands today. In the edit to my comment above I touched on this. In short, when you instruct someone on how to do something you put the focus on the task and not the peripheral stuff. You may mention it in passing but to explicitly go over certain things may not be the right thing to do. I can totally see any book or tutorial showing people how to do certain things without mentioning security or kind of glossing over them. That's because you want to make sure a person gets the concept first. Once a person gets how to work with GET/POST or do anything else for that matter, you can then explicitly go over security, mention where to look for vulnerabilities, where to use the security techniques etc. I learned a touch of Ruby and I'm getting decent with Python right now and pretty much everything I've read either completely skipped security or mentioned it in passing. At a certain point security is introduced and by that point I understood the language enough to know where to apply it in the previous examples from whatever I read. I've also been reading a copy of "Javascript: The Good Parts" and it does much the same thing where you get comfortable with the concepts and security comes later. I think that because of PHPs history of security problems people are extra sensitive to any PHP code they read online and are almost looking for any way to jump up and say "that's not secure!!". PHP deserves that because of how it used to be but things have and are still changing very much.
- Firehed 14y ago
  Sounds like a documentation problem, not one of the language. You can shoot yourself in the foot with any programming language. PHP just happens to have one of the shallowest learning curves and greatest availability, so simply by virtue of being everywhere it's responsible for a lot of damage. It doesn't help that a newbie that came up with a working (but dangerous/incorrect/...) solution can then easily start answering other newbies' questions, although that's hardly a PHP-specific thing. Further - because it's so many people's first programming language, they don't even know to look for information about best practices, let alone go out of their way for it. It takes a seasoned programmer to go out of his/her way to avoid repeating other people's mistakes.
astrodust 14y ago
Regardless of the state of PHP itself, the user base is severely misinformed and a large part of the blame comes to rest on people writing tutorials like this. Python, Ruby, Perl, Java and even C# all have popular, widely used SQL interface libraries where placeholders are the norm. Only PHP even considers injecting user data into queries. This is extremely harmful. Tutorials should show best practices, not just the first thing that works. There should be significant attention paid to how to construct a safe and reliable query. This is not a secondary concern, not when there are automatic hacking tools with a very scary list of features (http://sqlmap.org/ http://sqlmap.org/) out there for anyone to download. Microsoft used to be very hand-wavey about security issues and it cost them severely. Now they've tightened all the bolts and Windows is in much better shape because of it. The PHP community needs to root out these poisonously bad tutorials and eliminate them from search results. How can this be done? By making better tutorials and linking to them more aggressively. Stop pretending this isn't a problem and start fixing it.
- gnud 14y ago
  One of the most important things that's about to happen for PHP security, is deprecating the 'mysql' extension[1], which doesn't support prepared statements. Forcing cheapo web hosts to enable mysqli or PDO will hopefully help a great deal. I just think they should have added E_DEPRECATED warnings in 5.4 - but I see why they didn't. [1]: http://news.php.net/php.internals/53799 http://news.php.net/php.internals/53799
  - astrodust 14y ago
    It's nice that it's generating warnings now, but the best thing for the community would be to completely remove it. It'd be better to answer questions about "Why doesn't my code work?" than "How can I fix my (horribly insecure) app?" where they're not even concerned about the security issues. PHP 5.5 will produce warnings when using mysql_query. It's a small step forward.
FuzzyDunlop 14y ago
To be fair, prepared statements have been a solved problem in PHP for a fair long time now, and so it's totally okay to call out the notion of "quickly learning from mistakes" when a subset of that community still doesn't use or encourage them.
- Stubbs 14y ago
  You can tar a whole language as bad because some of it's users use it to write bad code, otherwise you'd be talking about all languages.
h2s 14y ago
I can totally sympathise with the slightly angry tone of this reply, as my post was in a similar vein so I kind of had it coming. You're correct in that this was kind of just a cheap shot and I agree that the community is at least heading in the right direction. You could easily argue that if I really feel so strongly about this issue, I ought to be contacting codular to discuss the issue instead of idly bitching behind their backs on HN. I do disagree with you on some of your points about tutorials though. You claim it's possible to find such insecure example code for any language, and that's probably true. But is it easy? The first search result for "python mysql tutorial" [1] doesn't contain any SQL injection vulnerabilities. Neither does the first result for "ruby mysql tutorial" [2]. All seems well with "java mysql tutorial" [3] too. Surely the first Google result for "php mysql tutorial" [4] can't be that bad then? $first=$_POST['first']; $last=$_POST['last']; $phone=$_POST['phone']; $mobile=$_POST['mobile']; $fax=$_POST['fax']; $email=$_POST['email']; $web=$_POST['web']; mysql_connect(localhost,$username,$password); @mysql_select_db($database) or die( "Unable to select database"); $query = "INSERT INTO contacts VALUES ('','$first','$last','$phone','$mobile','$fax','$email','$web')"; mysql_query($query); Ouch. In this case, your point about this being an "old and awful" tutorial does apply. But the tutorials from my original post are new, as in "2013" new. And they were on the front page of HN not one week ago. It's like, finally here comes a fresh-looking new site that looks like it might even have a shot at knocking that garbage from "freewebmasterhelp.com" off the top spot on Google, and it's still not as good as it should be. [1] http://zetcode.com/databases/mysqlpythontutorial/ http://zetcode.com/databases/mysqlpythontutorial/ [2] http://zetcode.com/db/mysqlrubytutorial/ http://zetcode.com/db/mysqlrubytutorial/ [3] http://www.vogella.com/articles/MySQLJava/article.html http://www.vogella.com/articles/MySQLJava/article.html [4] http://www.freewebmasterhelp.com/tutorials/phpmysql/4 http://www.freewebmasterhelp.com/tutorials/phpmysql/4
- blindhippo 14y ago
  The tutorial you linked to shows a date of 1999-2001 (not 2013...). Considering the origins of PHP being predominantly a templating language targeting "webmasters", it's understandable that this link is at the top of the search results. Unfortunate, yes, but understandable. However, PHP is no longer a templating language. It's a full featured programming language that is used to build a variety of different systems. Trained developers work with PHP every day to build solid, testable and secure code. There is no excuse for any trained developer to write code like that. Perhaps you shouldn't judge the language just because some untrained idiot put up a bad tutorial.
colanderman 14y ago
Is there some magic language out there that cleans all external input for you? If by "magic" you mean simply disallowing non-structured queries (which is pretty darn easy with a Structured Query Language): http://en.wikipedia.org/wiki/Language_Integrated_Query http://en.wikipedia.org/wiki/Language_Integrated_Query http://www.impredicative.com/ur/ http://www.impredicative.com/ur/ http://pgocaml.forge.ocamlcore.org/ http://pgocaml.forge.ocamlcore.org/ https://github.com/mfp/ocaml-sqlexpr https://github.com/mfp/ocaml-sqlexpr and that's just off the top of my head.
- TylerE 14y ago
  Also, for instance, the (quite nice) Sequel library in ruby makes this painless DB["insert into foo (bar, baz, qux) VALUES (?, ?, ?)", bar, baz, qux].insert And the library handles all the escaping, and even type conversion for you (e.g. Date objects to SQL compatible date strings)

pavel_lishin 14y ago

> Can you tell me which language is impervious to SQL vulnerabilities? That's not the point. The point is that PHP tutorials/books/best practice guidelines repeatedly and consistently do this sort of thing. Even "PHP: The Good Parts" spent most of the chapter on SQL without mentioning security until the very last part, where they sort of waved their hands at it.

bpatrianakos 14y ago
Security is important, and I can't say your concern over it is unfounded. But it seems like its coming from PHPs reputation and not PHP as it stands today. In the edit to my comment above I touched on this. In short, when you instruct someone on how to do something you put the focus on the task and not the peripheral stuff. You may mention it in passing but to explicitly go over certain things may not be the right thing to do. I can totally see any book or tutorial showing people how to do certain things without mentioning security or kind of glossing over them. That's because you want to make sure a person gets the concept first. Once a person gets how to work with GET/POST or do anything else for that matter, you can then explicitly go over security, mention where to look for vulnerabilities, where to use the security techniques etc. I learned a touch of Ruby and I'm getting decent with Python right now and pretty much everything I've read either completely skipped security or mentioned it in passing. At a certain point security is introduced and by that point I understood the language enough to know where to apply it in the previous examples from whatever I read. I've also been reading a copy of "Javascript: The Good Parts" and it does much the same thing where you get comfortable with the concepts and security comes later. I think that because of PHPs history of security problems people are extra sensitive to any PHP code they read online and are almost looking for any way to jump up and say "that's not secure!!". PHP deserves that because of how it used to be but things have and are still changing very much.
Firehed 14y ago
Sounds like a documentation problem, not one of the language. You can shoot yourself in the foot with any programming language. PHP just happens to have one of the shallowest learning curves and greatest availability, so simply by virtue of being everywhere it's responsible for a lot of damage. It doesn't help that a newbie that came up with a working (but dangerous/incorrect/...) solution can then easily start answering other newbies' questions, although that's hardly a PHP-specific thing. Further - because it's so many people's first programming language, they don't even know to look for information about best practices, let alone go out of their way for it. It takes a seasoned programmer to go out of his/her way to avoid repeating other people's mistakes.

astrodust 14y ago

Regardless of the state of PHP itself, the user base is severely misinformed and a large part of the blame comes to rest on people writing tutorials like this. Python, Ruby, Perl, Java and even C# all have popular, widely used SQL interface libraries where placeholders are the norm. Only PHP even considers injecting user data into queries. This is extremely harmful. Tutorials should show best practices, not just the first thing that works. There should be significant attention paid to how to construct a safe and reliable query. This is not a secondary concern, not when there are automatic hacking tools with a very scary list of features (http://sqlmap.org/ http://sqlmap.org/) out there for anyone to download. Microsoft used to be very hand-wavey about security issues and it cost them severely. Now they've tightened all the bolts and Windows is in much better shape because of it. The PHP community needs to root out these poisonously bad tutorials and eliminate them from search results. How can this be done? By making better tutorials and linking to them more aggressively. Stop pretending this isn't a problem and start fixing it.

gnud 14y ago
One of the most important things that's about to happen for PHP security, is deprecating the 'mysql' extension[1], which doesn't support prepared statements. Forcing cheapo web hosts to enable mysqli or PDO will hopefully help a great deal. I just think they should have added E_DEPRECATED warnings in 5.4 - but I see why they didn't. [1]: http://news.php.net/php.internals/53799 http://news.php.net/php.internals/53799
- astrodust 14y ago
  It's nice that it's generating warnings now, but the best thing for the community would be to completely remove it. It'd be better to answer questions about "Why doesn't my code work?" than "How can I fix my (horribly insecure) app?" where they're not even concerned about the security issues. PHP 5.5 will produce warnings when using mysql_query. It's a small step forward.

FuzzyDunlop 14y ago

To be fair, prepared statements have been a solved problem in PHP for a fair long time now, and so it's totally okay to call out the notion of "quickly learning from mistakes" when a subset of that community still doesn't use or encourage them.

Stubbs 14y ago
You can tar a whole language as bad because some of it's users use it to write bad code, otherwise you'd be talking about all languages.

h2s 14y ago

I can totally sympathise with the slightly angry tone of this reply, as my post was in a similar vein so I kind of had it coming. You're correct in that this was kind of just a cheap shot and I agree that the community is at least heading in the right direction. You could easily argue that if I really feel so strongly about this issue, I ought to be contacting codular to discuss the issue instead of idly bitching behind their backs on HN. I do disagree with you on some of your points about tutorials though. You claim it's possible to find such insecure example code for any language, and that's probably true. But is it easy? The first search result for "python mysql tutorial" [1] doesn't contain any SQL injection vulnerabilities. Neither does the first result for "ruby mysql tutorial" [2]. All seems well with "java mysql tutorial" [3] too. Surely the first Google result for "php mysql tutorial" [4] can't be that bad then? $first=$_POST['first']; $last=$_POST['last']; $phone=$_POST['phone']; $mobile=$_POST['mobile']; $fax=$_POST['fax']; $email=$_POST['email']; $web=$_POST['web']; mysql_connect(localhost,$username,$password); @mysql_select_db($database) or die( "Unable to select database"); $query = "INSERT INTO contacts VALUES ('','$first','$last','$phone','$mobile','$fax','$email','$web')"; mysql_query($query); Ouch. In this case, your point about this being an "old and awful" tutorial does apply. But the tutorials from my original post are new, as in "2013" new. And they were on the front page of HN not one week ago. It's like, finally here comes a fresh-looking new site that looks like it might even have a shot at knocking that garbage from "freewebmasterhelp.com" off the top spot on Google, and it's still not as good as it should be. [1] http://zetcode.com/databases/mysqlpythontutorial/ http://zetcode.com/databases/mysqlpythontutorial/ [2] http://zetcode.com/db/mysqlrubytutorial/ http://zetcode.com/db/mysqlrubytutorial/ [3] http://www.vogella.com/articles/MySQLJava/article.html http://www.vogella.com/articles/MySQLJava/article.html [4] http://www.freewebmasterhelp.com/tutorials/phpmysql/4 http://www.freewebmasterhelp.com/tutorials/phpmysql/4

blindhippo 14y ago
The tutorial you linked to shows a date of 1999-2001 (not 2013...). Considering the origins of PHP being predominantly a templating language targeting "webmasters", it's understandable that this link is at the top of the search results. Unfortunate, yes, but understandable. However, PHP is no longer a templating language. It's a full featured programming language that is used to build a variety of different systems. Trained developers work with PHP every day to build solid, testable and secure code. There is no excuse for any trained developer to write code like that. Perhaps you shouldn't judge the language just because some untrained idiot put up a bad tutorial.

colanderman 14y ago

Is there some magic language out there that cleans all external input for you? If by "magic" you mean simply disallowing non-structured queries (which is pretty darn easy with a Structured Query Language): http://en.wikipedia.org/wiki/Language_Integrated_Query http://en.wikipedia.org/wiki/Language_Integrated_Query http://www.impredicative.com/ur/ http://www.impredicative.com/ur/ http://pgocaml.forge.ocamlcore.org/ http://pgocaml.forge.ocamlcore.org/ https://github.com/mfp/ocaml-sqlexpr https://github.com/mfp/ocaml-sqlexpr and that's just off the top of my head.

TylerE 14y ago
Also, for instance, the (quite nice) Sequel library in ruby makes this painless DB["insert into foo (bar, baz, qux) VALUES (?, ?, ?)", bar, baz, qux].insert And the library handles all the escaping, and even type conversion for you (e.g. Date objects to SQL compatible date strings)