1
Vote

Security Issue: Video content should not be downloadable.

description

The download url that is used within the object div of the Video Content Section to load the media object can be used (copied and pasted in the browser's address bar) and is also picked up as an indexable url via bots that do not respect robot.txt files.
 
What would the most suitable/safest option be to ensure nobody can download a file with out permission and that it is not findable by rude bots?

comments

mkamoski wrote Jan 13, 2010 at 12:49 PM

One can do the following.
Write and inject the object tag dynamically, programmatically.
Set IIS to have the DotNet process handle video extensions.
Use SSL.
Etc.
HTH.
-- Mark Kamoski

SpiderMaster wrote Jan 14, 2010 at 2:38 PM

Inject as in using the code behind to inject the div programmatically such as document.write(<object and so on? But the url is still available in the source for those who look for it! if thats the case then the problem still exists.
SSL is being used for Secure pages how ever it still needs to be accessible on a non secure connection. It is still downloadable also.
DotNet is handling the download using an assigned handler. Download.ashx and parses if the user is allowed to access the file witch parses as true because we need the video to be downloadable for viewing in the silverlight player.

So thats where the problem is. How can i verify that a video is being called upon from the silverlight player so that I can set the handler to by default not allow anything else to be downloaded unless it is certain the silverlight player is hosting the video.

mkamoski wrote Jan 14, 2010 at 5:50 PM

Spi --
Inject as in using the code behind to inject the div programmatically such as document.write(<object and so on? But the url is still available in the source for those who look for it! if thats the case then the problem still exists.
Yes, I know-- that is why one needs a combination of both SSL and writing the tag programmatically, IMHO.
how ever it still needs to be accessible on a non secure connection
That being the case, there will always be a way to steal the video-- providing public access (non-SSL) means, intrinsically, that it is unsecure.

In the same way image file copy-protection and access-protection is not simply not possible unless the image is protected by SSL or similar.

I wish that I had better news.

Short of steaming the bits dynamically into some generic container where there is no actual "video file" exposed to the out-facing system, it is not really possible.

That said, all that is MHO, driven by my research on such matters, and I do hope to be proven wrong.

:-)

HTH.

Thank you.

-- Mark Kamoski

Sign in to add a comment or to set email notifications