How to block file access requests from Chrome/Firefox on the basis of url?
For e.g. song.mp3 should not be allowed to access if *.google.com is being visited.
Related
I set up cors in azure storage (URL-for example: www.abc.com, GET, * , *, 200)
Then i just copy the link from storage
https://demo.blob.core.windows.net/demo/demo.png
And use it on postman or localhost (web), but still can display pictures, is it normal?
I suppose postman and localhost website will not be able to get images, once cors is set up for azure storage.
CORS prevents cross domain requests that are usually send by AJAX requests. If such a request is send from your browser it will perform a preflight request to see if your current domain is allowed to make such a request. As example it would prevent this site from sending a POST request in the background to api.<yourbank>.com to transfer money.
It won't stop anybody from embedding an image or other file on their website as the browser won't perform such a preflight request unless they call the resource through an AJAX request. Likewise Postman won't do that as it's a testing tool where you explicitely define the request you want to send without being on another 'domain'.
Is it possible to at a domain level (meta tag / HTTP header) to indicate to the web browser that no form of data persistence should be allowed.
Similar to how hsts tells the browser, you should ALWAYS expect to connect to this domain using SSL. Is there a way to tell you browser you should NEVER storage any for of data for this domain (Cookies / Local Storage / IndexDB) etc?
In our project, we are trying to integrate cookie-based authentication for content accessed using cloudfront cdn. Lets say that my application domain is A.com and is being accessed from B.com. A.com's content is served via cloudfont cdn. Now B.com wants to access content from secure cloudfront cdn. Generally B.com requests A.com for content. A.com redirects the request to cloudfront cdn. B.com has to send the authentication information to cloudfront.net via cookies with the redirected request.
see this for an elaborate diagram.
Now, I am setting the cookies in the response header of the initial request but am unable to find it in the redirected request header to cloudfront.net domain. As a result I am getting a 403 response and unable to access the content.
A.com can set the necessary cookies in the user's browser who is visiting application hosted in B.com domain. These third party cookies will be stored in the user's browser. When you will access the A.com domain again, the the stored third party cookies will be sent by the user's browser automatically with the request.
I can see that you want to send the A.com domain cookies to cloudfront.net domain and the browser will not allow it. Since the required cookies are not sent with the redirected request to cloudfront.net, the request is returning a 403 forbidden response.
If you own both the cdn distribution and the A.com domain, then you may create a cname say cdn.A.com which will point to your cdn distribution.
Now when the request is redirected to cdn.A.com to fetch the content, the necessary third party cookies will be sent across along with the request and the files could be accessed without any issues.
I have a website that will have customers logging into:
www.example.com/login
and will do their authenticated tasks here
www.example.com/dashboard/
Customers will also have their own public facing content here:
customer1.example.com
The public facing content is where they can't write their own content, so I am concerned if they write some javascript etc. to grab cookie information somehow i.e. they write javascript, and when a different user goes to their site who was authenticated on www.example.com, the javascript will grab their session cookie and send it over to another website.
When cookies are stored at the root domain and sub-domain, are they free accessible at each level?
Trying to understand the security implications.
Cookies will be accessible for all subdomains of the host you specify in the Domain attribute.
If you set Domain=example.com, the cookies will be available to all subdomains of example.com.
A cookie with Domain=www.example.com will only be accessible for www.example.com and subdomains of www.example.com (e.g. foo.bar.www.example.com) - no worries if you do that.
However, note that this also means it won't be accessible from example.com.
The most restrictive option is to omit the Domain attribute, by not sending it at all. In that case, the cookie should only be accessible for the hostname that sent it. That is, if you send it from www.example.com, it will only be sent back to www.example.com and not even to its subdomains.
This is all explained in RFC 6265, section 4.1.2.3.
I am building an ASP.NET Azure Web Application (Web Role) which controls access to files stored in Azure Blob Storage.
On a GET request, my HttpHandler authenticates the user and creates a Shared Access Signature for this specific file and user with a short time frame (say 30 mins). The client is a media player which checks for updated media files using HEAD, and if the Last-modified header differs, it will make a GET request. Therefore I do not want to create a SAS url but rather return LAst-modified, Etag and Content-length headers in response to the HEAD request. Is this bad practice? In case the file is up to date, there is no need to download the file again and thus no need to create a SAS url.
Example request:
GET /testblob.zip
Host: myblobapp.azurewebsites.net
Authorization: Zm9v:YmFy
Response:
HTTP/1.1 303 See other
Location: https://myblobstorage.blob.core.windows.net/blobcontainer/testblob.zip?SHARED_ACCESS_SIGNATURE_DATA
Any thoughts?
Is there a specific reason to force the client to make a HEAD request first? It can instead authenticate using your service, get a SAS token, make a GET request using If-Modified-Since header against Azure Storage, and download the blob only if it was modified since the last download. Please see Specifying Conditional Headers for Blob Service Operations for more information on conditional headers that Azure Storage Blob service supports.