http://news.netcraft.com/archives/2005/07/04/php_blogging_apps_vulnerable_to_xmlrpc_exploits.html
single quotes? whodathunkit?
I wouldn't be so inclined to say that all PHP users are dumb. There are a lot of PHP utilities out there that are very secure. PHPNuke is not one of them.
It's not a flaw in a PHP utility, it's a flaw in a PHP library that's fairly widely used. Furthermore, it's a really, really idiotic mistake that any decent programmer should have understood not to make.
Snarky!
It's so cute how he blames it on the programming language instead of the crap libraries and crap code that uses the crap libraries. Nothing wrong with the language (other than a bad case of the ugly stick)
The language was just following orders!
>>6 The guy who wrote it (a friend of mine) and his wife are both programmers and have many bad experiences with PHP. Now they are both very much fans of Python, and little else.
The bug was eval() being used inappropriately, but on a deeper level it had to do with the way that in php, string interpolation is done via the grammar of the language.
For the purposes of the example, I'll illustrate a non-stupid usage in PHP of string interpolation, SQL.
execute("UPDATE foo SET age = '$age' WHERE id = '$id'"); seems perfectly reasonable, except that in this instance, we have a situation where an attacker could 'inject' data into the sql query by crafting a string
?age=14',access_level='admin
Giving the attacker's user account admin access.
The solution is to use mysql_quote_string, making the code more verbose, i.e.
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
But this isn't right yet, there's a possibility that gpc_magic_quotes is on, in which case you have to remove those quotes before you do this, otherwise you\'ll get that nasty bug where \' quotes get a \\ infront of them when they\' retrieved from the database. (bash.org suffers this at the moment).
so:
if (get_magic_quotes_gpc())
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
But! that's wrong again. This can be attacked based on what combination of mysql character encoding is being used, so we have to change this again:
if (get_magic_quotes_gpc())
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_real_escape_string($age)."' WHERE id='$id'");
Okay, now that's all over, lets look at how a real language handles it. Instead of using string interpolation that requires the above series of backflips to escape each untrusted argument, and very_long_function_names and string concatenation to break the very feature that makes php string interpolation easy, this is how to do the same kind of thing in perl or python, two other scripting languages.
$db->execute("UPDATE foo SET age=? WHERE id=?", $age, $id);
and
db.execute("UPDATE foo SET age=%s WHERE id=%d", (age, id))
By doing string interpolation via a library call that is aware of the specific needs of the database, it's possible to moot the entire issue.
PHP is stupid, and so are its users for putting up with this crap.
/me applauses in the background.
And here I used to wonder why Perl's DBI did that. Great post.
"mysql_real_escape_string" is a totally hilarious function name.
"Nah, we were just kidding about that one. Here's the real one!"
My favorite is mcrypt_module_get_supported_key_sizes. Hey, self-documenting code is good, but that's over the top.
There's also gems like recursiveiteratoriterator_getsubiterator.
>>9
That was most enlightening, thank you. As a "young" PHP coder (scripter?) I'm aware of these issues, but didn't know how they could be exploited until now. So far my practise has been to sanitise every bit of input from the client. I don't know if this is too inefficient or kludgy for other uses, but for me it's perfect.
PHP has better things, though. PEAR has a DB interface module that I believe does things like that to make it all safe. (syntax like C's printf where it's correct to do printf("%s", stringVar) and whatnot. I haven't heard of any vulnerabilites with it, but then, I haven't checked. Either way, it's a much nicer interface than using lots of ugly PHP function calls.
class DBI {
function DBI($server,$user,$pass,$base) {
if (isset($this->cxn)==false) {
$this->cxn=mysql_connect($server,$user,$pass) or die("Connection error.");
mysql_select_db($base,$this->cxn) or die("Database selection error.");
}
}function clean($call) {
if (get_magic_quotes_gpc()==0) {
//This will hopefully kill injection attacks. Hopefully.
$call=mysql_real_escape_string($call);
}
return($call);
}
function myassoc($call) {
//echo($call."<br />");
return(mysql_fetch_assoc(mysql_query($this->clean($call))));// or return null;
}
function myresult($call) {
//echo($call."<br />");
$dog=mysql_query($this->clean($call)) or die(mysql_error()."<br />".$call);
if ($dog===false || mysql_num_rows($dog)==0) {
return(null);
}
return(mysql_result($dog,0));
}
function myquery($call) {
//echo($call."<br />");
$dog=mysql_query($this->clean($call)) or die(mysql_error()."<br />".$call);
if ($dog===false) {
return(null);
}
return($dog);
}
} $dbi=new DBI("server.xyz","username","password","database);
$result=$dbi->myquery("blah blah blah")
That can't work, can it? It'll escape all the quotes that are supposed to be in there too. You need to separate out the inserted values and the query itself.
Aw, hell. Well, the code works flawlessly if Magic Quotes is on, but I tried turning it off in php.ini, and sure enough, it severely broke things. Hmm, and I thought I was just around the corner from shipping this thing, too. Good thinking.
Ah well, it probably won't be that bad. I can just take the clean() call out of the myassoc()/myarray()/myquery() functions, then just run clean() on every bit of text that comes in otherwise. Fixing this shouldn't take too long. Thanks again for the heads-up; just as with other things, it often takes another pair of eyes looking over someone's code to see where they screwed up.
(Heh, maybe PHP users really are dumb...)
Perl fanbois can get quite idiotic, bash PHP, and bash PHP programmers, when it's they who are bad PHP programmers.
mysql_query(sprintf("UPDATE foo SET age='%d' WHERE id='%s'", $age, $id));
That's the equivalent to Perl's. And BTW, you shouldn't be calling mysql_query directly. Instead, use a DB abstraction layer, like ADODB, PDO, etc.
So stop bullshitting and learn proper PHP first if you want to point out its flaws.
Hey, when you can't drive, don't blame the car.
age so you can rage
Uh... yeah.
$id="0'; UPDATE foo SET access='admin' WHERE id='me';"Does your code snippet there protect against that? The only thing sprintf will do is protect you against insertion in number arguments. Strings will still leave you wide open for attacks. You are missing the point completely.
The only language I've seen that didn't accidentally encourage bad programming practices is Pascal, but it's not used much professionally. PHP's strong suit is string parsing and handling, but it's up to the individual programmer to recognize when commands and functions get too powerful. PHP's weakness is that its low entry barrier doesn't discourage sloppy programming.
PHP users are dumb only in the same vain that Basic programmers or Bash scripters or C++ programmers are dumb: The techniques for good solid programming have been taught for decades, regardless of language, but too few programmers recognize the consequences of skipping basic data sanity checks, even after getting bit by the resulting bugs.
One thing Perl has that PHP doesnt: Taint checking
Y'see, with taint checking on, it forces the code and the programmer writing it to be more secure about vars/arrays that have values set by the user. You then regex/substr/whatever any data that was inputted, "untaint" it, and voila! More security. To do that in PHP requires a bit more, umm.. is it even possible?
Yes, it's possible, and it's good programming practice to treat external arguments as tainted whether the language forces it or not. Don't get me wrong; I'm not knocking Perl here, but I'm saying dumb programmers exist and are programming in all kinds of languages, online and off, not just in PHP.
So why is it all the dumb ones seem to hang around PHP more than the others?
That's easy: Because PHP targets newbie programmers. There's nothing wrong with that, as I've said earlier - the problem is that PHP doesn't protect protect them from making dangerous mistakes when writing things they do not fully understand. At least, that's part of the point of >>9.
>>26
Perhaps it was a mistake to make PHP [b]look[/b] so easy. The good programmers doing PHP just because it's more productive for certain tasks get bashed all the time by the Perl fanbois.
Which tasks are those, exactly? Mixing HTML and code is one, but that doesn't seem to be what you're referring to.
>>28
I was referring mainly to that, besides some system scripting (where I'm using both Perl and PHP depending on what I feel like using).
>Mixing HTML and code is one
This is actually considered bad practice nowadays. I personally can't stand scripts that mix HTML output with code... they're an eyesore, and they cause you to have to read or write at least two files' worth of code at once (the script and its output). Even for small projects, I'll use templating of some sort.
I think one of PHP's strengths is its ubiquity and its ease with respect to getting it to do its original purpose; that is, chuck output at a web server and to a web client. I considered switching to Python a couple of weeks ago, but it's such a pain for web output, namely because there's so many ways that that can be done; as a slow CGI script, as a FastCGI script, using mod_python, using Python's built-in web server and/or a server built in Python itself... What a mess! Is there any way to write a single script that will work the same on all possible setups? With PHP, it's not a concern.
(I'm still possibly interested in switching, though, so the question above is not rhetorical if someone knows the answer...)
> This is actually considered bad practice nowadays. I personally can't stand scripts that mix HTML output with code... they're an eyesore, and they cause you to have to read or write at least two files' worth of code at once (the script and its output). Even for small projects, I'll use templating of some sort.
And yet, this is the one thing I think PHP was ever good at. And thus it seems to me that PHP is busy abandoning the things it was designed for and was good at, in exchange for becoming a solidly mediocre scripting language. It is as if the language has this huge inferiority complex towards the other scripting languages, and wants to be just like them.
> I considered switching to Python a couple of weeks ago, but it's such a pain for web output, namely because there's so many ways that that can be done; as a slow CGI script, as a FastCGI script, using mod_python, using Python's built-in web server and/or a server built in Python itself... What a mess!
So flexibility is a drawback now? If Python is anything like Perl in this respect, you'll only need to follow some basic good programming practices to run properly on anything. Also, you can just design to be run as a normal CGI script, which is the overwhelmingly most common option.
> Is there any way to write a single script that will work the same on all possible setups? With PHP, it's not a concern.
...and I can't just let that one slip by: What about the myriad of different PHP installation options? Magic quotes? Safe mode? Differing PHP versions and installed modules? Don't go pretending PHP is some perfectly homogenous environment.
> It is as if the language has this huge inferiority complex towards the other scripting languages, and wants to be just like them.
Not rly, but there seems to be a lot of anti-PHP fanbois for some reason, who will bash even its name.
> What about the myriad of different PHP installation options?
Ever heard of ini_set(), pal? Learn to use PHP properly before being a fanboi against it.
> Many settings, although they do get set, have no influence in your script.... like upload_max_filesize will get set but uploaded files are already passed to your PHP script before the settings are changed.
> [[[Editors note: Yes, this is very true. Same with register_globals, magic_quotes_gpc and others. ]]]
Why am I, who knows hardly anything about PHP, correcting you here? It's easy enough to dismiss anyone who has an opposing opinion to your own as a "fanboi", but it neither makes for good discussion, nor does it make you look very clever when you go ahead and get it wrong.
Next up, try presenting some actual arguments and opinions beyond simple personal attacks, OK?
I don't know enough about PHP, so I've been largely avoiding this joyous thread. However, I took a look at the documentation for ini_set(), then looked at all directives listed in the appendix.
Yikes that's ugly.
>So flexibility is a drawback now?
Of course not; flexibility is why I want to switch to Python for all my projects in the first place. I guess you could say, though, that Python is so flexible with respect to web apps that I have no idea where to start with one.
>...and I can't just let that one slip by: What about the myriad of different PHP installation options? Magic quotes? Safe mode? Differing PHP versions and installed modules? Don't go pretending PHP is some perfectly homogenous environment.
You have a point, though, from my experience, most installations are fairly "normal," and it's not that hard to stick with standard PHP modules. But I was speaking with respect to just getting output to the web client.
Ignore what >>32 says about ini_set(). As far as I can tell, that only works if you have permission to tweak those settings, which isn't likely if you're using a shared server.
>most installations are fairly "normal,"
To expand on this a bit, if you're a hosting company, you have pretty good incentive to use a set-up of PHP which is widely compatible, because you're not going to want to deal with support tickets from every schmuck who follows the installation directions for phpBB to the letter but still can't get it to work because you've tweaked some esoteric setting or other. Most of those settings are for people who are running their own server and need to specifically tweak PHP just for their needs. This is why, aside from some common tweaks (magic quotes namely... safe mode has no effect on 99% of scripts), having to adapt your script for different PHP environments isn't an issue.
Well, the same is true for other languages (although I guess you are already heading towards esotericness by using Python in the first place), and in the case of Python the common case would be plain CGI. That's what you'd design for if you wanted a script everyone can use. If you were designing for a webserver you have full control over and wanted to tweak for speed, you'd probably be using mod_python. The rest are fairly esoteric.
I haven't used mod_python, but the corresponding mod_perl will run normal CGI scripts as long as they follow some simple guidelines. It also offers some additional features that aren't available to CGI scripts, but if you don't use those, it's easy enough to make scripts that run on either.
I don't know, mixing code and html is no problem when using, let's say ruby on rails, but I've seen some awful stuff with php and some of the java frameworks out there.
The important thing is separating your presentation layer from the others and keeping the presentational code simple, readable and keeping as much logic away from it as possible.
That's true for large apps, but for quick hacks, nothing beats mixing code and HTML. And I always though PHP was good for the latter but not as much the former, yet the direction the developers of the language have taken has been consistently away from the former.
The PHP developers don't seem to know what they're doing at all, dragging the language in several directions at once and trying to fit every programming paradigm in a language that's only good for the simplest of the simple dynamic websites.
∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧ ∧＿∧
（ ・∀・） （ ｀ー´） （ ´∀｀） （ ﾟ ∀ﾟ ） （ ＾∀＾）
（ つ┳∪━━∪━∪━━∪━∪━∪━┳⊂ つ
｜ ｜ | ┃This thread has ended┃ ｜ ｜ ｜
（_＿）＿） ┻━━━━━━━━━━━━━━┻（_＿）＿） Thank you.
The way PHP was envisioned on working is in a broken way. By default PHP supports and pushes for the mixing of business and presentation logic.
To by default PHP supports very bad practices.
Even worse the lead developer of PHP said he doesn't know how to make a programming language. This is obvious. Just look at the shitty syntax in PHP, the arbitrary function names, the 49 different functions which the do exact same thing.
relevant?
There's not all that much wrong with PHP. If it didn't have crazy scoping rules and $ variables I wouldn't have much that I'd complain about.
Those can be disabled in .htaccess, as far as I know.
"those" are magic quotes
>Although register_globals now defaults to off in the PHP distribution, the majority of web hosting providers re-enable it
Um... not.
even PHP is most user create their Homepage with... is because PHP have GPL license.. i Can't say PHP is very tought.. He has weakness tooo...
BTW... is good if your languages using class.. not only simple echo echo procedure..
>>39 I agre with u... mixing html with php is wrong... u should use bbcode instead and re produce using procedure before show in HTML/homepage
>>52 is exceptionally on-topic, I'm thinking.
>>53
i concur.
Ouch. lol
i have no idea what this does, but it showed up as a result in a google search and i thought it might be relevant:
http://www.64bit-world.com/forums/impex/tools/cleaner.php
Wow, that's awesome. Listing the contents of all private messages at the end is a nice touch!