PHP Flaws - Page 2
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: PHP Flaws

  1. #11
    Hi mom!
    Join Date
    Aug 2001
    Posts
    1,103
    I've evaluated PHP 4.3.10 and my conclusion is that it's completely unusable in its current state.
    Out of curiousity, how did you do that? Also, could you list the 5 most common mistakes in PHP programming, and a way to circumvent that?

    I'm not trying to make you prove your point here, I'd just like to learn from someone who seems to have the knowledge I lack.
    I wish to express my gratitude to the people of Italy. Thank you for inventing pizza.

  2. #12
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Originally posted here by Guus
    Out of curiousity, how did you do that?
    How did I evaluate 4.3.10 ?

    I installed 4.3.10 on my development / testing server, and the fact that my main application I'm currently developing caused it to crash immediately, lead me to believe that it's unsuitable for production use

    I used the same configuration of everything for 4.3.8 and the same web server - that works fine and I've rarely (if ever) seen it crash.

    I tried the latest nightly snapshot too with the same results.

    I believe these are known issues - if you go to bugs.php.net and search for "reproducable crash" bugs in 4.3.10 you'll see there are several.

    Also, could you list the 5 most common mistakes in PHP programming, and a way to circumvent that?
    1. Failing to validate data correctly - this is the main one really. Not checking that positive values are positive. Not checking that values selected from a drop-down, really are ones which were in the drop-down in the first place. Attackers can modify the form so they can enter values which aren't present in a drop-down, so you can't rely on it (not to mention, if the drop-down is dynamically generated, the options may have changed by the time the person submits it)

    2. SQL injections - this topic has been done to death elsewhere.

    3. Thinking they can prevent SQL injections by just being really, really careful. You can't. You can only prevent SQL injections by using techniques which aren't vulnerable to them, for instance, prepared statements or a query builder like DB_DataObjects

    4. Trusting stuff sent via the browser - specifically cookies. Nothing, whether it's a hidden field, or a cookie etc, should be trusted, regardless of whether it's been sent via HTTPS to an authenticated client etc. This is really an extension of 1.

    5. Misunderstanding the security implications of various PHP options - specifically, register_globals (can cause serious security problems), magic_quotes (can cause data corruption), allow_fopen_url (Can cause some compromises). All of those three should be OFF in any new application intended to be secure.

    Slarty

  3. #13
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    I'm not sure how 1-4 are PHP specific. Most of the things you are mentioning, are things that the developer, not the programming language has to be mindful of. You could code c or c++ and not validate input properly. It doesn't make a difference which language you use, you shouldn't trust user supplied input. I think you list deals more with common developer mistakes, then actual php specific. C'mon, sql injections are not specific to php and they only exist because developers don't validate input properly, not because the language itself is flawed.

    In your list, the only thing that I really see as a specific fault of php was registered globals, which now comes turned off by default. I think that the 1-4 list, is mis-leading because they are supposed to be php specific issues, not developer issues, which those are. I think it would be a programming issue if there wasn't a means for the developer to fix the issue.

    Lastly, with PHP growing so rapidly, and especially in the Enterprise, I can't see how PHP isn't production ready.

    Great discussion guys.


    --PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  4. #14
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    With PHP growing more and more rapidly as each day passes, it's to be expected that bugs, crashes, and other Bad Things to be found. You don't create a good product without finding these things out. Apache did not get to be the #1 used web server overnight and definitely not because it had flawless code. As long as code is written by people, it will always be flawed and even if machines wrote it, it still has the human factor in it somewhere and that's been proven to be flawed, exploited, bypassed, corrupted and bribed and all of these way before the advent of computers. They spent years building the Great Wall of China and how did it get circumvented? Bribing the guards. You see where this is going.

    Never trust user input, never trust validated user input, never trust what the program *thinks* a variable has, never use variables without a default declaration, always limit your variable input data to sane values, error check everything and then do it again to make sure, the list goes on and on and on. Living by these fundamentals, a programmer can take any language and create good applications. VB is notorious for being inefficient and unstable but I know several developers who make some seriously sick progs with it.
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  5. #15
    Senior Member
    Join Date
    Mar 2003
    Posts
    452
    Vorlin, very well spoken.



    --PuRe
    Like this post? Visit PuRe\'s Information Technology Community. We\'ve also got some kick ass Technology Forums. Shop for books and dvds on LiveWebShop.com

  6. #16
    Senior Member
    Join Date
    Jan 2002
    Posts
    1,207
    Fair comments, Pure, that these are not PHP specific problems.

    To be quite honest my main gripe with PHP these days is that the authors don't seem to have a clue what character encodings *are*. They think they do, occasionally, but they don't really. Therefore I cannot recommend PHP for applications which need to be localised into non-western languages, as it really doesn't have any easy way of supporting Unicode properly.

    I would not expect PHP releases to be without bugs. All software has bugs. But I sort of expected 4.3.10 (which is "stable", after all) not to crash as soon as it took one look at my application

    Slarty

  7. #17
    Senior Member
    Join Date
    Nov 2001
    Posts
    1,255
    I'm not sure how employing utf8_encode() is difficult, so perhaps you could elaborate on that?
    Chris Shepherd
    The Nelson-Shepherd cutoff: The point at which you realise someone is an idiot while trying to help them.
    \"Well as far as the spelling, I speak fluently both your native languages. Do you even can try spell mine ?\" -- Failed Insult
    Is your whole family retarded, or did they just catch it from you?

  8. #18
    PHP/PostgreSQL guy
    Join Date
    Dec 2001
    Posts
    1,164
    Agreed, slarty, but how is that any different than any program's use of unknown or non-standardized methods (read: IE's proprietary html "standards" versus W3C's standards...as an example)?

    I also agree that it's a lot harder to write localized programs that use non-western languages and character encodings. However, I wouldn't put the failing with php so much as I would the developers. In line of your program failing, is there a definitive reason as to it's crash? What error's given? I really am interested as I've never had php really "crash" on me.
    We the willing, led by the unknowing, have been doing the impossible for the ungrateful. We have done so much with so little for so long that we are now qualified to do just about anything with almost nothing.

  9. #19
    http://www.php.net/ChangeLog-4.php#4.3.10
    nothing in there related to anything in the zend engine so language constructs wouldnt be effected so im going to go with install specific

    http://bugs.php.net/search.php?searc...ail=&bug_age=0

    only shows up 10 bugs and there is only 1 crash in what could be considered core php and htats with overloading of objects under specific conditions

  10. #20
    Priapistic Monk KorpDeath's Avatar
    Join Date
    Dec 2001
    Posts
    2,628
    Originally posted here by PuReExcTacy
    PHP is the bomb, once you learn it. What CRM are you updating? I think out of 4 different programming languages I've messed around with, PHP is the easiest to learn.


    --PuRe
    A custom built job that doesn't always work the way it should, but to make up for that shortcoming the layout is bad and it runs slowly.

    Mankind have a great aversion to intellectual labor; but even supposing knowledge to be easily attainable, more people would be content to be ignorant than would take even a little trouble to acquire it.
    - Samuel Johnson

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides