Tickets :: Comment on [#5892] Linked attachment feature vulnerability

* Your Email Address
* Spam protection	Enter the letters below: . ..__ . .. ..__ \|_/ [ __\|\ \|\ /[ __ \| \[_./\| \\| \/ [_./
Comment	>>> 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.
Attachment
Watch this ticket