[Tickets #5892] Re: Linked attachment feature vulnerability
bugs at bugs.horde.org
bugs at bugs.horde.org
Tue Nov 20 23:17:45 UTC 2007
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 15:17) wrote:
> 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 received from the attacker's email with unique_id = 10 received
(not even the attacker knows that id, just the rcpt):
if the rcpt is authenticated on the server's imp system:
if the unique_id corresponds to the logged user: success!
else: fail!
else: success! (cause then, it wont happen any XSS attack)
Maybe that's too complicated, cause maybe i'm not think well about all the
problems that it raises, so, let's get back to the other solution
mentioned...
> ... which is solved by an intermediate page, if not a redirect (I
> didn't see an answer to that question), right?
Well, i have to say that when you adopted my "redirect" suggestion, i
didn't thought that it was a bit modified, cause, my google's previous
example (when i explained my redirection idea) won't work on this
situation, but i think that a solution with an intermediate page, as you
said, it's ok.
More information about the bugs
mailing list