RE: incompatible on older version of windows: I don't know nuthin about windows compatibility, somebody want to volunteer to investigate? Is bitcoin 0.4 less compatible for some reason than 0.3.24 was? (shouldn't be...)
Matt mentioned that it's related to MinGW and the upnp library. I don't mind testing builds on W2k. |
|
|
|
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. |
|
|
|
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. <?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($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" 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. |
|
|
|
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? 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. |
|
|
|
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. <?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. |
|
|
|
Unforunately it won't start in W2k (I know it's an old OS, but that's what my Intranet server is running). I reported that for version 0.3.21 and think Matt already took a closer look into it: https://bitcointalk.org/index.php?topic=24841.0 |
|
|
|
|
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 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.phpThis 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.htmlUnfortunately 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-magicquotesgpcThe 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. |
|
|
|
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. |
|
|
|
|
Figured that accounts are only used for some sort of summaries.
Let's say I have two accounts in my wallet:
- acc1 with addr1 holding 5btc
- acc2 with addr2 holding 10btc
When I do a move(acc2, acc1, 1), then 1btc should wander from acc2 into acc1.
But how is this handled address-wise? The moved bitcoin needs to be removed from addr2 and added either to addr1 or to a new address which gets assigned to acc1.
So either:
- acc1 with addr1 holding 6btc
- acc2 with addr2 holding 9btc
or
- acc1 with addr1 holding 5btc and addr3 holding 1btc
- acc2 with addr2 holding 9btc
|
|
|
|
|
The API documentation states that one can move Bitcoins from one account to another one in your wallet with move() by specifying from, to and the amount.
Since addresses are assigned to accounts with setaccount(), I don't think that move() is just moving addresses, but actually doing a transaction (hence the amount option).
Now if I want to use move() to reorganize / shuffle around the Bitcoins in my wallet, will I
a) have to pay a transaction fee every time I move an amount and
b) generate an entry in the blockchain?
Also, the amount is rounded to the nearest 0.01. Will it be possible to move smaller amounts in the future?
|
|
|
|
You're seeing a blank page because you don't send any POST data. The reply to bitcoinnotify's request would contain the POST data in its reply. If you need to see the data, your script needs to log it. You can simply dump it into a file: <?php
$f=fopen('/path/to/logs/bitcoinnotify.log', 'a');
fwrite($f, "[".date('r')."]: data received\n");
fwrite($f, ': POST: '.print_r($_POST, true));
fclose($f);
?>
Remember that, depending on your config, you might have to adjust the permissions on the log file so that your webserver can write to it. |
|
|
|
|
So I thought about taking a closer look at SolidCoin since threads about it keep popping up.
Now I won't.
RealSolid's way of handling this is arrgoant and he comes across as a huge drama queen.
He also seems not to be interested in giving back fixes to the project from which he forked his.
Perhaps SolidCoin is good, but with a project leader like this I won't touch it with a 10' pole.
|
|
|
|
I really had no idea I would get this kind of response. I expected one or two to PM me, but thanks to everyone who has tried to help.
Bitsky was the first to PM me, and so far it looks like I can use his code so I will send him 0.5BTC.
I will also send 0.1BTC to everyone else who has contributed in this thread. Hope this is fair.
Thanks. Also, out of curiousity: did you want to display the value, or the json? |
|
|
|
Right, stands to reason he'd want to involve jquery-ajax to make live stats, which you could clean up even more to insert the various stats in specific spots anywhere on the page.
Would still need a second php script small just like I had said for my project to bypass cross-site scripting limitations.
Probably 3 lines in php, 1 include in html plus 3-4 lines there for calls of actual data being put in tags on the page.
If enabled, SSI/CGI could do the job too. Again, unfortunately I bet an imaginary burrito. Until I can find an IB to BTC exchange, I'm afraid I am forever indebted to you sir.  There goes my hope. Is that one of those new blockchains which pop up at every corner? |
|
|
|
I'd bet money no one has PMed you yet and posted here instead. PMing now.
You just lost. I sent a PM, but since everybody started to reply I saw no reason to wait for him to reply. How much did you bet? See my sig for recipient details  |
|
|
|
Stands to reason that he wants ALL the same BUT one thing changed. How can he have the same information if the ONLY thing you display is different?
If he's passing all the details on to an end user, then he wants the whole stream of info for api, the way you suggest means he'd have to make a seperate script and page for each of the details. If he wanted to just pull one at a time he could have just read from source and had a single trigger somewhat like yours is. It sounds like he wants the whole set of information sent though.
Still makes no sense to have the site reload every minute when the output is json. Either display the content and refresh, or deliver json and let the client do the reloads. Anyway, in case he wants json without the reloading: <?php
$data=json_decode(file_get_contents('http://bitclockers.com/api.json'), true);
$data['activeworkers']>500 ? $data['activeworkers']=100 : $data['activeworkers']=1000000;
echo(json_encode($data));
?>
|
|
|
|
This information needs to be updated every minute.
I believe he wanted the same information (ie. the whole json) returned with just the workers changed.
That would make no sense with the auto-reload. Returning json makes sense when another script pulls the info every minute. @fsvo: googleapis for a refresh? Seriously? Nobody likes small code anymore? <html>
<head><meta http-equiv="refresh" content="60"></head>
<body>
<?php
$data=json_decode(file_get_contents('http://bitclockers.com/api.json'), true);
$data['activeworkers']>500 ? print(100) : print(1000000);
?>
</body>
</html>
|
|
|
|
|
Show Posts
