"I'm playing audio file in my web application. If i inspect in the network i can able to get the exact file path of audio. Getting actual file path of audio leads to security problem. How to prevent this.
You can't.
You can make this process difficult for the user but if your app in the browser can get any data from server then it can be done without your app too.
You cannot prevent the file path from appearing - but there are ways to prevent it from being used outside the application - or at least being used easily outside the application.
The steps are pretty much the same for any file (Blob) so it would be the same for an audio or video file.
You can prevent it by downloading the file with XHR and converting it to a blob URL - which is what Youtube and Netflix do for video - that way you have full control over the authentication and download process (make sure you download and merge each chunk with a range request to create a full video while streaming the information).
for example: for youtube this is a video URL - it is also revoked after a while so you probably can't open this file with your browser.
This URL is not protected - but there are protected video files on youtube for their premium services which will expect certain headers and cookies to be present.
In order to make this fully protected, you would have to generate a onetime token for each chunk.
https://r6---sn-4g5ednll.googlevideo.com/videoplayback?expire=1563544755&ei=U3gxXZKKFoKZgQeOuYuoBA&ip=62.41.73.80&id=hHW1oY26kxQ.348&itag=140&source=yt_live_broadcast&requiressl=yes&mm=44%2C26&mn=sn-4g5ednll%2Csn-5hne6nsz&ms=lva%2Conr&mv=u&mvi=5&pl=24&live=1&hang=1&noclen=1&mime=audio%2Fmp4&gir=yes&compress=yes&mt=1563522739&fvip=4&keepalive=yes&c=WEB&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Clive%2Chang%2Cnoclen%2Cmime%2Cgir%2Ccompress&sig=ALgxI2wwRQIhANT3eXWZbPN0bFz5j7Zs56veNXpvNuXcvt0yOzwlNx-zAiB4ZjcCA7GTn6k16AiwQcOq2XaUkA3SWFuIdskws8MqBQ%3D%3D&lsparams=mm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl&lsig=AHylml4wRgIhAJ3FqpB1r_T_ErODyHxwcWZZdhxeVJ1yTdovfn0BPBmuAiEA5KbeCcZXe8C7l6W5IjmXWXwN1VXvgwiP7Jn2tWdReoc%3D&alr=yes&cpn=rp9-DtQeCOUxaQZ9&cver=2.20190718&sq=1134933&rn=10&rbuf=15966
Is transformed at runtime to this, and this URL is only local to the user session on the website and cannot be used to download manually unless they inject a script to the website.
blob:https://www.youtube.com/f49abcd9-d431-42f0-8e04-4e156a78a8cc
Now you need to make sure the video is only accessible by authenticating the user the normal way (HTTP only cookies - so users can't get it easily) + CSRF + CORS
CORS - only accept requests with access-control-allow-origin: https://www.youtube.com
JWT - only accept validated users (cookies)
CSRF - token to prevent cross-site forgery (i.e users can't access it without going through the website) - they get invalidated after each user session.
SSL - It is always a good idea to have SSL to prevent easy interception
This is more difficult than I make it sound, and smart hackers can still download the file with extra steps (there are downloaders for Youtube/Udemy/Netflix etc...) - but for the most part, it will prevent most users from easily downloading it.
** In case this isn't clear - there is no solution that involves only the client - the fix must come from the server-side to prevent access to the file.
Related
Helloo, i have a theoratical question, thats why I don't have code snippets, but maybe someone knows an answer.
I program a website that offers videotrainings, but they cost. If the user knows the path to the videos on the server, can I prevent them from editint the html in browser and insert a video tag linked to the video, they should pay for?
If the user knows the path to the videos on the server
If you're trying to be security-conscious, an unauthorized user should not know the path to a video they don't have the credentials to see.
Only send a video link to a user after verifying (on the server) that their account has bought it, and only serve a video to a browser if the browser has supplied the server with the required credentials to see the video. If something requests a video link without the right cookies (or without the right JWT, or however you're authorizing things), reject the request.
Why not rely on a library? Passport is 18K star project, and does the job with Node and Express on your server. They have tons of precofigured strategies (500 and more). This can be done with a simple fetch API, while the rest of your site is served with Apache
We have a Javascript file that we have developed for our clients to use. The Javascript snippet takes a screenshot of the website it is run on and then sends it back to our server via jQuery.post()
The nature of our industry means that we have to ensure there is no way that the file can be tampered with by the client.
So the challenge is that we need to make sure that the screenshot was generated by the javascript file hosted on our server, and not one that's been copied or potentially tampered with in any way.
I know that I can get the script location using:
var scripts = document.getElementsByTagName("script"),
src = scripts[scripts.length-1].src;
But this won't help if a client tampers with that part of the SRC.
What methods can I employ to make sure that:
1) The post was made from the javascript file hosted on our server
2) The javascript was not tampered with in any way.
Short answer:
You can't.
You can't.
Both stem from the fact that once you hand over something to the client side, it's out of your hands. Nothing will prevent the user from putting a proxy between you and their machine, a process that intercepts content or an extension that tampers content, headers, cookies, requests, responses etc.
You could, however, harden your app by preventing XSS (prevent injection of scripts via user input), using SSL (prevent tampering of the connection), applying CSP (only allow certain content on the page), add CSRF tokens (ensure the form is authorized by the server) and other practices to make it harder for tampered content to get through.
But again, this won't prevent a determined hacker to find an opening.
The scenario:
A user posts a link to a website
A little AngularJS service fetches a preview, including an image
This information (including the remote URL of the image) is copied to a hidden form and sent to the server when the user clicks submit.
Now I have to download the image to my server for the preview. Otherwise I would be hotlinking them which isn't good and could also cause problems later.
Because of the cross-origin policy I guess this can only be done server side.
My idea so far is to create a little API where I pass in the URL to the image and the server checks if a local copy exists and if not downloads one on the fly
http://example.com/staticapi/v1/get?img_url=ENCODED-IMG-URL
What I don't like about this idea is that a malicious user could just bombard this system with URLs.
An alternative would be to save the remote URL temporarily and let a background job download any remote images that haven't been processed yet.
How would you approach this?
I really don't understand why do we need to create channel.html file, as mentioned by FB docs. I also want to understand how it is used. In my logs I don't see this file being ever requested.
The channel file is to provide a way to do cross domain communication between FB's servers and your own. The reason for this is their tight control over access tokens. You must authenticate a redirect url and app id to retrieve this access token. In order for them to pass you the token, they hit your URL with the access token in the hash. With the Channel URL, they get to pass this token to themselves (their JavaScript running on your domain).
This channel file can then communicate the access token to your active page.
For them to keep all of these things available to only their domain, they need something that works in every browser. Currently, that is a hack of creating popups that are not accessible by javascript running on your server.
Hope this helps.
https://developers.facebook.com/docs/reference/javascript/FB.init/
From the doc:
This is an option that can help address three specific known issues. First, when auto playing audio/video is involved, the user may hear two streams of audio because the page has been loaded a second time in the background for cross domain communication. Second, if you have frame busting code, then you would see a blank page. Third, this will prevent inclusion of extra hits in your server-side logs. In these scenarios, you may provide the optional channelUrl parameter:
Using javascript one cannot convert an image (hosted on a different domain than the one the javascript comes from) into a canvas.
What's the security risk with that? It can't just be to avoid phishing, right?
Same origin policy stops any remote data from being accessible by a different domain. One of the main attacks this stops is being able to circumvent a user's login by waiting for them to be logged into another site, and then piggy-back your request on their authenticated session.
Whether the data loaded is an HTML snippet, an image file or anything else, it's blocked so you can't take advantage in any way (for example, by inspecting the pixel data of an image retrieved this way)
There is one tricky attack vector connected with external images: someone can post image which will be loaded from the external resource, which they control. After some time this url can be changed to return the request for the basic http authentication. So the other users will see windows requesting their login and password. Some users, especially non-experienced ones can enter the credentials of the attacking resources which will be sent to the attacker. So be careful with external resources.