Hello,
On 9/10/05, Lincoln Yeoh <lyeoh_at_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
Received on Sep 13 2005
Intro
