XSS injection on Jitsi-Meet?


Our security department detected an XSS injection vulnerability on Jitsi-Meet when the client sends post request to /http-bind

  • original request : the client sends its user-agent in the post request as below ( in the red frame)

  • modified request : we replace user-agent content with JS code as below

  • server response after modifying user-agent : we can see that server sends back the user-agent in the response body with an unencoded content

However, the browser doesn’t seem to be affected by this unencoded response, but generally speaking it’s still considered as a XSS injection vulnerability.

I don’t know if this was fixed on the latest stable version of jitsi-meet but this issue was found with the following versions of prosody and jicofo :

  • jicofo_1.0-405-1_amd64
  • Prosody trunk nightly build 747

Thanks for the warning.

I’m also curious if this has been fixed in latest unstable. Anyone know?

Nope, nobody had worked on it. The values got injected in xmpp xml messages and I don’t think this brings any risk.

any tips on how to fix this ?
I could dig a little bit to patch it

Hi Hamza,

If you want to try to fix this, you should look at prosody code (and https://prosody.im/bugs/#security_issues) because it can’t be fix at client side.

But first we should be sure that we can inject malicious code that way into jitsi-meet conference.
In you example you try to inject HTML code in User Agent, but the response has a text/xml mime type from the web server, so it’s seen has an XML file by the browser and not HTML.

Could you ask your security team to try to inject code to the browser XML parser to see if this is really a security issue ?

I will add it to my to-do list, thanks.

You’ve got a point :+1:

It will be complicated to ask them to do that again because It was actually a security audit including pen test.
In general, everything is fine with Jitsi-Meet security. E̶x̶c̶e̶p̶t̶ ̶t̶h̶i̶s̶ ̶i̶s̶s̶u̶e̶,̶ ̶i̶t̶ ̶w̶a̶s̶ ̶n̶o̶t̶ ̶p̶o̶s̶s̶i̶b̶l̶e̶ ̶t̶o̶ ̶i̶n̶j̶e̶c̶t̶ ̶c̶o̶d̶e̶ ̶a̶n̶y̶w̶h̶e̶r̶e̶ ̶o̶n̶ ̶t̶h̶e̶ ̶c̶l̶i̶e̶n̶t̶ ̶s̶i̶d̶e̶
EDIT : There is actually an XSS vulnerability. See post : [meet.jit.si] Stored XSS on meet.jit.si chat

As Damencho mentioned, this injected code will never get executed. I think we should either escape the string or remove the code, just to make audit tools happy (and make it less likely that future changes create a problem). I actually don’t see this used anywhere in either jicofo/jitsi or jitsi-meet/lib-jitsi-meet. Is anyone aware of the reason that it exists?


@Boris_Grozev yeah, I don’t see it used anywhere, let push the stable and then remove it from the client. Maybe @Pawel_Domas can say, is the user-agent in presence useful for anything on the jicofo side?

The user-agent I think was at some point intended to use for feature evaluation (FF simulcast if I remember correctly). Then we switched over to XMPP feature discovery, but maybe it was left in lib-jitsi-meet by mistake or maybe in hope it might be useful for something.

Fixed with https://github.com/jitsi/lib-jitsi-meet/pull/829

1 Like

Great ! Thanks.
Did you also fix this XSS vulnerability that was found by @k1tten ? [meet.jit.si] Stored XSS on meet.jit.si chat

Yes, that was also fixed.

What a great team :heart_eyes:
Thanks for the quick feedback.

1 Like

Not yet pushed ro stable or meet.jit.si, but this will happen soon.
Latest unstable has both fixes.

1 Like