Based on a report by @Adotchar:
When you're at a page like https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=10891259 (random junk ticket for this example) and right click the frame -> this frame -> show only this frame you're taken to a URL like https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketAttachment;Subaction=HTMLView;ArticleID=12964712;FileID=2;OTRSAgentInterface=$REDACTED
Note the $REDACTED. That was my actual OTRSAgentInterface cookie, and copying that URL and sending it to anyone else would've logged them straight in as me to OTRS (it is the session cookie it seems). It's not obvious at all that the URL is a private one to the individual user that generated it and cannot be safely shared with anyone, even other agents.
Note there are likely other parts of OTRS doing such things with these session cookies - this was originally reported by @Adotchar (aka Vermont) who received a link from @Guilhermebm (aka Tks4Fish) containing their OTRSAgentInterface cookie (the link was apparently like https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=10717957&OTRSAgentInterface=redacted), and found themselves logged in with access to Tks4Fish's queues etc. Grepping for SessionName through the OTRS source shows several other potential places to look into.
Based on a report by @Adotchar:
After being logged out due to inactivity, I logged back in to see if there was an update, and went to sent the ticket to @Adotchar so he could check something. In no moment I purposefully added or tried to find the cookie, and was very surprised when he mentioned that it had logged him in as me. I am currently waiting with another ticket open in another tab to see if when I log out this will happen again, and will report here as soon as I find it out. Thanks @Krenair for bringing this here.
I just reproduced it. This is related to a sandboxed <iframe> that is embedded in the page to showcase the content of the email in a safe way. That being said, leaking session info in the url is indeed bad practice, due to all the copy pasting that can happen. In fact, just adding a valid OTRSAgentInterface to any OTRS url seems to be enough to allow assuming the OTRS identity of a user. On the plus side, those aren't guessable at least. The fun part is that
- We have Core::Session:: SessionUseCookie as true (the default)
- indeed the request does have the HTTP cookie correctly set in the iframe HTTP request, so adding the session to the URL seems not required.
- It is not always reproducible. There are tickets like https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=11076119 for which the iframe is not populated. At first, it seems related to attachments, but the little attachment icon is not a valid indicator as the behavior seems to also apply to emails with Content-Type: multipart/alternative as well.
This should be taken upstream. It seems to me as a forgotten if clause somewhere.
Fix by upstream in https://github.com/OTRS/otrs/commit/7ab33e51a4db9f712e979040f644d0d0c39ff0af for 5.x (which we run). Has also been fixed in our package for OTRS in https://gerrit.wikimedia.org/r/#/c/operations/software/otrs/+/514230
The patch to the above has been released in OTRS 6.0.20, OTRSBusiness 6.0.21 and OTRS 5.0.37. We don't have to update yet due to our setup being already patched, although we eventually will anyway