When a session is created and token has been sent to the front-end as a response, the token URL contains the session ID in plain text. (https://<openvidu_server>/openvidu?sessionId=&reconnect=true).
Sensitive information within URLs may be logged in various locations, including the user’s browser, the web server, and any forward or reverse proxy servers between the two endpoints. URLs may also be displayed on-screen, bookmarked or emailed around by users. They may be disclosed to third parties via the Referer header when any off-site links are followed. Placing session tokens into the URL increases the risk that they will be captured by an attacker.
So is there any way to avoid this security threat ?
The session id by itself does not expose any security risk. You need the token of a session to be able to access, and this token is sent by your backend to your frontend app connecting to OpenVidu. So, without the token you can’t do anything,
If you have a PoC we can execute where you think there is a security thread, let us know.
Hi @cruizba . Thanks for your reply. I have three doubts here:
-
When we say token, is it this entire URL ((https://<openvidu_server>/openvidu?sessionId=session1&reconnect=true). ) which comes from the token API or token is something else ?
-
Lets say from token API, I get this : https://<openvidu_server>/openvidu?sessionId=session1&reconnect=true. Since I receive this in the front-end, could it be possible for the attacker to modify this to https://<openvidu_server>/openvidu?sessionId=session2&reconnect=true and join a different session. Assume that the attacker is the user who wants to join a session he’s not authorized to.
-
In another scenario, lets say if the user stops the flow once the url got from the token API is received as response and shares it to another user. The another user tries to connect to this URL using webrtc and joins the call. Is it possible ?