Re: The Dangers of Allowing Users to Post Images

[Marc Slemko <marcs () znep com>]

(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.