Re: A Study In Scarlet - Exploiting Common Vulnerabilities in PHP Applications

From: Chris Adams (chrisat_private)
Date: Mon Jul 02 2001 - 15:36:06 PDT

  • Next message: Toby DiPasquale: "Re: Solaris mailtool exploit"

    on 2001-07-02 07:37, Shaun Clowes at shaunat_private wrote:
    
    > SecureReality is pleased to announce the release of our new paper entitled
    > 'A Study In Scarlet - Exploiting Common Vulnerabilities in PHP
    
    You listed many common mistakes, which is good, but I think your conclusion
    ("I contend that it is very hard to write a secure PHP application (in the
    default configuration of PHP), even if you try.") is somewhat off-target. It
    really should be something like "PHP does not prevent bad programmers from
    writing insecure code", particulary if you consider "even if you try" to
    imply more than the most cursory effort.
     
    For example, consider how many of these problems disappear if you correct
    three common mistakes:
        - failure to place private files outside of the webroot
        - failure to check user input
        - failure to structure a program to prevent people from calling code in
    creative ways[1]
    
    We've all seen these before.
    
    It's really quite easy to write a  secure application in PHP - assuming you
    have the necessary security literacy, which is the real issue. PHP is no
    more vulnerable to these problems than any other language - problems like
    these have been reported in everything from ASP to Zope - and in fact makes
    it easier to protect against them than many environments[2]. It's also no
    secret that much of the PHP code available in various opensource projects is
    not particularly well-written.
    
    Since all of these problems are quite easy to avoid, what we really need is
    to improve the security literacy of the average programmer. Without at least
    basic security awareness, the odds that a programmer won't remember to do
    something trivial like declaring critical variables but will handle the less
    obvious challenges correctly approach zero.
    
    Chris
    
    [1] e.g. PHP provides include_once() and require_once() for this purpose -
    if bar.php depends variables which are defined in foo.php, it should have a
    require_once("foo.php") at the top. Similarly, rather than using the
    something like include("$configPath/file"), you should either set
    include_path or use constants, which can't be set by attackers.
    
    [2] e.g. magic_quotes_gpc helps prevent an entire class of attacks and there
    are a number of validation functions which are quite easy to use, hopefully
    enough so that they will actually be used.
    



    This archive was generated by hypermail 2b30 : Tue Jul 03 2001 - 11:04:57 PDT