[SECURITY WARNING] Dangerous PHP.INI setting by default

[BCEmporium]

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.

[1714017887]

1714017887

[1714017887]

1714017887

[1714017887]

1714017887

[Bitsky]

long rant

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.

[BCEmporium]

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.

[casascius]

It's a legitimate complaint.

[ClownCoins]

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

[BCEmporium]

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

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... ?

[Bitsky]

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.

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

This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged. (...) It's preferred to code with magic quotes off and to instead escape the data at runtime, as needed.

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

Unfortunately this protection isn't perfect: there are a series of other characters that databases interpret as special not covered by this function. In addition, data not sent direct to databases must un-escaped before it can be used.

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

The fundamental problem with magic_quotes_gpc is that they know nothing about the context. They don't know if you're using the data to insert it into MySQL, Oracle, or if you're writing to a file. Maybe you're sending it through SOAP or displaying it in HTML? Or maybe all of it. They just don't have enough information, only you know it. Escaping values depends on a context in which they are used.

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

[BCEmporium]

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

[Bitsky]

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.

[BCEmporium]

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.

[Bitsky]

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.

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.

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.

Code:

<?php
# drop table if exists injecttest;
# create table injecttest (id tinyint(3) unsigned auto_increment, user varchar(8) not null, pass varchar(8) not null, primary key(id) ) engine=myisam;
# insert into injecttest (user,pass) values ('bob', 'secret'), ('jane', '12345');
$s=mysql_connect('localhost', 'dbuser', 'dbpass');
mysql_select_db('test', $s);
if (isset($_REQUEST['id'])) { $id=$_REQUEST['id']; } else { $id=0; }
$q=mysql_query('select user, pass from injecttest where id='.$id);
while ($r=mysql_fetch_array($q, MYSQL_ASSOC)) { echo "Hello ".$r['user'].", your password is ".$r['pass']."<br />"; }
mysql_close($s);
?>
<form method="post" action="">
User-ID: <input type="text" name="id" />
<input type="submit" value="Send" />
</form>

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.

[BCEmporium]

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.

[NghtRppr]

SQL injections ARE stopped by magic_quotes_gpc

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.

[BCEmporium]

SQL injections ARE stopped by magic_quotes_gpc

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.

None of the missing chars allows injection. Corrupt queries don't inject anything, simply don't execute. Also don't expect very complex queries or db's other than MySQL with those newbies. It's the usual PHP+Apache+MySQL set which gets the heat.

Expose the entire web to danger out of some elitism is probably the most obnoxious move I'd ever seen to be done in ANY programing language!

[NghtRppr]

None of the missing chars allows injection.

First, it depends on which database you're using. Second, even if the initial injection doesn't do anything, what happens when the incorrectly escaped data is used in subsequent queries? The point is, magic_quotes_gpc is ignorant of what database you're using so you it's simply false to say flat out that "SQL injections ARE stopped by magic_quotes_gpc". You need to qualify that statement rather than proposing it as a panacea.

Also don't expect very complex queries or db's other than MySQL with those newbies. It's the usual PHP+Apache+MySQL set which gets the heat.

It's fine if you want to say that magic_quotes_gpc, maybe, sometimes, prevents SQL injection. But that's not what you said earlier, hence my correction.

[BCEmporium]

OK, so lets all the folks who installed Open Sourced 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).

Don't pick the chat in the middle bitcoin2cash.

Those "almost-nobody-uses-sql" are excluded. Due to the nature of such projects an Oracle, MSSQL, DBASE, PostegréSQL... developer is meant to not be a newbie for starters.
At MySQL addslashes (what magic_quotes_gpg is indeed) is enough to save you of injections. Corrupt queries no, but injection it does... unless you show up a code as bad as Bitsky, but for that one nothing can actually do anything.

[zer0]

If you can avoid PHP do it, using smalltalk or even Python

Otherwise use wrappers when calling to SQL, no direct access

[BCEmporium]

If you can avoid PHP do it, using smalltalk or even Python

Otherwise use wrappers when calling to SQL, no direct access

OO -> NO! What the heck! Damn Lego makers! OO == +Speed up "development" -performance +crashing +incompatibility between versions... other than speed up "development", OO languages are just turn downs.
Not enough to look at the "king of OO languages"; Java? .NET at least is faster but leaks memory like a broken pot.

[NghtRppr]

Corrupt queries no, but injection it does... unless you show up a code as bad as Bitsky, but for that one nothing can actually do anything.

No, prepared statements will most certainly stop someone from injecting "1 OR 1=1". Like I said, prepared statements are the way to go if you actually care about security. If you want to get hacked then keep suggesting the use of magic_quotes_gpc.

[Bitsky]

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

If you read my post you'll notice that I said that this is downright bad code. But let me quote one of your earlier posts:

SQL injections ARE stopped by magic_quotes_gpc

And now you've admitted that my example would inject, proving your earlier statement wrong.

Expose the entire web to danger out of some elitism is probably the most obnoxious move I'd ever seen to be done in ANY programing language!

It's more like having soft rubber bumpers down along every street and then complaining about a car crash because one street doesn't have them instead of learning how to drive correctly in the first place.

At MySQL addslashes (what magic_quotes_gpg is indeed) is enough to save you of injections.

Then why are you undoing the magic_quotes_gpg "protection" and rely on mysql_real_escape_string() instead?

Code:

function makeSQLSafe($str){
    if(get_magic_quotes_gpc()) $str = stripslashes($str);
    return mysql_real_escape_string($str);
}

That code block is taken from your project.