I have stored a video file in BLOB storage. I need to stream this video but, I do not want users to go into developer mode and copy/paste URL on a browser so they can download it.
I have tried many ways to control this but I have failed. I used SAS token with an expiry, but, users are still able to download the content within that expiry period.
My latest approach is to hide the SAS Token enabled video URL behind Azure API Management Service. This will give me a different URL (which is not the BLOB storage URL) which I will expose on the HTML page. Will this approach work ?
NO, we cannot hide the backend information in a Web. You can’t hide anything that your app running on a clients Browser. Instead of that you can secure your backend service.
There are some alternate ways to do that, but we don’t hide anything on a web.
1. Mask URLs in content
The redirect-content-urls policy re-writes (masks) links in the response body so that they point to the equivalent link via the gateway. Use in the outbound section to re-write response body links to make them point to the gateway. Use in the inbound section for an opposite effect.
<redirect-content-urls />
Refer for Mask URLs in content
2. Set backend service
Use the set-backend-service policy to redirect an incoming request to a different backend than the one specified in the API settings for that operation. This policy changes the backend service base URL of the incoming request to the one specified in the policy.
<set-backend-service base-url="base URL of the backend service" />
Or
<set-backend-service backend-id="identifier of the backend entity specifying base URL of the backend service" />
Refer Set backend service
Other wise you can encrypt your video data to secure a backend
To know the possible ways see here
If a client has a valid SAS can access your storage account that was permitted by the SAS. It’s important to protect a SAS from malicious or unintended use. For that use discretion in distributing a SAS, and have a plan in place for revoking a compromised SAS.
Refer: SAS for blob
Related
I am building a web page that will be embedded on a third party website using iframe. No login service is required to initiate the communication so I can't manage any session token.
Therefore, I am planning to validate the origin header of the https request to check if the request comes from the expected source. This external website is not in my control but I can ask them to make some changes to achieve secure communication.
I have two questions:
Is it possible to set or modify "origin" header maliciously in an https request? Or is it always set by browser itself?
Because I am not very sure of the level of security provided by origin header I plan to use HMAC-SHA256 as well. The external site should generate a unique number for each request and sign it with secret key.
So, if I implement the above two things, is there anything else I should be worried about?
Is it possible to use HTTP.get on the client side to retrieve some json data and store it as a string?
I need to get the JSON from this site https://blockchain.info/address/15cNko3ZtmYCba8GoaYsZ6GWFy1VCLgFji?format=json and store it as a string for later parsing.
The above site address for the wallet was chosen at random.
You can perform HTTP.get on the client. As per the documentation it's available Anywhere (Client and Server)
However, the example you've provided isn't on the same domain as your app, and hasn't provided Access-Control-Allow-Origin headers to permit cross-domain requests. So requests from the client will fail.
From Wikipedia:
The same origin policy prevents a document or script loaded from one
origin from getting or setting properties of a document from another
origin. This policy dates all the way back to Netscape Navigator 2.0.
Try typing $.ajax("https://blockchain.info/address/15cNko3ZtmYCba8GoaYsZ6GWFy1VCLgFji?format=json"); in your browser console in your application development tab.
You're likely to receive this error as response :
XMLHttpRequest cannot load https://blockchain.info/address/15cNko3ZtmYCba8GoaYsZ6GWFy1VCLgFji?format=json. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:3000' is therefore not allowed access.
This is a CORS related issue which is a whole topic on itself so I suggest you google this and understand its implications.
Next, if you can control CORS settings on the domain where you're trying to fetch json from, then you need to allow cross origin requests from your web application domain, this is possible when using an amazon S3 bucket, another web application you designed, etc...
If you can't, then I'm afraid you'll have to use a Meteor.method client side to reach your Meteor server where you'll fetch the json with HTTP.get then send it back to the Meteor client.
whenever, i request to server using jQuery-ajax for retrieve data that is shows in firebug so that is unsafe or hackable.
even facebook and google+ hide their json data, but how?
You could use a library like crypto-js to encrypt all data that is sent to and from the server. However, most of the time, that is an overkill when you already use https (since you should make your application hack resistant via server side validation and safety is ensured by the real encryption offered by https).
I have two websites http://www.example.com and https://www.example.com. I am using HTML5 session storage to store user preferences.
A user arrives at http://www.example.com and I load some default settings via ajax.
They browse to a page requiring login and are sent to https://www.example.com/login.html
After they are done logging in they are sent back to http://www.example.com where because they are now logged in I should fetch new settings from the server. The trouble is that http and https are different origins and can't share session storage.
Things I've tried that don't work:
Loading a page http://www.example.com/clearSession.html in an iframe that just runs sessionStorage.removeItem('key') to clear my data, but it seems that this has it's own browsing context so it doesn't work.
Things I've tried that work but I'm not wanting to use:
Using a cookie. This works great because http and https can share cookies but this means all my user settings get sent to the server with every resource request. This is usually about 4k but could be up to 1MB of data. No I can't host my resources on a different domain.
Don't cache the settings and just make the request every time to get the settings. I am doing this on older browsers as they don't support session storage but it slows down the page load and puts extra load on my database.
I can tell you how we have solved this problem, but it doesn't involve local sessionStorage. We use a server-side session to store the user's login data (username, ID, etc.) after they have been to our authentication server and back. Before they are authenticated you could still collect preference data from them by using AJAX to report these preferences back to a web service on the server that can store it in the server's session scope. This would break the RESTful model, however, because it would assume the use of server side sessions. That would depend on your server language and how you have your web services set up.
I think you will always bump into that origin problem because that is a restriction designed into local storage in general.
Switch everything to https, its a standard now.
I want to set up a project page on GitHub, so that it acts as a live site.
The site would require an API sid & token (both just long strings of text) that, in a self-hosted environment, the user would just add to the config file.
If I host this through GitHub project pages, users will supply their sid/token through a form. The page with the form will need to be served over SSL so that the sid/token aren't transferred as cleartext. The problem is that GitHub project pages don't allow SSL.
So, if I can find another secure way to take input through a form aside from using SSL, then I can host this whole thing a hosted service through GitHub project pages.
The project would be open source, so I don't expect any sort of encoding/hashing scheme to work, since the methods would be public.
The sid/token are being used in curl calls to an API which is sent over SSL. Perhaps there's a way to direct the form input directly to that SSL URL instead of having it go through the non-SSL GitHub project page...
Any ideas?
You can just give the action attribute of the form the HTTPS URL of the target script, if that's possible.
You could also use some kind of Challenge-Response encryption/hashing scheme using Javascript. The algorithm for that would be something like this:
Server generates unique, random token, saves it and sends it to the client along with the form HTML.
On the client side, Javascript intercepts the form submission and hashes the sensitive form data with the server-generated token as a salt.
Server can now check whether the hash is equal to its own calculated hash value
HOWEVER
A man-in-the-middle attacker with the ability to modify traffic (for example through ARP poisening, DHCP or DNS spoofing) could always strip all your client-side protection mechanisms from the served HTML. Have a look at SSLStrip for a tool to rewrite HTTPS URLs to unsecure HTTP URLs on the fly. The challenge-response could be defeated something like this:
Save token sent by the server, remove the Javascript from the HTML form.
As the form submission is not intercepted now, we get the raw input data.
Hash the data using the same algorithm that the Javascript would have performed.
Thank you for all the fish.
You see, an intercepting attacker can probably defeat any defense mechanism you try to make up.