Re: PHP File Upload Security Hole - Still No Fix?

Lars Torben Wilson <torben@php.net> wrote: > > How are people supposed to know how to program PHP? Are they allowed to > > go looking through the source code, to find hacky tricks that work in > > today's CVS tree, and then complain when they don't work tomorrow? > > Certainly. It's their own damn fault if they get bitten, same as it is > my own fault if I write code depending on any undocumented feature in > gcc. Exactly! This is my whole damn point. It is not possible, for example, to write file upload code without either (a) being insecure, or (b) relying on undocumented features. Since you and I both agree that relying on undocumented features is not acceptable, this only leaves the option of writing insecure code. I suggest you educate your fellow PHP developers on this matter. > > This is great, for people to add examples and tips. It is no use for > > providing documentation of what the functions do. > > Quite the contrary. That's what many use it for, but that's a > different issue. :) Anyone, meaning *anyone* (even you, Jon), can look > at the code, figure out what a function (or operator, or feature, or > whatever) does, and add a note regarding it. That only tells you what the function does *today*. It doesn't tell you what it will do tomorrow. Only the PHP developers can tell us that. Exactly as we just agreed at the top of this message. > > If you are writing code to produce HTML output, as I think I can safely > > assume most PHP code is, and you have never used htmlentities, then your > > code is almost certainly completely broken. > > Would you care to elaborate? Some examples to prove your point would > go down real good right about now. See the "Cross-Server Scripting" issue on BUGTRAQ, for example. Even something like $row = mysql_fetch_array($res); echo '<h1>',$row['title'],'</h1>'; is obviously broken (unless 'title' is intended to contain HTML, but this is rare), but if the person who edits that field in the database is trusted then this is simply a bug, not a security issue. > > Ditto, if you have written code to generate URLs. > > Mm. Unless you build them by hand. Jon, I've been coding PHP for some > years now, and while these functions certainly get used, you're > completely overstating the number of lines of code on which they turn > up. I'm not overstating anything. I don't even particularly give a damn about this issue. I simply suggested that a couple of functions might be nice with shorter names, and gave *suggested examples*. If you don't like my examples, fine. Whatever. The main issue anyway is access to CGI variables. I hope no-one is going to claim that these are not frequently accessed. > I have many more lines of PHP which are not concerned with HTML than I > have lines which are. If I need HTML, I can simply drop out of PHP > into HTML and do it there. With an editor or something. You don't need htmlentities() with static HTML - only when you're outputting generated HTML. In which case you have to do it in the PHP section. > You haven't the right to judge others on the value of their > volunteer work until your own efforts to improve said work can be > demonstrated to match those of the people you judge. I can't cook, but I can tell burnt food when I eat it. Besides which, I don't claim the right to judge anything. I'm simply pointing out a few observations. You can do something about them or ignore them as you will. I can't force people to do the right thing. They have to decide to by themselves.