When I go to the HTTPS server, I can see in Developer tools (or in Fiddler) a request cookies that are send to the server by client. But how client know, which cookies should be sent, if no response cookies are sent by server. At least I can´t see any response cookies in Developer tools or Fiddler.
First up each domain has its own cookies in a cookie jar / cookie store. Whenever a request is made by the browser to the server all cookies in the store for that domain or subdomain will be sent to the server.
secure cookies vs insecure cookies
Secure cookies will be sent only on connections that are made over ssl(https protocol). Normal cookies will be sent on both http and https protocols.
session cookies vs. persistent cookies
session cookies - These cookies persist as long as the browser session is open. This means that Once you have cleared cache or closed the browser they get lost.
persistent cookies - These will persist even if the browser is closed and opened again unless you have set the browser to clear cookies on exit in which case they will behave just like session cookies.
First party cookies vs. Third party cookies.
First party cookies - generated by the domain currently open as main document - this means they have same domain as the one displayed in your browser.
Third party cookies - generated by a different domain then currently opened by the browser(in the addressbar) but which are managed inside an iframe or various resource calls like css, script, media(images, videos or other embedded media)
CORS - cross domain calls via xhttp ajax calls - this case arises when you create a domain requests resources from another domain via xhttp(ajax calls). In this case the browser makes a preflight check to see if the receiving domain accepts queries from the origin domain(origin headers are sent to the domain to check the cross domain policy). The server must necessarily respond with a valid options header and the server may allow identity data which is short for cookie data. If the remote domain has answered correctly with an "Access-Control-Allow-Origin" header that allows your domain or "*" then you are allowed to send cookies via this request. And these will behave just like normal calls.
To read more about cors:
https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
To directly answer the question: the client sends back all cookie data it has for that domain and path.
If you do not see any Set-Cookie header in any HTTP response, it may be because the cookie has been issued by server and stored on your computer before you started looking at Dev Tools or Fiddler. It could have been up to a few days, weeks, even months ago.
In Firefox, if you navigate to about:preferences#privacy and click Manage Data, you can see which domains already have cookies issued and stored on your computer. The Storage tab in Firefox Dev Tools can show you details of all cookies. The expiry of the cookie is determined by the server, using the Expires or Max-Age directive in the Set-Cookie header.
How a cookie first ended up on the client computer:
Client makes its first ever HTTP request to server, e.g. GET www.example.com
Server creates a cookie and sends it back in the HTTP response, e.g. the response headers contains a line: Set-Cookie: sessionID=1234567; path=/; Max-Age=31536000
The client receives HTTP response and stores the cookie in the "jar" for domain www.example.com.
How server uses cookies to identify the client
In subsequent HTTP requests to domain www.example.com, the client sends back all cookies in the jar that matches the path or sub-path. For example, the client wishes to issue a request GET www.example.com/about, sees that the URL is a sub-path of / in domain www.example.com, so it sends the cookie as a line in the HTTP request header, i.e. Cookie: sessionID=1234567.
The server sees the cookie and knows exactly which client made this request.
Related
I'm making http request from React to our API for authentication. I'm using fetch to make the requests.
My question is, can a user go to the network tab in chrome dev tools, find the request, and see their own token?
It depends.
Normally, user can see all request headers in the HTTP request, in Network panel of Chrome dev tool.
However, after Chrome 67, a new feature named "Site isolation" was introduced, and enabled by default. As a result:
In Chrome's DevTools, cookies and other request headers are not shown in the network panel for cross-site subresource requests.
That is, if JWT token is transferred by cookie in a subdomain site, and the domain of JWT-cookie is wildcard, it will not be displayed in Network panel.
Here is an example. cookie token's domain is .miaotest.com, and it is used in HTTP request to site cshao.miaotest.com. While this cookie is transferred to backend successfully, you won't see it in "Request Headers" part in dev tool.
Cookie token's information in "Application" panel:
Cookie token is sent but not displayed in Network panel:
Please note the "Site isolation" feature can be disabled by visiting chrome://flags/#site-isolation-trial-opt-out in Chrome.
Yes, he can see the whole request including all request headers.
I am having trouble understanding how a session is restored via cookies. How do the client know which sessionID cookie to send to the server via the HTTP request the first time? Does the client send all cookies and the server accepts the one that it also knows?
For example, let's say there are websites A and B (both using PHP), and I logged into both websites and then closed my browser. Now I open the browser again and go to site A and see that I am kept logged in. In this scenario, when my browser sends the HTTP request, the cookie whose file name contains the session ID for site A must have been included in the header. However I have two sessionID cookies for both site A and B. As far as I understand, the host name is usually not stored in the cookie, at least in many PHP tutorials of the setcookie() function. How do my browser know which sessionID cookie is for site A? Does the browser just send all cookies to A and let A figure out which is the right one by comparing all the received session IDs with stored session IDs? This does not sound right to me.
We have a somewhat odd situation.
Our environment consists of 2 web servers (Windows 2016 running IIS) and a load balancer. The applications are running .Net Framework 4.
MachineKey with matching Encrypt/Decrypt and other attributes exists in the .Net web.config (server level).
We noticed that the Set-Cookie Response header was missing when making requests to a specific server.
Further digging identified the following.
Direct URL request following authentication to Server 2 - Response Set-Cookie with Auth cookie correctly set.
Refresh of the URL on Server 2, Request Cookie sent with Auth cookie, Response Set-Cookie with Auth cookie correctly set again, new cookie with sliding expiration date.
Request of the same URL on Server 1, Request Cookie sent with Auth cookie (cookie is HTTP Only but allows any server in the domain to access), Single Sign On Auth is successful since MachineKeys match, Response Set-Cookie with Auth cookie correctly set again, new cookie with sliding expiration date.
Request of the same URL back on Server 2, Request Cookie is sent, user is still authenticated ask cookie is still valid, but no Response Set-Cookie comes back with the server Response.
From that point forward no Set-Cookie will come back from Server 2 until a logout is forced, which returns a Response Set-Cookie with expiration date set in the past, which browser sees and expires the cookie.
IP Stickiness cannot be enabled on the Load Balancer (due to CDN and other restrictions), so a user that authenticates on Server 1, or accesses Server 1 for any requests, results in no longer receiving any Response Set-Cookie headers from Server 2.
Application is proven and has worked correctly in several similar environments. Seems to be server specific issue.
Any ideas on server configuration that may cause this?
I have a site (running a 3rd party app) that's available over HTTPS and HTTP. It allows people to log in with Basic Authentication. I'm trying to force all logins to happen over HTTPS rather than HTTP.
The app is odd in that the authentication "realm" is the root of the domain (/), and 401s are returned based on query string parameters rather than the URL path. I think I've got my RewriteRules set up properly so that any request that could result in a 401 is redirected to HTTPS first. However, I'm worried that after logging into the secure site, if users navigate back to the HTTP version somehow, browsers will still send Authorization headers (now unencrypted) without seeing a 401 since it's all the same domain with the /same/path/structure. That is, I'm worried about this behaviour from RFC 2617:
A client MAY preemptively send the corresponding Authorization header with requests for resources in that space without receipt of another challenge from the server.
Should I worry? Or does switching protocols (https to http) prevent browsers from sending those preemptive auth headers?
We heavily use basic auth for our application. All using https of course :)
Browsers have a good sandbox model, they know that when the protocol changes, the target machine may not be the same anymore. You don't have to worry about browsers submitting the authentication information.
Even when they run into the initial 401, they will still ask the user for the username/password pair.
I have two virtual directories, one hosts an application the other hosts a web service layer running WCF with ASP.NET compatibility mode enabled.
The service project has an HTTP module that deals with authentication for incoming requests. The login service writes an authentication cookie to the client.
Subsequent requests are handled via AJAX (jQuery) to the services from the application project (another virtual directory on the same domain.)
Cookie domain is set correctly, the cookie path is "/", the cookie is set to HTTP ONLY so that scripts cannot interact with it.
My issue is the login service seems to be sending the SET-COOKIE header with the correct payload in the cookie, however the subsequent requests are not sending the cookie back to the server, in fact when inspecting the local store the cookie is not even there.
Potentially what could be my issues?
We tracked the issue down to Chrome. Apparently there was a prior bug that seems to be presenting itself again whereby expires cookies are not promoted to session and are instead discarded.