You are so completely and utterly off base with this rant, it's not even funny.
The fact is SQL injection shouldn't even be a thing these days. If everyone used query binding/prepared statements/whatever your API calls it, it simply wouldn't exist. Idiocy like magic_quotes_gpc and "let's just throw more abstraction at it" only serves to band-aid the problem, and with this "advisory" all you're doing is throwing a temper-tantrum that everyone's not licking the window right along with you.
Which is better, arbitrarily munging data (in the case of magic_quotes_gpc, absolutely everything that comes in through the webserver, leaving you to guess whether you're even going to send it to an SQL DB or not so as you can stripslashes() it) - or simply not having data from userland anywhere near the query parser?
Look at it another way: which is the correct solution? Scanning all strings for and munging % characters on the off chance you might use the string in sprintf(), or just having people not do something stupid like use something that came from userland as the first argument to sprintf() in the first place?
Topic: [SECURITY WARNING] Dangerous PHP.INI setting by default (Read 5054 times)
Note also that "magic quotes" is a server setting, so at least half of the time it was configured wrongly by the sys admin and the developer didn't take that into account. Resulting in either SQL injections or \\\\\\\\\\\\\\\\" all over the place.
THEN I believe it to be better to have \\\\\\\\\\\\ all over the place than SQL injections... If you see the web as a cow "\\\\\\\\\\\" are the flies and the DB is the milk. The flies are annoying but harmless, yet the milk is precious and must be saved.
The only time those "magical" settings annoyed me was in a project where I must output a XLS file... when I pack the bytes, *puffff*, "magically" rendered a blank file... took me a while to figure out, because it looks all ok on the test server, yet on the production server magic_quotes_runtime were on. gpc on the other hand never bothered me, just strip it if found to be on and it's quite easy to notice.
Lol yeah of course you can wrap it in stripslashes, to remove the slashes again that were unnecessary in the first place. And so the image of PHP as hackish amateur language was born.
Note also that "magic quotes" is a server setting, so at least half of the time it was configured wrongly by the sys admin and the developer didn't take that into account. Resulting in either SQL injections or \\\\\\\\\\\\\\\\" all over the place.
Note also that "magic quotes" is a server setting, so at least half of the time it was configured wrongly by the sys admin and the developer didn't take that into account. Resulting in either SQL injections or \\\\\\\\\\\\\\\\" all over the place.
Magic codes are crap, they should indeed never have existed in the first place. And people should never have been building SQL queries as strings but using proper parametrized queries (prepared statements) from the beginning. Magic quotes made developers lazy.
"magic quotes" is the reason why you cannot use ' and " in some sites because a \ will always be added (and if you submit multiple times, it will turn into \\\\\\"). Why in hell the PHP developers thought that every string coming in would be submitted as-is in a SQL query, I don't know.
"magic quotes" is the reason why you cannot use ' and " in some sites because a \ will always be added (and if you submit multiple times, it will turn into \\\\\\"). Why in hell the PHP developers thought that every string coming in would be submitted as-is in a SQL query, I don't know.
Just do a stripslashes when outputing the data. That's the "most hazard" magic_quotes can do being on.
PHP developers thought that input data will be used with SQL, because PHP+Apache+MySQL is the Trinity of web... and yes, most it goes to MySQL. There they weren't wrong at all.
Magic codes are crap, they should indeed never have existed in the first place. And people should never have been building SQL queries as strings but using proper parametrized queries (prepared statements) from the beginning. Magic quotes made developers lazy.
"magic quotes" is the reason why you cannot use ' and " in some sites because a \ will always be added (and if you submit multiple times, it will turn into \\\\\\"). Why in hell the PHP developers thought that every string coming in would be submitted as-is in a SQL query, I don't know.
"magic quotes" is the reason why you cannot use ' and " in some sites because a \ will always be added (and if you submit multiple times, it will turn into \\\\\\"). Why in hell the PHP developers thought that every string coming in would be submitted as-is in a SQL query, I don't know.
Indeed, PHP is like VB6, can be deceiving. It looks easy but ain't, it's just easy to produce bad code.
However unlike VB, PHP is used in a multiuser web environment with all the dangers it brings along, and unlike removing register_globals, which just made a bunch of lousy scripts to stop working, like osCommerce, magic_quotes_gpc has direct impact on security, changing them from "barely locked" to "with the front door wide open". THAT makes a difference!
Is like if you forget to tight a bolt on your breaks, so your car will be breaking with one wheel or removing the whole set so it won't be breaking at all.
However unlike VB, PHP is used in a multiuser web environment with all the dangers it brings along, and unlike removing register_globals, which just made a bunch of lousy scripts to stop working, like osCommerce, magic_quotes_gpc has direct impact on security, changing them from "barely locked" to "with the front door wide open". THAT makes a difference!
Is like if you forget to tight a bolt on your breaks, so your car will be breaking with one wheel or removing the whole set so it won't be breaking at all.
For a coder it may not make much difference, can activate it in the config if needed or deactivate if don't. But for the regular web users who, at best, can install XAMPP, it's exposing them to unnecessary danger.
You need to realize that sometimes you should let someone do a job who knows how to do it. I could repair the brakes of my car, but I don't; because I might forget a tiny detail that can cost my life. If someone has problems getting a LAMP running smoothly, maybe that person should let someone do it who's familiar with it. Having said that, the reason why PHP has caught on is because it makes it easy to write code; it forgives many errors. However, this is also it's main problem. Removing magic_quotes_gpc is actually a step towards better security; just like removing register_globals. No, prepared statements will most certainly stop someone from injecting "1 OR 1=1".
No, it wouldn't.
You're wrong. Try it.
Already noticed, seams like it prevents the query from be extended by removing unescaped keywords.
My bad, sorry for that one.
No, prepared statements will most certainly stop someone from injecting "1 OR 1=1".
No, it wouldn't.
You're wrong. Try it.
Yes and no.
That isn't the best example, because have a worse bad coding practice than rely on magic_quotes on it; slack coding.
I do prefer to validate every input myself rather than rely in magical cleaners, mysqli removes keywords that would extend the query - which is mostly a counter measure to an even more slack way of code - yes, there're folks so slack that pass parts of queries with GET or POST; I recall to have seen some site when you press a page nr to go to page.php?q=LIMIT%2010,50
But again, I'm not "for magic_quotes" or its fan, I'm against removing it, because many open sourced software relies on it. Different subjects.
For a coder it may not make much difference, can activate it in the config if needed or deactivate if don't. But for the regular web users who, at best, can install XAMPP, it's exposing them to unnecessary danger.
That isn't the best example, because have a worse bad coding practice than rely on magic_quotes on it; slack coding.
I do prefer to validate every input myself rather than rely in magical cleaners, mysqli removes keywords that would extend the query - which is mostly a counter measure to an even more slack way of code - yes, there're folks so slack that pass parts of queries with GET or POST; I recall to have seen some site when you press a page nr to go to page.php?q=LIMIT%2010,50
But again, I'm not "for magic_quotes" or its fan, I'm against removing it, because many open sourced software relies on it. Different subjects.
For a coder it may not make much difference, can activate it in the config if needed or deactivate if don't. But for the regular web users who, at best, can install XAMPP, it's exposing them to unnecessary danger.
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.
Not, it wouldn't. There's nothing filtering the input before it goes to db, it would need data type checking before fill the var. A thing that neither PDO or mysql_real_escape_string do.
Code:
# 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');
if (isset($_POST['id'])) { $id=$_POST['id']; } else { $id=0; }
if (isset($_POST['iface']) && $_POST['iface']=='mysqli') {
$s=new mysqli('localhost', 'dbuser', 'dbpass', 'test');
$q=$s->prepare('select user, pass from injecttest where id=?');
$q->bind_param('s', $id);
$q->execute();
$q->bind_result($user, $pass);
while ($q->fetch()) { echo "Hello ".$user.", your password is ".$pass."
$s->close();
}
elseif (isset($_POST['iface']) && $_POST['iface']=='mysql') {
$s=mysql_connect('localhost', 'dbuser', 'dbpass');
mysql_select_db('test', $s);
$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']."
mysql_close($s);
}
?>
Then try this code. Yes, it's as bad as the previous one and the example programmer even makes the mistake to bind the id as a string when using prepared statements. However, the injection does not return the entire password listing, but only one hit, contrary to the "classic" way to access mysql. Prepared statements are a method to protect against injections.# 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');
if (isset($_POST['id'])) { $id=$_POST['id']; } else { $id=0; }
if (isset($_POST['iface']) && $_POST['iface']=='mysqli') {
$s=new mysqli('localhost', 'dbuser', 'dbpass', 'test');
$q=$s->prepare('select user, pass from injecttest where id=?');
$q->bind_param('s', $id);
$q->execute();
$q->bind_result($user, $pass);
while ($q->fetch()) { echo "Hello ".$user.", your password is ".$pass."
$s->close();
}
elseif (isset($_POST['iface']) && $_POST['iface']=='mysql') {
$s=mysql_connect('localhost', 'dbuser', 'dbpass');
mysql_select_db('test', $s);
$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']."
mysql_close($s);
}
?>
Again, I'm perfectly aware that these examples are overloaded with bugs (on purpose) and can be abused in multiple ways. they only exists as an example where magic_quotes_gpc fails to protect you from an injection, unlike prepared statements.
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:Yes, but the example is way too bad, it can be injected... but injected on any circumstance.
SQL injections ARE stopped by magic_quotes_gpc
And now you've admitted that my example would inject, proving your earlier statement wrong.Sorry, your code doesn't need any anti-sqli measure, it needs a miracle. magic_quotes is effective on stop unescaped entries, not a magical corrector. Anyway your example isn't checking if the user can access the data you're giving him, so whether he uses 1 OR 1=1 or create a script to request from 1 to 1000 would get the same output.
If you match it against the user_id he can perform the query, inject it, and still be safe code. Isn't that amazing? Coding is like playing chess... you've many ways to get the same outcome and can apply different strategies.
Code:
while ($r=mysql_fetch_array($q, MYSQL_ASSOC)) { if($r['id'] == $_SESSION['uid']) echo "Hello ".$r['user'].", your password is ".$r['pass']."
?>
?>
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.[/quote]
I found this another analogy to be more valid on the subject: You've a yale lock (those normal ones flat you see everywhere) on your front door. Someone notices that yale isn't safe and advises you to change to a dimple lock, so this person takes your yale away but doesn't input the dimple lock himself, leaving your frontdoor open.
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.if(get_magic_quotes_gpc()) $str = stripslashes($str);
return mysql_real_escape_string($str);
}
Isn't because I see no harm on magic_quotes_gpc that I'll use it. And that code actually shows you how "hazardous" magic_quotes_gpc can be when on; nothing. Takes just one line of code to undo them: if(get_magic_quotes_gpc()) $str = stripslashes($str);
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.
Not, it wouldn't. There's nothing filtering the input before it goes to db, it would need data type checking before fill the var. A thing that neither PDO or mysql_real_escape_string do.
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);
}
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.
If you can avoid PHP do it, using smalltalk or even Python
Otherwise use wrappers when calling to SQL, no direct access
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.
If you can avoid PHP do it, using smalltalk or even Python
Otherwise use wrappers when calling to SQL, no direct access
Otherwise use wrappers when calling to SQL, no direct access
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.
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.
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!
Jump to: