New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple Cross-Site Scripting (XSS) #139
Comments
|
BTW, the file upload function (share a file) is also susceptible. Any user can upload a file with a XSS payload in the filename. For example As the filename is reflected at multiple locations in the web application (e.g. in the chat screen or upload popup), this again can XSS other meeting participants. |
|
Hello @l4rm4nd, Thanks so much for reporting this to me, it should be
Thank you so much, I'm very happy you like it! Join with us on Discord and Have a good weekend. |
|
Hi @miroslavpejic85, many thanks for the fast reply and fix. Your fix works as intended on the client side. Malicious names or filenames are not transfered to other participants but blocked before sending. However, this validation only happens on the client side via JS. An attacker can easily intercept a valid name modification or file transfer via websockets (that is not blocked before sending) and just modify the request directly. On the participant's side, no validation or sanitization will take place and the XSS payloads will trigger again. An example websocket request for file transfer would look like this: So your fix does not mitigate XSS, unfortunately. Here an example for name changing via websockets: |
|
It's a general problem with output sanitization, since input validation will always be easily bypassed due to JS and websockets. For example, the raising hand feature is also susceptible. An attacker can easily modify the websocket request and again modify the peer_name. XSS on all participants, as the peer_name is reflected. |
|
Same for sharing a video. Peer name can again be weaponized for XSS. The opened video player on the participant's side will reflect which peer opened the video. BTW, this also allows for impersonification. So an attacker could easily fake the |
|
So sorry to spam the project with security issues but I really love this project. It is so much better than other web meeting platforms and provides a lot of cool and thoughtful features. If we get things like these sorted, it's just brilliant <3! |
|
Hi @l4rm4nd, Don't worry, I'm very glad you care about security! I added the Can you confirm please? Thank you!
Thank you for your nice feedback! :)
Sure, Thanks to your cooperation everything will be improved - fixed ;) |
|
hi @miroslavpejic85, good job using the I've even tried some older XSS payloads to especially bypass js-xss from Portswigger XSS Cheatsheet. No luck. The only thing that is now still possible is HTML injection. But honestly, the impact for this is kinda low. And some self-XSS popups that are not exploitable for other participants. Will only trigger a JS popup for the attacker himself. Should be fixed too but there is no security impact/risk leaving it as is. For example a name change to |
|
Hi @l4rm4nd, Nice to hear your again.
Thank you, yes, seems very good!
I agree with you.
For the name change, I found a way to disable the JS Popup and clean up :) Thanks again so much for reporting this issue to me and for helping with debugging, much appreciated! |
|
Hi @miroslavpejic85 , very nice. The self XSS for the name change function is now fixed. I've found a remaining self XSS when joining a meeting. You may want to fix this too as it is the second input field presented to a user (after optionally choosing a room name). You may want to restrict and filter the room name people can choose. A room name with |
|
Hi @miroslavpejic85 , sorry, I've found another XSS. This time it is a bit more hidden. A user can choose an XSS payload as name when joining a web meeting. The XSS name will trigger a self XSS popup for the attacker himself. No impact for other participants. However, the Proof of Concept:
So the reflection of peer_name for private messages must be validated and sanitized too. |
|
Hi @l4rm4nd, |
Looks good! Malicious HTML/JS is escaped properly. Participants can also not choose malicious payloads anymore during meeting join: Also within meeting a peer name cannot be changed to malicious JS/HTML on the frontend: Great job and many thanks for your fast replies and implemented fixes! |
|
Good! It's a pleasure, Many thanks to you! |



















Describe the bug
The mirotalk web application is susceptible to XSS.
If two participants joined a web meeting, one participant can change their name, which is then reflected for all other meeting participants. Since no input validation takes place; or output filtering to sanitize maliciously choosen names, the payload of an attacker is executed in the browser of other victims.
This can introduce various problems and attack vectors, such as:
To Reproduce
Steps to reproduce the behavior:
<img src="x" onerror=alert(document.domain)>Expected behavior
A meeting participant's name should always be sanitized before being displayed or embedded into the website's content.
Screenshots
Desktop - Mobile
Please complete the following information:
Additional context
Recommendation
Other from that, many thanks for this projects. Really, really cool!
The text was updated successfully, but these errors were encountered: