3 ms·

Doesn't strike me as very secure, since everything here happens through the url and anyone can just go in and grab the required values to spoof a transcode requ

Doesn't strike me as very secure, since everything here happens through the url and anyone can just go in and grab the required values to spoof a transcode request. It's mostly mitigated by the necessity of file upload access, but even with that this can still be taken advantage of, especially if there are rewrite rules on the file server that might expose the same file through different urls (also if this service follows 3xx redirects that's even more vectors of attack). In case resolution choice is added as an option, what's to keep any random Joe from requesting videos with various resolutions (or very huge resolutions) and racking up the bill for me?

amrit_b 13y ago
Thanks for your inputs! And yes you are right and even I am worried with those cases. Anyways its a 3 days side project and I had no idea that it will gain this much hype! I am alone here and 5th position on Hackernews is kinda a new thing for me! Currently I am worried about if my server goes down!
- shuzchen 13y ago
  One thing you could do is involve HMACs. Basically, give the user a key that they use to sign the request (basically sign a hash containing the url, user id, requested options). You can then use the HMAC to verify that the user did request a video be transcoded, and website visitors cannot fiddle with the request parameters without invalidating the HMAC. The problem is that this has to be done server side because the key needs to be secret (thus, this can't happen in javascript in the client), which breaks the whole idea you're selling (API-less transcoding). You could also provide your clients with urls by having them submit the request on your site (obviously, behind a login). The user would then use that url in the src of their video tag. Again, this method goes against your selling point.
  - amrit_b 13y ago
    yeah right. Don't want to make it that complex.
twodimman 13y ago
That could be easily avoided setting up an htaccess password and let the service know about it I guess.
- amrit_b 13y ago
  wow! thats a great idea. thanks!
- shuzchen 13y ago
  I'm not sure how that helps any. The issue isn't access to the raw movie file source, but access to the url, userid and eventual customization variables necessary to start a transcode job. All of this is readily available to any website visitor on a page that has a video utilizing this transcoding service.
amrit_b 13y ago
Hey shuzchen, I am still wondering how can people upload file to someone else 's server? When you call the transcode.io URL, you don't provide the host address. The host address is pulled from the user's account. And the account is linked with payment and other stuff. And requesting same video with different resolutions doesn't work like that. Transcoding only happens for the first time (and you have to pre-select the output resolution while creating your account)
- shuzchen 13y ago
  If that's the case with the resolution setting then my concern there isn't as major, although users might still be at risk if their webservers are configured a certain way. I'm not concerned about users uploading files to someone else's server, but sometimes servers are configured to rewrite certain urls, or to do redirects, and attackers might be able to take advantage of that to rack up some user's bill. For instance, some cache-busting schemes rewrite /d/_somehash_/file or /d/file._somehash_ to the same /d/file and your service has no idea they're actually the same file. In this case, some attacker can just make up random hashes to make false transcode jobs, even though they all return the same video file. Does your service treat /d/file and /d/file?v=1 as separate files? If so that can also be used as an attack vector as someone can add whatever parameters they want to the url, and most webservers silently ignore those. You can close this by ignoring those parameters, but then you exclude sites that serve files through some script (like /cgi/get-file?f=somefile) Does your service whitelist file extensions? Or stream in file headers first to decide whether any file is a valid movie, otherwise stopping the download? Otherwise, any site that hosts other large files (say, linux ISOs) can force you to download really large files and waste bandwidth and resources. With that in mind, I think if you also make it so your clients must also provide a subdirectory (for example, I could set it so only files within /static/videos/ are valid, as that's where I've decided to put my videos) then most of these issues will be taken care of. Your clients would then just need to make sure they don't have rewrite enabled for that subsection of their site, and make sure other large assets live outside that subdirectory.
  - amrit_b 13y ago
    These issues have been bugging me since long. Thanks for writing the solutions! I am not sure whether the server treats /d/file and /d/file?v=1 as different files or same. Need to check that. Regarding the mime type, how can I test it without downloading it..? It downloads and then match. If irrelevant then discards. Need to figure out a way to check mime before downloading. Your /satic/videos/ idea is excellent. This solves a lot of issues. I will take that path along with name, email & host. And the account will go to "readOnly" state after every update of these critical account details. We need to test manually the path and host before removing the "readOnly" mode. (any other solution?) Thanks again for delving this much into this. Shoot me an email if you wish to discuss more on this :)

amrit_b 13y ago

Thanks for your inputs! And yes you are right and even I am worried with those cases. Anyways its a 3 days side project and I had no idea that it will gain this much hype! I am alone here and 5th position on Hackernews is kinda a new thing for me! Currently I am worried about if my server goes down!

shuzchen 13y ago
One thing you could do is involve HMACs. Basically, give the user a key that they use to sign the request (basically sign a hash containing the url, user id, requested options). You can then use the HMAC to verify that the user did request a video be transcoded, and website visitors cannot fiddle with the request parameters without invalidating the HMAC. The problem is that this has to be done server side because the key needs to be secret (thus, this can't happen in javascript in the client), which breaks the whole idea you're selling (API-less transcoding). You could also provide your clients with urls by having them submit the request on your site (obviously, behind a login). The user would then use that url in the src of their video tag. Again, this method goes against your selling point.
- amrit_b 13y ago
  yeah right. Don't want to make it that complex.

twodimman 13y ago

That could be easily avoided setting up an htaccess password and let the service know about it I guess.

amrit_b 13y ago
wow! thats a great idea. thanks!
shuzchen 13y ago
I'm not sure how that helps any. The issue isn't access to the raw movie file source, but access to the url, userid and eventual customization variables necessary to start a transcode job. All of this is readily available to any website visitor on a page that has a video utilizing this transcoding service.

amrit_b 13y ago

Hey shuzchen, I am still wondering how can people upload file to someone else 's server? When you call the transcode.io URL, you don't provide the host address. The host address is pulled from the user's account. And the account is linked with payment and other stuff. And requesting same video with different resolutions doesn't work like that. Transcoding only happens for the first time (and you have to pre-select the output resolution while creating your account)

shuzchen 13y ago
If that's the case with the resolution setting then my concern there isn't as major, although users might still be at risk if their webservers are configured a certain way. I'm not concerned about users uploading files to someone else's server, but sometimes servers are configured to rewrite certain urls, or to do redirects, and attackers might be able to take advantage of that to rack up some user's bill. For instance, some cache-busting schemes rewrite /d/_somehash_/file or /d/file._somehash_ to the same /d/file and your service has no idea they're actually the same file. In this case, some attacker can just make up random hashes to make false transcode jobs, even though they all return the same video file. Does your service treat /d/file and /d/file?v=1 as separate files? If so that can also be used as an attack vector as someone can add whatever parameters they want to the url, and most webservers silently ignore those. You can close this by ignoring those parameters, but then you exclude sites that serve files through some script (like /cgi/get-file?f=somefile) Does your service whitelist file extensions? Or stream in file headers first to decide whether any file is a valid movie, otherwise stopping the download? Otherwise, any site that hosts other large files (say, linux ISOs) can force you to download really large files and waste bandwidth and resources. With that in mind, I think if you also make it so your clients must also provide a subdirectory (for example, I could set it so only files within /static/videos/ are valid, as that's where I've decided to put my videos) then most of these issues will be taken care of. Your clients would then just need to make sure they don't have rewrite enabled for that subsection of their site, and make sure other large assets live outside that subdirectory.
- amrit_b 13y ago
  These issues have been bugging me since long. Thanks for writing the solutions! I am not sure whether the server treats /d/file and /d/file?v=1 as different files or same. Need to check that. Regarding the mime type, how can I test it without downloading it..? It downloads and then match. If irrelevant then discards. Need to figure out a way to check mime before downloading. Your /satic/videos/ idea is excellent. This solves a lot of issues. I will take that path along with name, email & host. And the account will go to "readOnly" state after every update of these critical account details. We need to test manually the path and host before removing the "readOnly" mode. (any other solution?) Thanks again for delving this much into this. Shoot me an email if you wish to discuss more on this :)