CP?
It depends of where you're from; if you're portuguese it means trains, as that's their initials... if you're not, than it's probably about child porn. |
|
|
|
tl;dr
But still; When Zen Cart forked osCommerce they didn't come out spreading FUD about the project they forked. When Joomla forked Mambo they didn't come out spreading FUD about the project they forked. When SMF forked phpBB they didn't come out spreading FUD about the project they forked. When IXCoin forked Bitcoin they didn't come out spreading FUD about the project they forked. (...) It's nearly a constant on all Open Source world, eventually a project gets forked, a new line of COOPERATIVE DEVELOPMENT ( THAT is the use of Open Source, not a f**ing vanity fair) When Cracked/ScamCoin came out its sole forker hop into others' work (Bitcoin), that's ok so far, but promptly started a DEFAMATION and an attempt to spread FUD about it, promising to be "fixing bugs" whereas was opening holes. I guess this already reached rock bottom, so there's no need to keep digging. Now go get your "FUD spread bounty", make sure you get paid in scamcoins 2.0, looks like scamcoins 1.x are worthless now. |
|
|
|
|
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.
|
|
|
|
You do know the OP was joking right?
Actually no, but it made me laugh a lot.  |
|
|
|
If you own Solidcoins, we suggest that you exchange them for BTC for the time being, because old solidcoins are soon going to be worthless. Once Solidcoin 2.0 will be traded on exchanges, you will be able to convert your BTC back to the new solidcoins.
Depending on the market exchange rates, you might not have exactly the same amount of Solidcoins before and after the transfer. However, statistical fluctuations should cancel out. We found that the first users who will exchange their old solidcoins for new ones might enjoy a more favourable exchange rate. This will create a nice incentive to bootstrap the conversion process.
ROFLOL! I can't stop laughing reading this! This bozo words:If you own Solidcoins, we suggest that you exchange them for BTC for the time being, because old solidcoins are soon going to be worthless.Translation:If you've Scamcoin, we suggest that you go find someone else and scam him to trade his bitcoins for your scamcoins, because your scamcoins are soon going to be worthless. Once Solidcoin 2.0 will be traded on exchanges, you will be able to convert your BTC back to the new solidcoins.Translation:If you're dumb enough to bite our scam twice, you're welcome. We need eediots like you. We found that the first users who will exchange their old solidcoins for new ones might enjoy a more favourable exchange rate. Translation:Be quick! As the rates will go downhill as soon as the scammers start to try dump their scamcoins for bitcoins. |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
Man! This is a scam! After you solve the first block you get this captcha to solve in order to input it to the chain:  |
|
|
|
Oh and BTW I was supporter of SC until he proved to be scam artist check my post history on Sept. 1 this year where I lay it all out for all to see...
Me too... out of this whole load of alt-chains, solidcoin was the only one I could see to be doing something different, improving, unlike IX/I0 that have nothing to show away from bitcoin. Well... we got fooled. |
|
|
|
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. <?php
while ($r=mysql_fetch_array($q, MYSQL_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. 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. 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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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! |
|
|
|
|
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.
|
|
|
|
|
Sounds hard, anyway try to not use spaces in the path to either the wallet.dat or the tool.
Eg. Mkdir C:\bitcoinRepair
cp wallet.dat there
cp tools there
try to fix.
|
|
|
|
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. |
|
|
|
|
Isn't it funny that besides your self-claims I was the only one actually posting some lines of code showing some implementation and let someone try out to see how it would look, render, resources usage and so on?
From your kind I've "theories" and self-proclamation BS.
|
|
|
|
it's yum -i apache actually I don't give a damn about who readers believe in. I'm not seeking for a job here. Let me guess, by microcontroller I must assume some Java PIC, by your posts I *REALLY* doubt you would touch ASM even with a 10 feet pole. "Java available for everything; crashing everywhere". BTW: is that "elite coder" posture I use to find obnoxious; «I'm the coder, deem it unsafe, that unsafe, follow "my" standards, "teach"/"educate" users, all my systems are "good practices", all others' are "security by obscurity"...» GTFO! |
|
|
|
I really would love to know where you folks get those "well paid consultant" jobs!
You shouldn't be too surprised that us who do end up at the forum of the world's first possibly-successful crypto currency. Well... I'm the kind of guy where people goes AFTER being "well paying" consultants... and AFTER it goes down. That's why I'm amazed by your kind to keep being "well paid".  |
|
|
|
|
Show Posts
