Page MenuHomePhabricator

OTRS exposes session cookie in URLs
Closed, ResolvedPublic


Based on a report by @Adotchar:
When you're at a page like;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;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;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.

Event Timeline

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.

akosiaris triaged this task as Medium priority.May 28 2019, 10:48 AM

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

  1. We have Core::Session:: SessionUseCookie as true (the default)
  2. 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.
  3. It is not always reproducible. There are tickets like;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.

Hidden and marked as security by upstream.

akosiaris changed the visibility from "Custom Policy" to "Public (No Login Required)".
Restricted Application added a subscriber: Krd. · View Herald TranscriptJun 4 2019, 8:04 AM

Patch has been applied to our own packages and has been deployed and tested. Marking this as resolved, thanks!

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