Re: The Dangers of Allowing Users to Post Images

From: Marc Slemko (marcsat_private)
Date: Fri Jun 15 2001 - 11:19:34 PDT

  • Next message: Ryan Kennedy: "Re: The Dangers of Allowing Users to Post Images"

    (replying to two messages at once here)
    
    On Thu, 14 Jun 2001, Ben Gollmer wrote:
    
    > This is not a big deal if you use some validation on images (in PHP at 
    > least).
    > 
    > Try the function getImageSize(); it will return an array containing the 
    > size of the image, as well as the format. If the file specified is not a 
    > GIF, JPEG, PNG, or SWF, getImageSize() returns null.
    
    Simply verifying it once before you accept the post is not sufficient.
    It is easy to point to something that is a valid image at the time of
    the post, but then later change that to be a redirect to a 
    compromising URL.
    
    And verifying it every time or uploading the image to be stored on the
    server can be quite slow or resource intensive, respectively.
    
    On Thu, 14 Jun 2001, Richard M. Smith wrote:
    
    > This is a *very* interesting finding.  It seems
    > kind of obvious too.  I wonder why no one seems
    > to have run across it before.  
    
    People have.  It just isn't something the world in general cares much
    about, like most other security vulnerabilities that aren't presented in
    the way of a particular, high profile, example.  A lot of these issues are
    fairly closely related to cross site scripting related issues that are
    still rampant on many sites.
    
    > This same weakness can be exploited from an
    > HTML email message also.  The bottom line is that
    > a privileged operation should always require
    > an HTTP POST and never allow a GET.  Hmm, I wonder how many
    > Web sites break this rule?
    > 
    > At least in Outlook 2002, cookies are disabled
    > in HTML email messages by default.  With other
    > email readers, cookies are likely turned on 
    > by default.
    > 
    > Interesting how cookies continue to bite us in the butt!  
    > In this situation, it is third-party cookies
    > that are doing the biting.
    
    It isn't cookies that are the problem in particular.  The same
    issues come up regardless of what "automatic long-lived login" (or
    even session logins in the case of a message board where the viewing
    of HTML that results in the browser performing an action with
    unexpected results) authentication scheme is being used.  This can
    be an issue with cookies.  This can be an issue with HTTP basic
    auth, digest auth, NTLM auth, and even SSL client certificates.
    All provided they are setup to automatically send the authentication
    to the server without prompting the user, or that the user accepts
    any dialog box because "that is what they normally do".
    
    Actually, using SSL client certificates for "strong" authentication,
    given weak UI implementations in today's clients, really scares
    me.  Not because the authentication isn't cryptographically strong,
    but simply because it is too transparent to the user.
    



    This archive was generated by hypermail 2b30 : Sat Jun 16 2001 - 10:05:21 PDT