May 14 2019 - Security Update: Session-based Authentication

Problems with Unreal Media Server

May 14 2019 - Security Update: Session-based Authentication

Postby admin » Tue May 14, 2019 4:25 pm

On May 14 2019 we have updated the Unreal Media Server v13.0 and Session-based authentication documentation and sample code in our SDK.

Unreal Media Server now exposes a new method AddSessionEx in IExternalSessionEX COM interface.
The SDK sample projects were changed to use that method.
If you use AddSessionEx, instead of AddSession, then the Media Server will expect a secure token (Session ID or other user-specific token that you issue for logged-in user) to be passed from players as an HttpOnly cookie, as opposed to being appended to the playback Alias (playback link).
This is true for HTML5 players only: WebRTC and MSE players; all other player types (Unreal UMS protocol, Flash, MMS) still need to pass the secure token appended to the playback Alias.
AddSessionEx provides a parameter to prohibit other player types from playing (only allow WebRTC and MSE players).

This addresses the potential security flaw in Session-based authentication: if a secure token gets stolen on the way from web server to web browser, or if a logged-in user (who can see his secure token in the browser, using view source or debugging tools) passes the token to his friend, then this other person could use that secure token to play restricted media from the Media Server, without logging in to your web site. The Media Server would think that the playback request comes from the original logged-in user. This is possible while the original user is logged-in to the web site (session still exists).
While this scenario is possible when the secure token just gets appended to playback Alias (playback link), this scenario is NOT possible when Media Server expects secure token in HttpOnly cookie, that your web server needs to set for logged-in user. Even if the "other person" gets ahold of secure token, he will not be able to use it in his web browser's HTML5 players to play.

The issue still exists for non-HTML5 players, and here is how to mitigate it:
1. Of course you need to use HTTPS for your web application, so nobody can steal the secure token on the way from web server to web browser.
2. If a user himself passes the secure token to his friend, here is what you can do:
a. Charge for every playback or per viewing time - the original user will be charged for his friend.
b. Set limit of concurrent connections for authenticated user.
admin
Site Admin
 
Posts: 1004
Joined: Fri Aug 21, 2009 10:13 am

Return to Experience and troubleshooting

Who is online

Users browsing this forum: No registered users and 1 guest

cron