Let's say there is a website, which after authentication sets a browser cookie. This cookie is sufficient to authenticate a user, so if I were to transfer it to another computer's browser, the website would consider this browser authenticated.
The website uses HTTPS for all communications, except for the following. Whenever a user sends a request to http://domain.tld/ and gets redirected, the sensetive cookie gets sent in the first request, using HTTP (non-secure).
It seems weird to use HTTPS after sending the key using plain text. Is this a security concern, or am I not understanding this correctly?
Sensitive cookies needs to be protected by Secure attribute. Otherwise, it's easy to be intercepted by active network attacker. According to RFC6265:
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS)
In this way, sensitive authentication cookie won't be sent in non-HTTPS requests, thus keep it confidential. Example Set-Cookie statement is:
Set-Cookie: SID=31d4d96e407aad42; Path=/; Secure; HttpOnly
However, please note Secure attribute only protect cookie's confidentiality, not integrity:
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity.
Related
The MDN docs on HTTP cookies state:
A secure cookie is only sent to the server with an encrypted request over the HTTPS protocol. Even with Secure, sensitive information should never be stored in cookies, as they are inherently insecure and this flag can't offer real protection.
HTTPS requests have their request bodies and all of their headers encrypted with TLS, including the Set-Cookie: response header and the Cookie: request header. This should prevent third parties from reading or tampering with the cookie values.
So why are cookies "inherently insecure"? (Perhaps Mozilla is thinking of someone with access to the user's computer being able to inspect their cookies?)
Why are cookies "inherently insecure"?
The biggest problem of cookie is: it is stored in user's computer, which leads to many possibilities. The server lost control of the cookie's privacy once it is sent to client. As the cookie data is stored in user's computer, the data can be leaked when:
Vulnerability in operating system is exploited by attacker.
Vulnerability in user-agent is exploited by attacker.
Browser extension can get permission to read cookies (e.g. Chrome). Yes, a notification will be displayed to user, but a lot of people just ignore the alert and click "Yes".
Cookie can be inspected in browser dev tool, by another people.
More...
For secure flag, if you send sensitive information in secure cookie to browser, there are still security concerns:
As long as httpOnly flag is not set, all malicious script can read that cookie, and send the information to any server.
If domain setting is not correct, you may leak that sensitive cookie to some interfaces. For example, if the secure cookie's domain is /, then all backend API would receive the sensitive data, which may not be what you want.
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.
Assume you have XSS attack on your site.
Hacker can make any request with cookies.
So, what's point to hide this value from client?
In an XSS attack, "hackers can make any request with cookies", but NOT all cookies. If one cookie is HttpOnly, it cannot be accessed by client JavaScript, which means hackers cannot read the cookie value and send it to his own server, not even know whether this cookie exist.
Normally, when HttpOnly is used to protect cookie, the cookie's Domain is also set (if Domain is missing in HTTP response's Set-Cookie header, browser will set the cookie's domain as that HTTP connection's hostname). Hackers can trigger HTTP request and make browser put HttpOnly cookie in the request, but it would be restricted by cookie's Domain -- the cookie is sent only when its Domain match the HTTP request. Thus, HttpOnly cookie with website's Domain is safe, it will not be leaked to XSS attackers.
Well Http Only cookies can only be accessed by the server. They cannot be accessed from JavaScript. Which means it will be more difficult for hackers to use these cookies for their own use.
Http Only cookies reduces the possibility of Cross Site Scripting attacks on websites.
See this link for more information: https://www.owasp.org/index.php/HttpOnly
I have a Web API application and have configured SSL for it.
Our authentication mechanism is via the header. Each request will have to contain a pair of keys that we will validate them against our database. We're not using Forms/Basic or Digect authentication.
I'm just wondering do we have to do anything with regard to the Cross-Site Request Forgery (CSRF) issue? is it applicable in this case?
I thought because we're not using the cookies so it should be safe.
Indeed, forcing another user to do a request only has an advantage for an attacker if that user's browser automatically pushes some credential that the attacker does not have. That can be:
auth cookie
HTTP Authentication (Basic/Digest/Windows Auth)
TLS session ID (in HTTPS)
implicit authorisation from IP address or network location (eg intranet site)
If you are not relying on any such credential, then there is no CSRF attack to defend against.
I know that a cookie with secure flag won't be sent via an unencrypted connection. I wonder how this works in-depth.
Who is responsible for determining whether the cookie will be sent or not?
The client sets this only for encrypted connections and this is defined in RFC 6265:
The Secure attribute limits the scope of the cookie to "secure" channels (where "secure" is defined by the user agent). When a cookie has the Secure attribute, the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS) [RFC2818]).
Although seemingly useful for protecting cookies from active network attackers, the Secure attribute protects only the cookie's confidentiality. An active network attacker can overwrite Secure cookies from an insecure channel, disrupting their integrity (see Section 8.6 for more details).
Just another word on the subject:
Omitting secure because your website example.com is fully https is not enough.
If your user is explicitly reaching http://example.com, they will be redirected to https://example.com but that's too late already; the first request contained the cookie.