Topic: [SECURITY WARNING] Dangerous PHP.INI setting by default - page 2. (Read 5054 times)

No, they aren't. That directive has no idea what kind of database you are querying and different databases require different characters to be escaped. For example, with MySQL it doesn't escape \x00, \x1a, \r, or \n. You should at least be using mysql_real_escape_string(), db2_escape_string(), pg_escape_string(), etc. That way you are escaping relevant characters that could affect your database queries. Even when using those functions, it's still possible that you could be using a different character set than the escaping function is using. The only real solution is to use prepared statements. Relying on magic_quotes_gpc is a terrible idea. It encourages bad programming practices and shields programmers from learning about those mistakes as soon as possible. The sooner PHP developers purge the memory of magic_quotes_gpc from their minds, the better. Beginners have to learn about all kinds of pitfalls, even if it's the hard way, and this should be one of them.

Actually your sample would be injected with or without magic_quotes, BUT also with mysql_real_escape_string or PDO.

That is so badly coded that no "idiot proof" system would be able to save you from Armageddon. Yet a simple

if (isset($_REQUEST['id'])) { $id=$_REQUEST['id']; } else { $id=0; }

to

if (isset($_REQUEST['id']) && is_numeric($_REQUEST['id'])) { $id=$_REQUEST['id']; } else { $id=0; }

would... however no PDO or mysql_real_escape_string is going to save you, PDO probably if you use %d, if you use %s not quite.

And, obviously, it isn't the first time I see vars dumped directly inside queries, just that guy wrote a "security tutorial" given also the lousiest of examples when it comes to basic query security.

I expect some "Elitism" when those people handle the data of others. I couldn't care less when they write buggy scripts to be used in their local network; but when personal data of others is involved I think it's fair to expect some basic knowledge. A lot of data leaks have happened because developers neglected the most basic security rules.

Now I admit that this is crappy code and probably (or hopefully) not found in any real world program. But let's say some newcomer wrote this to let users retrieve their password by typing in their user-id. Bob types in 1 and gets his password. Jane types in 2 and gets her password. Badboy types in "1 or 1=1" (no quotes) and gets all logins. All with magic_quotes_gpc enabled. There is your injection. No broken query, it's perfectly valid. Yes, the code is designed to be unsafe, but it proves that magic_quotes_gpc does not stop injections.

And if you think nobody uses data from _POST or _GET directly: people do. I've lectured some guy about this once who worked on a bank(!) website.

PHP hadn't decide nothing, I don't recall AI to be that developed that a program can decide about itself, some PHP core developers did. And upon these devs I can't start to get amazed. What are they up to? Oracle spies to create "JPHP"? Java has been a failure for web applications, even if that was part of the original Sun's plot.

Now... about people who probably "shouldn't" be developing projects. I don't agree with that posture! That's Elitism, and Elitism is both obnoxious and counter-productive. For many 0 coding knowledge the work of a few low coding knowledge made the difference between HAVE (even if badly coded) and DON'T HAVE (at all).

SQL injections ARE stopped by magic_quotes_gpc, what can happen as in the lousy examples found at your url ( http://css.dzone.com/news/hardening-php-magicquotesgpc ) - just by giving examples with {$_POST...} or {$_GET...} inside the SQL statement that guy is already a dangerous teacher for noobs - all he can do is to create an invalid query, rendering a SQL error, not an injection. In order to be injected you need to can perform or alter a query, not just corrupt an existing one. If you just corrupt queries... big deal! You won't be able to see their possible output and that's all.

Magic_quotes_gpc is one of those simplest of things that made most of PHP sort of "idiot proof". Removing it will NOT stop those "low knowledge" from coding, will just make their code more unsafe than what it is already.

Other projects will fix it. Simply because PHP decided to deprecate the function. Sure, they can ask their users to install a version still supporting it, but that means not getting any security updates and that makes it a dumb move. Security needs to be taken care of as close as possible to a project. At best, inside the project.

The last example explains why magic_quotes_gpc is no protection since SQL injections aren't stopped. However, strict input validation done by the developer and prepared statements do.

OK, so if you think that was a good measure just go over to all Open Source projects on the web and fix it... you've just probably a few billion of lines of code to go.
~ OR ~ the users could simply have it enabled - they're easily to notice when enable than when disabled actually.

BTW; that last example isn't anything to exploit it, it's just a concern about context (have it properly escaped/encoded).

And if you want to know how I do it, before go ad hominem, check the source at https://github.com/BCEmporium/PHPCoin

Well, then bring your complain to the attention of those writing buggy software so they fix it. magic_quotes_gpc are deprecated since 5.3, so they pretty much have to fix their code.

I don't really cry many tears when people get burned by relying on something which they think offers security. It's one of the most important rules to never ever trust user input. Always validate it and don't rely on some fairy magic that promises to do that for you. Of course it's not sweet for the users of that software, but it's in their power to put pressure on the developers to get it fixed.

The official statements: http://www.php.net/manual/en/security.magicquotes.php
Btw, the second comment sums it up (pretty blunt, but true).

Why it's not perfect: http://phpsec.org/projects/phpsecinfo/tests/magic_quotes_gpc.html

Example exploits even though you are "protected": http://css.dzone.com/news/hardening-php-magicquotesgpc

As for more, I'm sure you know how to use Google.

I'm not discussing the "wonders" of it, nor does my scripts rely on it.
However, what "harm" can they do being on? To the worse you would get something like John\\'s instead of John's... So, nothing.

And warn people to double check their PHP.INI because some PiDiOts think their rig is better or "so good" to let everybody be hacked is bad because... ?

Magic quotes are like your post; they should never have existed in the first place.

It's a legitimate complaint.

OK, so lets all the folks who installed Open Sourced software software, such as this forum, be hacked because "it didn't worked properly" (mind to explain where? With something-no-one-uses SQL? Because with MySQL it did).

That's like you saying that my Yale key is not "secure enough" so you take it away leaving the front door open. Nice one!

Well... it's "Open source" so I guess you get what you paid for, isn't it?
And it's not MY SCRIPT, it's MOST of widely available webscripts around.

So you are complaining that a "security feature", which never worked perfectly, is now disabled and leaves the developer with the task to sanatize the input, just like he should have done from the start?

If your script can be attacked because you rely on magic_quotes_gpc to protect you, then you should not write code.

Lately PHP developers had been targeted by Java moles, which came up with bogus "features" such as Private/Public declarations within classes and PDO. It's almost certain that PHP would either need to be forked or dumped at version 6 keeping this path.
Private and Public doesn't add nothing to performance, it's just that Java developers mindset is a mid-way between pure open source of PHP developers and extremely-proprietary mindset of Windows/Apple. Their only use is to prevent some other developer using "MY" class to access properties "I DON'T WANT".

Now, because these moles are getting their way, PHP ships with default EXTREMELY UNSAFE settings. Specially in this point:

magic_quotes_gpc = off -> UNSAFE;

I don't give a "F" if PDO bullshitter thinks his rig is safer than magic_quotes, by disabling it he opened more than 70% of the web to SQL injections. This is the main reason why some sites are being injected lately, people update or move the server to a new one and leave it as the defaults (has been working this far, so why bother, isn't it?)... jumping to this reef without even noticing. This is specially dangerous as many components of Joomla, Drupal, osCommerce... you name it... OS "web applications" rely on magic_quotes to prevent injections.
"It's bad practice to rely on magic_quotes_gpc"? Probably, but works and with so many people using it in such way you've to take it to account in the first place.

My bet was due to this bitcointalk got hacked, they changed from bitcoin.org to the new server and most likely did a fresh install without bothering about php.ini.