[Tickets #5892] Re: Linked attachment feature vulnerability

[bugs at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/?id=5892
-----------------------------------------------------------------------
 Ticket             | 5892
 Updated By         | Chuck Hagenbuch <chuck at horde.org>
 Summary            | Linked attachment feature vulnerability
 Queue              | IMP
 Version            | HEAD
 Type               | Bug
 State              | Feedback
 Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


Chuck Hagenbuch <chuck at horde.org> (2007-11-20 14:52) wrote:

>> Isn't the simplest answer here to just add an intermediate page? Make
>> it impossible to download a linked attachment directly - you have to
>> go to the page first, get a token that's valid for a few minutes,
>> make a POST request, etc., then you get the file. That way no jar:
>> link could link directly to a file.
>
> I don't know if that "secret id craziness" is that crazy, cause it's 
> how google does it; but maybe i've expressed my self wrong. If you 
> think that's the right solution, ok, but remember that the "jar:" 
> will operate after the url is resolved, and the file retrieved.

... which is solved by an intermediate page, if not a redirect (I didn't
see an answer to that question), right?

Think about the ids for a minute. Say someone has an email address on
server2 that forwards back to server1. When the attacker sends the message
to the server2 address, it'll have to generate a guest id. Then the victim
will read it when logged in to server1, and all we can do, maybe, is to say
that you can't see this attachment, because we have no record of the email
having been sent to the victim at their server1 account. The whole thing
seems fragile to me.