Bitcoin Forum
December 10, 2016, 01:03:20 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: [SECURITY WARNING] Dangerous PHP.INI setting by default  (Read 4743 times)
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 18, 2011, 11:52:23 AM
 #21

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481375000
Hero Member
*
Offline Offline

Posts: 1481375000

View Profile Personal Message (Offline)

Ignore
1481375000
Reply with quote  #2

1481375000
Report to moderator
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 18, 2011, 12:12:57 PM
 #22

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.

Quote
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:
<?php
while ($r=mysql_fetch_array($qMYSQL_ASSOC)) { if($r['id'] == $_SESSION['uid']) echo "Hello ".$r['user'].", your password is ".$r['pass']."<br />"; }
?>



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.

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

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);
Bitsky
Hero Member
*****
Offline Offline

Activity: 542


View Profile
September 18, 2011, 01:08:25 PM
 #23

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:
<?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');
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."<br />"; }
$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($qMYSQL_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" value="<?php echo $id?>"/><br />
<input type="radio" name="iface" value="mysql" />use mysql<br />
<input type="radio" name="iface" value="mysqli" />use mysqli<br />
<input type="submit" value="Send" />
</form>
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.

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.


Bounty: Earn up to 68.7 BTC
Like my post? Feel free to drop a tip to 1BitskyZbfR4irjyXDaGAM2wYKQknwX36Y
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 18, 2011, 01:32:50 PM
 #24

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.
NghtRppr
Sr. Member
****
Offline Offline

Activity: 476


View Profile
September 18, 2011, 05:40:37 PM
 #25

No, prepared statements will most certainly stop someone from injecting "1 OR 1=1".

No, it wouldn't.

You're wrong. Try it.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 18, 2011, 05:58:37 PM
 #26

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.
Bitsky
Hero Member
*****
Offline Offline

Activity: 542


View Profile
September 18, 2011, 09:55:49 PM
 #27

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.

Bounty: Earn up to 68.7 BTC
Like my post? Feel free to drop a tip to 1BitskyZbfR4irjyXDaGAM2wYKQknwX36Y
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 18, 2011, 11:41:06 PM
 #28

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.
wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 19, 2011, 02:59:44 PM
 #29

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.


Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 19, 2011, 03:06:57 PM
 #30

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.



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.
wumpus
Hero Member
*****
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
September 19, 2011, 03:23:35 PM
 #31

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.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
BCEmporium
Legendary
*
Offline Offline

Activity: 938



View Profile
September 19, 2011, 03:37:29 PM
 #32

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.
elggawf
Sr. Member
****
Offline Offline

Activity: 308



View Profile
September 25, 2011, 09:22:24 PM
 #33

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?

^_^
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!