More PHP Stupidity

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Aug 12, 2009.

  1. Just when you thought it was enough to wean PHP noddies off
    "register_globals", turns out there's another way PHP lets an attacker reach
    into the internals of your program and screw them around.

    <http://blogs.zdnet.com/security/?p=4002>
     
    Lawrence D'Oliveiro, Aug 12, 2009
    #1
    1. Advertising

  2. And another bit of cleverness from the PHP set:
    <http://www.h-online.com/security/jCryption-1-0-released--/news/113969>.

    Don't they realize how pointless this is?
     
    Lawrence D'Oliveiro, Aug 12, 2009
    #2
    1. Advertising

  3. On Aug 12, 12:10 pm, vitw <> wrote:
    > On Wed, 12 Aug 2009 11:33:19 +1200, Lawrence D'Oliveiro wrote:
    > > More PHP Stupidity

    >
    > 'PHP stupidity'?? The second word is redundant!
    >
    > > Just when you thought it was enough to wean PHP noddies off
    > > "register_globals", turns out there's another way PHP lets an attacker
    > > reach into the internals of your program and screw them around.

    >
    > > <http://blogs.zdnet.com/security/?p=4002>

    >
    > Just like Windows - the smartest offering doesn't always end up
    > dominating the market or the industry.
    >
    > PHP is brain pus. Sadly it wins hearts and minds by giving absolute
    > newbies an easy learning curve to becoming slightly productive.
    >
    > If languages were bikes, then PHP is like a squeaky old tricycle, which
    > way too many kids cling to even well into their adulthood, instead of
    > upgrading to 2-wheel bike then motorcycle or car.


    Except, this isn't a PHP vulnerability.
     
    Hamish Campbell, Aug 12, 2009
    #3
  4. On Aug 12, 7:21 pm, vitw <> wrote:
    > If a language makes it much quicker, easier, simpler or more convenient
    > to write vulnerable code than to write secure code, then I'm sorry, it is
    > a vulnerabilty in the language itself, albeit subtle.


    Not really. Some languages presuppose what you are trying to do, which
    might allow for better security, or it might just get in way. On the
    other hand, there is a strong argument that this is a false assurance,
    since developers will usually find a way to code around 'built-in'
    security features of a language.

    There is no such thing as a secure programming language.

    > Programmers almost always work under time pressure. It's very easy to
    > forget that in some places in one's code, the security considerations
    > aren't exactly paranoid.


    If you want to code securely, use a secure *framework* and learn how
    to use it properly.

    By the way, anyone interested in these issues should go along to the
    monthly OWASP meetups.

    http://www.owasp.org/index.php/New_Zealand
     
    Hamish Campbell, Aug 12, 2009
    #4
  5. In message <a6c86477-
    >, Hamish Campbell
    wrote:

    > Except, this isn't a PHP vulnerability.


    NO OTHER language has this "feature", whereby an outside entity can force
    certain data types on the program, regardless of the programmer's wishes,
    simply by encoding input data in a certain way. It's an unwarranted
    intrusion on the internal workings of the program, which is why it's a
    security risk.
     
    Lawrence D'Oliveiro, Aug 13, 2009
    #5
  6. On Aug 13, 11:39 am, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message <a6c86477-
    > >, Hamish Campbell
    > wrote:
    >
    > > Except, this isn't a PHP vulnerability.

    >
    > NO OTHER language has this "feature", whereby an outside entity can force
    > certain data types on the program, regardless of the programmer's wishes,
    > simply by encoding input data in a certain way. It's an unwarranted
    > intrusion on the internal workings of the program, which is why it's a
    > security risk.


    As with all user input, from any language (but especially an untyped
    one), it has to be properly filtered.

    If it has not been properly filtered, it is a fault of the developer,
    not the language.
     
    Hamish Campbell, Aug 13, 2009
    #6
  7. In message <>, Hamish Campbell wrote:

    > On Aug 13, 11:39 am, Lawrence D'Oliveiro <_zealand> wrote:
    >>
    >> In message <>, Hamish
    >> Campbell wrote:
    >>
    >>> Except, this isn't a PHP vulnerability.

    >>
    >> NO OTHER language has this "feature", whereby an outside entity can force
    >> certain data types on the program, regardless of the programmer's wishes,
    >> simply by encoding input data in a certain way. It's an unwarranted
    >> intrusion on the internal workings of the program, which is why it's a
    >> security risk.

    >
    > As with all user input, from any language (but especially an untyped
    > one), it has to be properly filtered.


    In other languages, a string is a string. You feed a string in a URL or form-submission parameter, and the language receives it as a
    string. End of story. It's only PHP where it can magically interpret certain string formats as encodings for something else that is not a
    string.

    > If it has not been properly filtered, it is a fault of the developer,
    > not the language.


    You don't need to "filter" strings in any other language if you're just going to use them as strings. Strings are strings. It's only PHP
    that requires you to check that you really have a string, that it hasn't magically turned into something else.
     
    Lawrence D'Oliveiro, Aug 13, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. raviraj joshi
    Replies:
    0
    Views:
    665
    raviraj joshi
    Jul 4, 2009
  2. OldGringo38

    Re: Yet more stupidity from Japan

    OldGringo38, Mar 23, 2010, in forum: Computer Support
    Replies:
    3
    Views:
    352
    G. Morgan
    Mar 24, 2010
  3. EVS
    Replies:
    0
    Views:
    1,972
  4. infocus
    Replies:
    0
    Views:
    902
    infocus
    Jul 19, 2010
  5. EVS
    Replies:
    0
    Views:
    1,828
Loading...

Share This Page