Imagine the following scenario:
The user goes to http://example.com
The server redirects to the secure version https://example.com using a temporary redirect (status 302)
https://example.com responds with an HTTP basic auth challenge (status 401)
The user successfully provides username/password and access is granted (the browser stores these credentials in its internal cache)
What happens if the user follows a link to the unsecured version of the website (http://example.com)?
Would the credentials be exposed due to the clear-text HTTP request?
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Technically, the two URLs belong to different origins so the credentials should not be shared. But I could not find any confirmation of this online.
Are HTTP credentials and HTTPS credentials stored in separate "buckets" by the browser?
Yes, and those buckets are officially called 'origins'. Specifications like HTML, Javacript, HTTP and URIs talk about origins, but the bucket is effectively the URI minus the path.
So for https://example.org/foo/bar, the origin is https://example.org
So this includes:
The scheme (http / https).
The domain
The port
So in your example the 2 relevant origins / buckets are http://example.com and https://example.com and they are separate.
Related
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.
I'm having difficulty using Nginx's http_auth_request_module with dynamic, user specific URLs.
http://nginx.org/en/docs/http/ngx_http_auth_request_module.html
I need to authenticate (using OAuth 2) a user whenever they attempt to access their notifications. I've got an Nginx instance acting as a reverse proxy to an API (api.*) built on Django, and a Node server (notifications.*) for real-time notifications.
Assuming I can authorize requests (return 200 on success, 403 on failure) through my API at:
api.example.com/authorize/user_id/ 'Authorization:Bearer user_access_token'
And the user's request is:
notifications.example.com/user_id/ 'Authorization:Bearer user_access_token'
How would I dynamically take the user's request to the notifications subdomain, proxy it (including user ID & access token) to my API to authenticate, then continue proxying to notifications iff the user is authorized?
I think the problem really comes down to how do I dynamically set the auth_request URL with the request's user ID and access token. Any help would be greatly appreciated!
We are setting up a website with secure and non secure pages. These have been added for mapping in uriworker.properties. The domain name in the urls are different . Example nonsecure url is x-y-z.a.b.org and our secure url is x-y-secure-z.a.b.org.Both of these domains are part of our DNS entry. We do not have any redirect rules configured within the webserver. But when we try to access the secure url https://x-y-secure-z.a.b.org, webserver is sending the request as http://x-y-secure-z.a.b.org:443. Due to the scheme not being https , the application does not identify this as secure request and is returning a 302 to the https url. This redirection happens infinitely and then an error appears which says that page is not redirecting properly.
After a lot of analysis , we figured out that the application had a hardcoded check on the scheme of the domain name to be in a certain format as secure.xyz.
I have two website, Site A and Site B.
Site A is on the DMZ area where allow public/anonymous sending http request (one of the client http request data), and i would like the request to redirect to Site B(internal secure host which only allow internal http request)
My question is, Site B is setup with basic authentication REALM. but public/anonymous http request doesn't support Basic REALM. is there a way in the IIS Site A to redirect the request with authentication so Site B could accept the request with REALM
I have found a way to resolve the above question by using Microsoft ISA Server
I have a site that has a mix of http and https pages. Under the root of the site, one folder has all the http pages and another has all the https pages. Login is over https and sends the user to the other pages. When a session expires the forms authentication redirects to the Login page but the browser uses http and the user gets a 403 error.
Is there any way to override the session timeout to send it to https?
one way is to configure IIS to redirect http traffic to https
http://support.microsoft.com/kb/839357
one thing to consider with mixed mode like that:
there is a common attack on SSL pages, which is, making a http request (to https resource) in order to obtain the un-encrypted session cookie. This is why you want to configure your session cookie to encrypted only (would not be sent over http). I am guessing that your http and https pages share session, which means you can't set this setting, making your site vulnerable to this attack. but it's good to be aware of this.
http://anubhavg.wordpress.com/2008/02/05/how-to-mark-session-cookie-secure/
another article you may find helpful
http://www.west-wind.com/Weblog/posts/4057.aspx