Re: "tinyurl" url masking

[Laurian Gridinoc <laurian () gmail com>]

Hello,

On 9/10/05, Lincoln Yeoh <lyeoh () pop jaring my> wrote:
> Background:
> A number of sites allow minimally controlled 3rd parties to post links to
> images which other 3rd parties can view, and the only filtering used is
> some pattern matching to ensure that a url has the "correct" extension.

Wrong approach, URLs are opaque, the application should send a HEAD
request to the URL in order to get a mime type and validate it.
 
> However such filtering has problems if the "image" url actually redirects
> to a url to a target site that does some naughty stuff.

Two cases,

1. mime type mismatch --  if you have an <img src="foo.jpg"> and at
the src URL you get anything but not image/* mime type, the browser
would not render anything, nor redirect you there -- Netscape
Communicator had some issues with this.

2. triggering unwanted actions by URL, as you pointed out:

> http://tinyurl.com/aqxq8/foo.jpg
> Goes to
> http://mail.google.com/mail/?logout&test=/foo.jpg
> Which seems to log one out of google mail :).

Which shows that Gmail (which I use to write this email) is badly
designed, logout should be used via a POST only...

And here let's blame cookies again... if the session would be in the
URL, you won't be able to guess the session id of your target...
 
> Some url shortening pages send a metarefresh page instead, which helps
> prevent them being abused in this way, but of course it means users of such
> services have to wait or make an additional click.
 
And the metarefresh is intended for user-agents that know or expect text/html.
 
The issue is interesting, there are a lot of webapplications that
break the semantics of GET, and a lot of other webapplications allow
displaying images from other domains... what to fix?

I think that it would be easier to fix the issue in the browser, to
have browsers not use cookies over a redirect? (thinking only at
session related scenarios)

Cheers,
-- 
Laurian Gridinoc, www.grapefruit.ro