6

I'm trying to figure out how to make an embedded video only readable by a specific player. Here's the context:

I have a website that hosts videos for streaming. All videos are private. My clients would like to be able to generate an embedding code snippet that would allow him to post this video to whichever site he desires. (ultimately this means that the video stream is no longer private but now made public).

Now this is the tricky part. The client does not want these videos to be scannable via their URLs, meaning that if the video url is http://my.domain.com/videoToken, any bots/users/programs hitting that URL will not see the video, however the player needs to load the video from that same URL.

Anyone know what secure options I have for implementing this? There are some DRM solutions out there, are those of any help for this use case?

Thanks in advance.

PS: if this is not possible for whatever reason, what's the next closest thing?

Pomme.Verte
  • 1,782
  • 1
  • 15
  • 32
  • This question is too broad in its current state. A video comprises of a player and an asset. Do you mean protect the asset or protect the player? – Alastair McCormack Jul 10 '16 at 20:35

3 Answers3

2

What if we put something similar to the following on a .htacces file?

<IfModule mod_rewrite.c>
 RewriteEngine on
 RewriteCond %{HTTP_REFERER} ^http://(www\.)?my.domain\.com/.*$ [NC]
 RewriteRule .*\.(mp4|avi)$ http://www.my.domain.com/forbidden.mp4 [R,NC,L]
 # or serve a standard 403 forbidden error page
 # RewriteRule .*\.(mp4|avi)$ - [F,L]
</ifModule>

Maybe that's not the solution, but the idea of use mod_rewrite to control access to video on an HTTP_REFERER basis could be developed.

  • Inspect incoming traffic on your video page and whitelist on some parameters using php. for example: $_SERVER["REMOTE_ADDR"] $_SERVER["REFERER"]. If it is on your whitelist, serve the video otherwise don't. OR have them call the video page with secret URL parameter(s) (eg. "http://my.domain.com?client=john102&viewvid=29091") and read/check that param(s) using php. Note- make sure that these parameters are not in plain text links on originating pages ;-) – Werner Jul 07 '16 at 10:54
2

I can't figure out how to block request by your choice unless you have a blacklist, but you could have a script that adds/changes some parameter, so the url is not complete when a bot scraps a site with embed code.

I've made a example with youtube:

JS

$('#embed').click(function(e){
  e.preventDefault();

  $(this).remove();

  var src = $('iframe').attr('src');

  $('iframe').attr('src', src + 'OAxm_GSM7L4?autoplay=1');

});

HTML

<div id="player">
<div id="embed"></div>
<iframe width="420" height="315" src="https://www.youtube.com/embed/" frameborder="0" allowfullscreen></iframe>
</div>

Demo https://codepen.io/anon/pen/bZAvYZ

1

Just to make things clear, your client seems to want;

  1. To be able to embed their videos on arbitrary web pages and have them load successfully, while
  2. Making it impossible for arbitrary users to load/view those same videos via the URL.

These two requirements are inherently contradictory. Any embedded code/element will have to make a request to your server from the client's browser, so you will be unable to tell if a given request is coming from a user loading an embedded video, or a bot/script/user trying to download the content directly from the URL. The method suggested by @ernestortiz would prevent a casually browsing user and web crawlers from stumbling upon your videos (if you had a white-list of permitted referrers, but that's an entirely different problem), but a non-malicious user will likely never accidentally stumble upon your videos, and a non-malicious bot will respect robots.txt. A malicious user can just fake their referrer header, and a malicious bot could easily be configured to do the same.

The crux of the problem is that, without back-end support from every site where you embed your video, you are going to have to distribute the code needed to access your video with your embedded code, such that any attacker would be able to access it. So an attacker would know exactly how to circumvent any protective measure you develop; you're giving them proof-of-concept code for doing so.

F. Stephen Q
  • 4,208
  • 1
  • 19
  • 42
  • Thanks. I wasn't entirely clear but the premise was that these "arbitrary web pages" would most likely not be accessed by malicious people. Any malicious intent would be done directly from scanning URLs or potentially some middle man attack. URL tokenization would be a lightweight security implementation, I've been trying to figure out if there weren't tougher systems available. I've since found a bit more out in AES encryption for streams and the likes which seem to fit the bill quite well. – Pomme.Verte Jul 05 '16 at 18:26
  • If your attack model trusts users with access to pages with embedded videos, then you can definitely use an AES-encrypted stream with the key distributed in the embedded client (although you'd likely also want to use obfuscated URLs as well). That would effectively frustrate any enumeration-based (i.e. URL scanning or webcrawling) attack, as well as most man-in-the-middle attacks. – F. Stephen Q Jul 05 '16 at 18:46