I serve my site with SSL and I want to accept cross-origin requests only from sites with SSL as well.
Is it possible?
The basic logic that you need is:
IF the value of the Origin request header STARTS WITH https:
THEN include a Access-Control-Allow-Origin response header with the value copied from the Origin request header.
ELSE … don't.
The specifics of how you implement that pseudo-code will depend on what technology you are using on your server.
Related
I'm new to HTTP protocol and I have limited experience in networking.
I'm wondering which http request headers can be set arbitrarily and which headers cannot.
For example, can I create a http request to www.twitter.com and set the Referer header value to www.google.com even though I did not visit the www.twitter.com website by clicking a link on www.google.com??
Can it be forged?
If so, which other http request headers can be forged like this?
I don't quite get the difference between UseHsts and UseHttpsRedirection in the configure section of the startup file in .net core. Could anyone explain?
According to the documentation you should use both together:
We recommend all production ASP.NET Core web apps call:
The HTTPS Redirection Middleware (UseHttpsRedirection) to redirect all HTTP requests to HTTPS.
UseHsts, HTTP Strict Transport Security Protocol (HSTS).
ASP.NET Core Enforce HTTPS
The .UseHttpsRedirection() will issue HTTP response codes redirecting from http to https. The .UseHsts() will add the HSTS response header which the client is supposed to obey.
UseHsts adds the Strict-Transport-Security header to the response, which informs the browser that the application must only be accessed with HTTPS.
After this declaration, compliant browsers should automatically convert any http request of the application into an HTTPS request.
UseHttpsRedirection causes an automatic redirection to HTTPS URL when an HTTP URL is received, in a way that forces a secure connection.
Once the first HTTPS secure connection is established, the strict-security header prevents future redirections that might be used to perform man-in-the-middle attacks.
I was just wondering this small little question. I know it is irreverent to coding, but I just had to know quickly.
If you type in http:// for a https:// will it still take you to the correct place?
That is mostly dependent on the server configuration. The server has to accept the initial HTTP request and be configured to redirect the client to an appropriate HTTPS url.
That being said, there are some Internet standards related to automating HTTP-to-HTTPS upgrades. HTTP Strict Transport Security and Upgrade Insecure Requests allow an HTTP/S server to tell clients that it wants them to automatically use HTTPS for all subsequent requests. If a client visits an HSTS/UIR-enabled server, it will receive a normal HTTP response with additional HSTS/UIR-related headers. If the client supports HSTS/UIR, it will then know to automatically send all subsequent HTTP requests to that same server using HTTPS, and in the case of UIR also treat any received HTTP URLs as if they were HTTPS URLs.
Some pages on my website (authentication, payment) must be served over HTTPS.
When a client hits such a page over HTTP, I want to redirect it to the HTTPS version.
At the moment I'm using a 301 Moved Permanently code with a Location header that points to the same URL with the scheme modified to HTTPS.
I'm wondering: is there a specific HTTP response code for using the wrong protocol?
Something that would be similar to 405 Method not allowed for the HTTP verb.
Not as such, no — the 301 permanent redirect is exactly the right choice here.
However, there is such a thing as HTTP Strict Transport Security (HSTS), which allows you, once you've told the browser to use HTTPS using the 301 redirect, to also tell it never to use the unencrypted HTTP protocol again on your site. The way you do this is by including a header like shown below in the HTTPS response (not in the redirect, which is sent over plain HTTP):
Strict-Transport-Security: max-age=31536000; includeSubDomains
For more details, see the Wikipedia article linked above and RFC 6797.
According to this, 403.4 seems to be what you want (in IIS), but I don't believe there is an equivalent in the HTTP standard.
Response 301 seems reasonable for the login pages etc. (where no credentials are needed to be transmitted to load the page). Otherwise when personal details have been sent it is wise to say not found (401) as somebody is being mischievous. It is also wise to check the referrer URL and also periodically check the log files.
(People do copy web sites and masquerade as yours, just forwarding traffic and collecting personal details in the process :-( )
I was going through the firefox local cache folder and found a lot of files containing the X-cache header. Can someone explain the purpose of this header ?
thanks
CDN (Content Delivery Network) adds X-cache header to HTTP Response. X-cache:HIT means that your request was served by CDN, not origin servers. CDN is a special network designed to cache content, so that usr request served faster + to unload origin servers.
Prefix 'X' in X-Cache indicates that the header is not a standard HTTP Header Field. Also its meaning vary from one proxy implementation to another. A common place to find these header fields is in squid servers. Organizations and universities place proxy (squid) servers between their and
outer network. This serves two purposes. One of security, and other of caching more frequent web pages (in order to limit network traffic).
X-Cache corresponds to the result, whether the proxy has served the result from cache (HIT for yes, and MISS for no)
X-Cache-Lookup represents if the proxy has a cache-able response to the request (HIT for yes and MISS for no)
Both HITs means that the client has made a cache-able request and the proxy had a cache-able response that matched, and was forwarded back to the client.
In case X-Cache is MISS and X-Cache_Lookup is HIT, then the client made a request that had a cache-able response but was forced by the client to bypass the cache. This is hard refresh, which can be simulated by Ctrl + F5 or by sending headers:
Pragma: no-cache (in HTTP/1.0) and Cache-Control: no-cache
(HTTP/1.1)
If both are MISS(es) then the request by the client doesn't have any valid object corresponding to the request.
Some Useful Resources:
X-Cache and X-Cache-Lookup Headers
Understanding cache HIT and MISS headers with shielded services
X-Cache "is NOT a standard HTTP header field".
Also, check out X-Cache and X-Cache-Lookup headers explained.
for me me this was related to fastcgi cache header existing on Nginx server block
add_header X-Cache $upstream_cache_status;
just removing commenting this line and restart nginx the header were removed .