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

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

Saved Queries