[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         | joao_mauricio at clix.pt
 Summary            | Linked attachment feature vulnerability
 Queue              | IMP
 Version            | HEAD
 Type               | Bug
 State              | Feedback
 Priority           | 2. Medium
 Owners             | 
-----------------------------------------------------------------------


joao_mauricio at clix.pt (2007-11-20 14:24) wrote:

> As I said earlier, people can already disable this with a configuration
option.

I guess that doesn't count as an argument, cause if you are suggesting
that as a good option, then, for the system's security, it shouldn't be
implemented in the first place.


> I have an alternate thought here than the secret id craziness, and 
> having to determine users by id and email address, which seems really 
> unworkable if you think about forwarding, aliases, and a bunch of 
> other stuff. My head spins.
>
> 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.