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

From: Date: Wed, 06 Sep 2000 12:27:21 +0000
Subject: Re: PHP File Upload Security Hole - Still No Fix?
References: 1 2 3 4 5 6 7 8 9 10 11  Groups: php.dev 
Request: Send a blank email to php-dev+get-32351@lists.php.net to get a copy of this message
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.
having more aliases would be a mess, the finer places of function naming are most external modules and eg. array (array_flip, array_diff...), would be fine if more functions would follow this rule, most important functions are short enough to live with (substr()...), others aren´t. but man does not need get_html_tranlation_table() and quoted_printable_decode() very often, if substr() was string_sub_string(), well that was worth considering a shorter one and if you *really* do need to type html*() and urlencode() that often you´re making some mistake, you´ve heard about classes or even functions (http://www.php.net/manual/functions.php), create some mechanism that does stuff for you and don´t accuse others for you bad programming style PHP is not [put your favourite language here]!!! your most recent msg tops it again and is makes no sense at all
echo '<a href="product.php?id=',htmlentities(urlencode($row['ID'])),'>'; (This is an excellent example of why I prefer H() and U() [;-)]
you´re designing crappy databases and thus you have to apply functions no one else has to apply in those cases (btw, you don´t need to apply htmlentities() after urlencode(), URL is URL there are no unescaped
<&"etc. signs in it) in this special case take care your row_id is an integer too
you don´t need to convert every single value which comes out of the database! theres a thing called database design. btw, to do this on output is not performing well, MOST sites are generating *much* more SELECTs than INSERTs or UPDATEs, thus convert on update and take care nobody touches your DB
The main issue anyway is access to CGI variables. I hope no-one is going to claim that these are not frequently accessed.
If you thought of these HTTP_*_VARS, create some references, no one hinders, you could write $G=&$HTTP_GET_VARS; then access with $G['id']
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.
again, improve your script-logic divide between processing and output and it´ll help if you do "template-programming" and are worried about applying the same functions over and over
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.
you ate burnt wood imaging it was food, it tastes burnt and ought to
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.
I don´t say there´s no truth in any of your endless postings, if you were a bit more smart you´ve had written a message as follows (an example covering only a few of your errors is below) and we all had saved time reading and responding to emotional over-emphasized thoughts: "Hi, I´ve noticed that there are some issues with PHPs security and that it lacks at some points. If I got it right, it´s a big security hole in PHP that need fixing. Incident 1) When I do xxx and yyy I receive zzz instead of aaa. I think it´s related to PHPs uuu handling. A possible workaround is to move rrr to eee and to check qqq against ccc. Incident 2) ... " and so on Here´s what you did: "Hey there´s a BUG in PHP and you DIDN`T FIX IT yet??? Hey what´s up? You´re to damn dumb to fix it to fit my needs... HEY I SAY IT IS A BUG and you´re to damn lazy to fix or merely less intelligent to understand. DON´T YOU GET ME? I said it´s a bug and you are wrong. You are wrong. I AM RIGHT. Well, you can tell me whatever ye like - I´m using PHP and I have the right getting my bugs fixed to fit my needs and the buggy language naming should be changed too to fit my needs. I want to write H(U(I(S(P(gv('HX'),su('PW')))))) cos I use it very frequently, why don´t you support it?" Perhaps you should buy a book "What if there were others, not just me?". I´d say this was the most annoying and less effective thread for a long while. regards, andré -- · André Langhorst · t: +49 571 3201801 · · waldschrott@php.net · m: +49 173 9558736 · · PHP Quality Assurance · http://qa.php.net ·

« previous php.dev (#32351) next »