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!
>>56-57
i would tell them about it, but...
http://www.64bit-world.com/modules.php?modid=4
and i was also unable to figure out how to post on their forum... kept giving me some nonsense about "You are not logged in" and "The administrator may have required you to register before you can view this page."
Send it to webmaster@64bit-world.com and maybe a few made-up names @64bit-world.com (since IPS often redirect it)? Use a throwaway mail account if you do, though, people who keep such pages live may not understand you're doing them a service by notifying them.
Thanks all
>>62
You're welcome :)
> vBulletin Message
> No Thread specified. If you followed a valid link, please notify the administrator
lol, how nice of them.
>>61
lol, they fixed dis, but forgot about www
http://tinyurl.com/75k8f
In response to topic. Duh.
When following design patterns like Model-View-Controller (MVC) in PHP, it is important that the the HTML View code is well separated from control code. I see most people doing this using a template system like smarty. But can template systems become bloated and effect performance?
I like to use the PEAR libraries (http://pear.php.net/) as much as posable for their stability and easy to use APIs. However, PEAR does not seem to have a fully featured template system that works well with other PEAR components like HTML_QuickForm and DB_DataObject.
Can anyone suggest the best template system to use with PEAR for building web apps?
PHP is the best templating language you could use with PHP. Bad template systems make it harder to get stuff done, and great ones merely make it more complicated, error-prone, and require to learn yet another language.
Well, one of the many advantages of using a templating system is that it makes it easy to tweak the template without worrying about possibly mangling the PHP code itself. So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
Also, Smarty has a resource-saving caching system, which is way better than "live"-rendering everything as you would have to do just using raw PHP -- unless you were to write your own caching system.
> So if you want to make it easy for others to design templates for your system, Smarty is the way to go.
what
For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
PEAR already provides a decent cache, you don't need to depend on Smarty's one.
Choosing a templating system because of a minor feature like a cache doesn't sound very wise, consider what will happen if using this template system is a maintenance nightmare (but hell, what isn't one in PHP).
I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
For a really simple app, maybe you could pull it off in some meaningful manner, but for anything even a little bit complex, there's just too many cross-dependencies between presentation and logic.
> I'm pretty sure the idea of managing to separate program logic and presentation for something that needs to output HTML is largely a myth. I've tried, again and again, to do this, but no matter what, you end up with HTML in your program code or program code in the HTML (even if the program code is some templating language, it's still code).
That doesn't mean you shouldn't make an honest attempt.
I like the way Wordpress or Ruby on Rails apps do it:
The first uses PHP files as the templating language. You use well-documented functions to fetch data, so the templates are really flexible, yet free enough from business logic, especially since plugins are quite easy to write.
In Ruby on Rails, the views are .rhtml templates which work a lot like PHP, which look like this:
<% @things.each |thing| %>
<div class="thing">
<%= link_to thing.name, :action = 'show', :id = thing %>
</div>
<% end %>But you'll still often code methods that spit out some HTML snippets outside of the views.
If you want to suceed at web applications, you certainly need a lot of discipline and to never allow a prototype to grow into a module without some serious clean-up, but you shouldn't follow the MVC approach all the way: the end users don't want to interact with applications, but with websites, and most web apps (especially PHP ones) feel way too stiff because coders are too disciplined to know when to blur the line between code and data.
The key to keep the website agile and the app seamless is to know the rules, to apply them religiously, and to break them all the time. That's really hard.
Well, sorry for going way off-topic.
>>71
I'd settle for the code in the HTML being side-effect-free and just evaluating simple expressions, perhaps based on cookies for instance.
>>74
It was a response to >>71. "Code" in the HTML is okay by me, provided it only consists of expressions to be evaluated and spliced into the output, and it doesn't change any data on the server, i.e. no side effects. In an imperative language, that really means just write code that gets some data and prints it, nothing more.
>For a non-programmer, Smarty would be as difficult to learn as some simple php. It'd be hard to beat PHP at being a simple straightforward template language.
Yes, if the non-programmer is trying to do programming-type stuff with the templates. But if they're just trying to make simple changes to the appearance of the rendered page, then it's best to keep them separated from the actual code which they could accidentally mess up, and they'll feel much less uncomfortable looking at it. A page marked up with Smarty still looks mostly like a normal HTML page, whereas if you've combined and interweaved the two, it can get very confusing.
For non-programmers who just want to change the appearance a bit, HTML with bits of non-vital code in it is better than vital code with bits of HTML in it.
>a minor feature like a cache
I would hardly call it a minor feature...
> I would hardly call it a minor feature...
It shouldn't be considered when choosing a templating though. Features like that should be regarded as marketing when deciding wether to use a system, then just as a bonus afterwards.
And it IS a minor feature because any decent templating system should make caching trivial. The hard part is making sure the cache never goes stale, and no template system will do that for you.
Well, that's a good example of what I was talking about. That Ruby -in-HTML code is pretty much incomprehensible to anyone but a Ruby programmer, and thus, the only person who can safely work with the HTML templates is still the programmer.
>>78
Yeah, this is why the code in the HTML should just be expressions to evaluate (i.e., math, basically).
>>78,79
I still don't think it's good enough a reason to use 'dumb' templates. They cause inflexible apps, where the designer is only allowed to write HTML loops in a well-defined zone of the page and just insert placeholders. Sites made this way often look like data dumps straight from the DB, with a lot of needless metadata around, and a lot of opportunities to make the user's life easier lost.
I think that the designer must be able to do very basic programming (loops, conditional logic), and the coder must understand design (but doesn't have to be talented). Ideally, they should be the same person, but that isn't often possible. The coder should be able to do most of the HTML the designer requires, so that the designer should only need to work with CSS.
As I see it, the choice is wether to have a programming language, or just having placeholders. In-between options are also possible, but they tend to be the worse of both worlds. I will always go for the first option, because it allows me to do a better work in less time - maybe that's just because I'm lucky enough to be able to do both the app and the design myself, but when I see the limitations and missed opportunities caused by using non-coder-friendly templates, I just think there's no place in web apps for people who aren't versatile enough.
>>80
News flash: You don't need loops to program. Look at any functional or array language.
I am not at all saying the code in the HTML shouldn't be powerful, but writing it in an imperative style would be distracting and easy to mess up.
> News flash: You don't need loops to program. Look at any functional or array language.
Thank you so much for the information! As a designer, I struggled a lot to understand looping over some content for my website, so I hit wikipedia:
> Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions. Functional programming emphasizes the definition of functions rather than the implementation of state machines, in contrast to procedural programming, which emphasizes the execution of sequential commands. A purely functional program does not use mutation: rather than modifying state to produce values (as is done in imperative programming), it constructs new values from (but does not overwrite) existing values.
This is definitely what I needed for my templates! Oh boy, my websight's gonna be great.
From a webmasters perspective, PHP is a fucking security nightmare. There are about a hundred thousand different ways to execute arbitrary code on a webserver using PHP just by uploading a simple script. Using mod_security on Apache takes some of those out, but even then a badly designed PHP script can open up your server to everyone and everything. This is probably same for other languages, but never has such a bad language existed which allows for such... originality when writing bad code that works yet doesn't.
All in all I've sworn on PHP for being so shitty. Either you castrate it with mod_security (twenty pages of rulesets) so that only dynamic rendering works, or you enable extensions and run the risk of getting your server fucked over in five minutes. And PHP is especially fun because it doesn't support modern threading techniques like Perl or Ruby-On-Rails. No no no, it has to fork off the httpd into a separate process with a separate memory allocation every time a single .php script is run. Thanks guys.
ADMIT THAT RUBY IS AWESOME.
SWITCH FROM PHP TO RUBY.
> ADMIT THAT RUBY IS AWESOME.
> SWITCH FROM PHP TO RUBY.
NEVER.
Or at least not until I ship, I really need the competitive advantage so I'd appreciate it if Ruby kept its 'lol jap crap' reputation for a few additional months.
Ok, this has sat here for days now, and I still don't understand a word of it. What the hell are you talking about?
I think he's working on a commercial product coded in PHP.
Good luck with that.
I think he's a convict and is going to get shipped to Australia.
He's making a product in Ruby, and considers it a competitive advantage. He wants the competition to remain using PHP so he'll have the leg up.
>>88
So he wants to ship something that he hopes remains considered "jap crap"? How does that make sense?
Heh.
Most users (probably) don't care about the underlying language, so long as the software works well.
I still say he stole a loaf of bread and is getting shipped to Australia.
>>91
We don't want him.
>but even then a badly designed PHP script can open up your server to everyone and everything.
That's why if you code a WELL DESIGNED PHP script, PHP doesn't suck and isn't unsecure. Amazing! As posters in the beginning of the thread have stated, learn it before you hate it. It's very possible to code a PHP script which can't simply be altered by outside means.
Of course, I'm going to admit right now though that NO CODE is ever 100% secure. There's always another way in EVERY language where the server can be broken into.
>>93
That's fine in theory. But in practice, I need to use other people's libraries, because re-implementing things would often take more time. And a significant amount of open-source PHP libraries are done by stereotypical dumb php users. Even if you are very security-conscious, there's nothing you can do about it.
And most quality PHP code available will assume you are using a shared hosting environment, aiming for the lowest common denominator in terms of features used.
It is in large part a hobbyist language. You can use it to make secure scripts and quality code, but you just can't rely on the community.
Because of this, I only use PHP for small independant web scripts that won't do anything more complicated than accessing a Sqlite database.
In a way, PHP is a victim of its own success and simplicity, which attracted the attention of crap-writing, copypasta, trial and error n00bs, but this doesn't mean you can't come up with high quality code in a highly productive manner with it, and some libraries are like this. This comes from an expreienced PHP developer who has had to deal with both good and terrible PHP code.
well!! sory about that!!
every code have weakness.. but the person try to find weakness is not bad person..
PHP are dumb.. that shock me up.. but i realise it..
btw... the source php are from perl.
>>96
Thanks for bumping
>>98
lurk more
>>100
I tried hard, but I just can't guess what the hell this is about (and I used to be a big KDE nerd and PHP user)
>>101
it was written by a PHP user.
see thread title.
Related news: http://www.informit.com/articles/article.asp?p=603037&seqNum=1&rl=1
Seriously, I understand that you can forget one form field now and then, shit happens, but not escaping any user input in the whole app? Where did those people learn programming? Even a "PHP for Dummies" book most probably has a chapter about the basics of securing your application now.
//Function: mysql_queryf($query, ...)
//Description: A MySQL query command in the similar format as printf, sprintf, etc. The parameters are automatically escaped to prevent injection.
//Only accepts codes %s (for strings) and %n for number values.
//Usage Example: mysql_queryf("SELECT * FROM table WHERE id=%n AND name=%s", $id, $name);
function mysql_queryf($query)
{
$finalstring = "";
$numargs = func_num_args() - 1;
$stringpos = 0;
$retstring = "";
for ($argnum = 0; $argnum < $numargs; $argnum++)
{
if (($stringpos = capture_till($query, $stringpos, "%", $retstring)) !== false)
{
$finalstring .= $retstring;
switch (substr($query, $stringpos, 1))
{
case "s":
$str = func_get_arg($argnum + 1);
if (get_magic_quotes_gpc())
{
$str = stripslashes($str);
}
$finalstring .= "'".mysql_real_escape_string($str)."'";
break;
case "n":
$finalstring .= "'".intval(func_get_arg($argnum + 1))."'";
break;
}
$stringpos++;
}
else
{
$finalstring .= $retstring;
break;
}
}
if ($stringpos !== false)
$finalstring .= substr($query, $stringpos, strlen($query) - $stringpos);
echo $finalstring;
}
function capture_till($string, $offset, $criteria, &$retstring) //returns a string starting at $offset of all content until it reaches the $criteria string
{
if (($pos = strpos($string, $criteria, $offset)) !== false)
{
$retstring = substr($string, $offset, $pos - $offset);
return $pos + strlen($criteria);
}
else
{
$retstring = substr($string, $offset, strlen($string) - $offset);
return false; //criteria never met
}}
sorry, posted old test version of the code by mistake.
Replace the line:
echo $finalstring;
with:
return mysql_query($finalstring);
They say there's no simple way to fix this. That can't be true. How would you fix it?
>>106
I guess their system is written in a way so that there is no easy way to fix this. That's most probably not PHP's fault, but poor design, it probably seemed like a good idea at the time mediawiki was originally written but doesn't seem like such a good idea now, but when you already have a huge, complex system running, even minimal changes are pretty hard to do.
As I posted in the other thread >>106 started (which apparently was deleted): [[The]] problem is in making both of these links lead to [[the]] same page, it seems.
Notably, Wiktionary works just fine with both:
http://en.wiktionary.org/wiki/Britain
http://en.wiktionary.org/wiki/duck
I really wish they'd find some way to get it working on Wikipedia too, though, so we no longer have to deal with things like http://en.wikipedia.org/wiki/IPod . Perhaps just have MediaWiki try shifting the case on the first character if the article isn't found with the original casing or something.
But yeah, it's definitely not a PHP thing.
It may not be a PHP thing, but it is the Unix disease of case-sensitivity. No interface that is exposed to users should ever be case-sensitive. Normal people do not differentiate between words written in different case.
>>110
most unix users do, and since unix was written for unix users, it's entirely appropriate that it be case sensitive, as unix users expect. thanks.
> normal
yeah we're freaks, ok so what. welcome to /code/.
This is a list of words that have several unrelated meanings, where one of the meanings happens to traditionally have different casing than the others. These are two different issues that happen to coincide, neither of which implies that the English language itself is case sensitive.
Just because you've gotten used to something, does not mean that that is a good state of affairs. One of Unix' biggest HCI shortcomings is its case sensitivity. I'll also note that Mac OS X has wisely removed this limitation.
>>113
gotten used to it? how, exactly, do you determine from your end of the interweb that i, personally, have "gotten used to it", as distinct from having "found that the way unix does things fits my brain well"?
remember, once upon a time, someone sat down and decided that unix was gonna be case sensitive; to that person, the most natural interface was one in which case distinctions were important. it's awfully patronising of you to suppose that that person didn't know wtf they wanted or needed.
but your original point was that "normal" people don't think this way. i'm refuting your misconceived idea that everyone who touches a computer fits your norm.
Unix was designed when processing power was really, really scarce. Case-sensitive matching is cheaper than case-insensitive matching, both in terms of time and code size. For a primitive system, case sensitive is the default choice. Doesn't mean it's the right choice on a more capable system, though.
PS: How are you refuting my argument? Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
> Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
Did you quote any statistics or other facts that show that most people don't think case sensitivity makes sense?
I, for one, think that case insensitivity is quite hard to get one hundred percent right even/especially nowadays.
"Because of IRC's scandanavian origin, the characters {}| are
considered to be the lower case equivalents of the characters []\,
respectively. This is a critical issue when determining the
equivalence of two nicknames."
As for personal preference, I pretty much don't care either way. I haven't ever had any problems with case-sensitive systems (I kind of mostly use the right case anyways, might have something to do with my first language beeing German), some slight problems on case-insensitive ones (When copying files over from a case-sensitive one). For me, case sensitivity doesn't really change usability, and I would suspect it's the same for most users.
Case closed.
Regrettably, this doesn't extend to the applications.
>>118
Um... yeah... what?
I used case-sensitive CLI's and case-insensitive CLI's, and I prefer neither.
Personally I use uppercase to distinguish some files/directories from others (I tend to work in a *nix CLI), mainly so the uppercase show up higher in listings. I like the side benefit that if I type "C<tab>" the shell knows to expand "Cool/" instead of "code/", if I type "r<tab>" it knows to expand "random.c" instead of "README", and so on. I'm not dogmatic on the matter but I find case-sensitive names slightly more useful for my purposes, because of this.
> but your original point was that "normal" people don't think this way. i'm refuting your misconceived idea that everyone who touches a computer fits your norm.
> PS: How are you refuting my argument? Did you quote any statistics or other facts that show that most people think case sensitivity makes sense?
I don't think any "statistics" or "other facts" about "most people" are at all relevant here. please actually read, understand, and think about what i'm saying here, instead of merely assuming that i'm arguing the point you seem to think i'm arguing (hint: i'm not). thanks.
Why don't you just spell out what you're trying to say? Because it is anything but clear.
I've already explained it two or three times. If you can't put down your preconceptions and actually read what I've previously said, me saying it again is hardly going to help any.
$age = stripslashes($age);
mysql_query("UPDATE foo SET age='".mysql_escape_string($age)."' WHERE id='$id'");
huh?
$age = round($age);
$id = round($id);
mysql_query("UPDATE foo SET age='$age' WHERE id='$id'");
Because obviously all data ever sent over the net is integers. Thanks for clearing that up for us.
>>124 Yeah I get it, but your wrong. Actually nether one is right because you're not doing any validation.
if(is_numeric($age) && is_numeric($id)){
if(!mysql_query("UPDATE foo SET age='$age' WHERE id='$id'"))
die ("Error: ".mysql_error());}
else
die ("Age and id must be numbers.");
And even then you're still wrong because who is going to let the user enter any ID number and change the value?
WHERE id='$id' and memberid='".$_COOKIE['memberid']."'
And even then you're STILL wrong because $_COOKIE isn't safe.
But, if done right php can be safe and secure. And if done wrong perl or python or anything else can be insecure.
Yahoo, YouTube, Digg, FaceBook, Wikipedia, Friendster, Photobucket and TONS of other high profile sites use PHP as either there main programming tool or use it extensively. I mean come on... Yahoo uses it and they are #1...
I do believe that PHP-coders are dumb, not all of them of course but simple abstract languages like PHP are creating dumb programmers.
They don't understand the basics of programming and never will if they continue to use only abstract languages.
They need to understand that abstract programming is more like scripting, because you're actually telling an interpreter someone else wrote how to produce bytecode or direct native code.
Until they learn how to write an interpreter of their own, they will never truly understand programming.
> simple abstract languages like PHP are creating dumb programmers.
I don't consider PHP a particularly abstract language. Ignoring that though, do higher-level languages make a person more stupid, or free them from silly minutiae to consider even higher-level concepts? Listen to Lisp or Haskell programmers some time.
> Until they learn how to write an interpreter of their own, they will never truly understand programming.
Absolutely, but you know, the same could be said for assembly programmers too.
> do higher-level languages make a person more stupid, or free them from silly minutiae to consider even higher-level concepts?
higher-level languages don't make them stupid. not learning lower-level langauges does.
it's also true if you swap "higher" and "lower".
>>129
Yeah well i'm not all up on the terms used today, i didn't even know what an abstract language was until last week when a java programmer explained it to me.
Of course abstract programming gives you more time for other things but you have to take the good with the bad and you have to recognize the bad.
Basically you give up control in return for speed and usability. You might call me an old fart but it's my opinion that usability is not something you should buy for the price of control over your programs execution, not as a true programmer.
That's the main thing there, to differ between scripters and programmers. To me a scripter gives up control to another persons program while a programmer tells the system he's programming what to do and how to do it.
It all boils down to this, lazy programmers. We're all getting lazier by the generation and why should IT be any different? It's not, lazy programmers are what started some of our biggest break throughs but they are not so fun if their abstract languages create generation after generation of programmer that doesn't understand what she's doing.
It all depends on what you want to do in your life, if you want to create webpages and software in java while saving a ton of time then be my guest. But what if you want to be the one creating an abstract language, an interpreter or maybe a compiler. You need a language that would be beyond you. So basically, PHP is a tool with it's own purpose that it might do very well but you will never build a house with one tool.
I'm pretty sure that "abstract language" doesn't mean anything.
http://www.dangermouse.net/esoteric/piet.html is an abstract language.
> it's my opinion that usability is not something you should buy for the price of control over your programs execution
I disagree. Languages are just another user interface, and should be made as easy as possible. More done in less time, with fewer bugs, higher maintainability and less aggravation.
Why should I spend all my time worrying about low-level issues when it's only something to be concerned about a small minority of the time? For that small minority of time there's usually a hatch (C API or FFI) I can use.
Some domains require the degree of control C offers all the time. That's okay too.
> It all boils down to this, lazy programmers
Laziness is a virtue, &c.
More seriously, why would you use a low-level language when a high-level language could get it done in a quarter the time or less?
> But what if you want to be the one creating an abstract language, an interpreter or maybe a compiler. You need a language that would be beyond you.
You don't need a low-level language to write an interpreter. You don't need to know a low-level language to write a compiler either. It just helps if you want it to go faster or not use some intermediary language on the way to native.
>>127
That's still crappy.
You should use "UPDATE foo SET age=? WHERE id=?" and then set the parameters.
Two reasons:
> I disagree. Languages are just another user interface, and should be made as easy as possible. More done in less time, with fewer bugs, higher maintainability and less aggravation.
Using an "easy" language doesn't automatically make your code have fewer bugs. It makes the bugs harder to notice, which will probably make your code have more bugs.
Not if that "easy" language is CL.
>>136
I find that reasoning suspect. If it were true, we should have never left entering machine code with switches.
Using functions is easier than manually constructing stack frames. Using automatic memory management is easier than manual. Using Pascal-style strings is easier than C-style. Using built-in associative arrays is easier than rolling your own. Using polymorphism is easier than tables of function pointers. Using closures is easier than writing classes with single methods. Using coroutines is easier than allocating your own stacks and longjmp()ing. Using messages is easier than juggling locks. You get the idea.
Every abstraction removes some cruft that you used to worry about. What was once complicated becomes easy. Imagine writing Prolog-style backtracking or cooperative multitasking in C; in some higher languages it's close to "Hello World".
That being said, removing cruft you need to worry about doesn't remove the need for someone to worry about it.
The use of many higher level languages ultimately becomes an exercise in working around bugs in the runtime which you can't easily fix yourself.
>>139
It's not too bad if you choose a nice, fresh language like Python or Ruby. Java is shit, .Net is less so when it comes to bugs.
I have heard more than one LISP advocate state such subjective comments as, "LISP is the most powerful and elegant programming language in the world" and expect such comments to be taken as objective truth. I have never heard a Java, C++, C, Perl, or Python advocate make the same claim about their own language of choice.
> That being said, removing cruft you need to worry about doesn't remove the need for someone to worry about it.
Exactly. It's better that the wheel be only written once. It's for a similar reason we have libraries.
> The use of many higher level languages ultimately becomes an exercise in working around bugs in the runtime which you can't easily fix yourself.
Except that you're not alone. If you start implementing all this on your own, you are. There is power in numbers.
That's true too, but it doesn't make Sun fix bugs in Java any faster. :-)
Perhaps you should not be judging the entirety of the world of programming based on Java.
I ought to add that I cannot take seriously languages -- or libraries -- that do not have a de facto implementation which is OSS.
Well-known languages that fail this criteria: Java, C#, VB, the Lisps (although SBCL looks like it'll fix that), PL/SQL, ABAP.
If a business wants to tie their infrastructure to something over which they have no control, the managers are incompetent. It amazes me how many large corporations are more than happy to hand over the keys to their kingdom, so to speak.
OpenJDK and Mono. VB does blow chunks, though; and companies who would gladly give M$ all of their revenue in exchange for empty promises of security rather than taking matters into their own hands are not worth my time.
A lot of programming security depends on skill; a top-notch PHP hacker can block anything from a simple single-quotes exploit to a full-blown MySQL injection. Of course, a top-notch hacker can also circumvent them as easily as he can block them, but a novice trying and failing to implement security is worse than an intermediate programmer not bothering to try to implement security. And depending on who you're up against, there are some cases where you're boned anyway, but those are rare.
> OpenJDK and Mono.
Mono is not the de facto implementation.
OpenJDK has promise if they can wrestle control of the libraries and language from Sun. Does Sun work on the same repository as everyone else?
OpenJDK development is still managed by Sun. All they've done is moved all the code to a place where more people can play with it, and changed the licence to GPL.
There are other open source Java runtimes though. GCJ / GNU Classpath comes to mind (GCJ can compile Java to native code too!) And there was an Apache implementation which I have forgotten since OpenJDK would more or less obsolete it.
> A lot of programming security depends on skill
But a beginner writing in PHP has a much larger probability of coding up an SQL exploit than a beginner writing in Perl or Python. That is the real issue. It's not about what you can do, it's about what happens in practice.
Why is that? Is it because SQL is more accessible to the PHP programmer? Or is it because Perl and Python are harder to use?
A lot of programming security depends on solid engineering and well-thought out designs. The best PHP programmers think that they just need to be more careful, but even if the PHP programmer writes perfect code, the people who write PHP itself are incapable of writing perfect code- look at the last few releases of PHP, the same security bug being "fixed" over and over again.
Almost all of these bugs are from extensions- things that are for some reason, better to write in any language but PHP than to write them in PHP itself. Why is that? Why is the bulk of any PHP application written in any language but PHP? What is it about PHP that makes it so difficult to express things like money_format() or glob() in PHP? Why do PHP programmers need to resort to such an ugly language as C in order to get any real work done?
>>150
Because, it's damn easy to forget to mysql_real_escape, but it's damn hard to get "SELECT foo FROM table WHERE bar = ?" or something similiar wrong. PHPs standard way of accessing databases is just plain shitty.
I'd like to here more about PHP please.
Why is it so awesome?
>hear
Those are the reasons one might consider it to be “awesome”. We all know and are bored of hearing why one might also consider it “fucking horrible”. The above reasons also make it similar to C and C++.
Hay, I resent the implication that C is somehow similar to PHP! (,ﾟДﾟ)
>Applications : New
>There are not any applications in this category.
>
>Maybe you'd like to add one?
lol not really