What happens to secure cookies on http requests. will it be lost over the request? What will happen if the cookie is a secure auth cookie?
RFC 6265 formalizes the behavior of HTTP cookies (as they work in the real world, not as they should ideally work, unlike some previous failed RFC):
Introduction
This document defines the HTTP Cookie and Set-Cookie header fields.
The description of the behavior of the "secure" flag follows:
4.1.2.5. The Secure Attribute
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]).
In practice only connections over TLS (that is, HTTP/S) are considered secure. Browsers could conceivably define direct HTTP connections to host "localhost" or an IP address that is by definition "local" (address of that IP stack), like 127.0.0.1 or ::1, or other local addresses, as secure. That would be in the spirit of the specification. (I don't know browsers that actually do so.)
Related
Application is deployed on AWS and serves on port 80 and ELB forwards that 80 to 443. Spring security is used for session which creates cookie with secure flag set. When I hit the application host name I could see that secure flag is set as shown below.
curl -I target_hostname
Set-Cookie: JSESSIONID=XXXXXXXX; Path=/; Secure; HttpOnly
But when i directly hit EC2 IP (using curl) I could see that secure flag is not set.
curl -I target_ec2_ip
Set-Cookie: JSESSIONID=XXXXXXXX; Path=/; HttpOnly
Why it is happening can anyone explain?
I'm going to assume that you terminate SSL at the ELB, and you're contacting the EC2 instance directly via HTTP (port 80). In that case, the following applies:
RFC 6265:
If the cookie's secure-only-flag is true, then the request-uri's scheme must denote a "secure" protocol (as defined bythe user agent).
NOTE: The notion of a "secure" protocol is not defined by this document. Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.
The MDN doc is more explicit:
Insecure sites (http:) can't set cookies with the "secure" directive anymore (new in Chrome 52+ and Firefox 52+).
I read many articles cookies are passed over HTTPS connection is encrypted.
I checked with my application, its having SSL connection, but i can read cookie information from request headers. Is anything done for cookie encryption in HTTPS connection?
HTTPS encrypts the entire session, headers included.
But notice that SSL (TLS in fact) works over the Transport Layer. If you are reading the cookies from the Application Layer (for example using javascript or a java servlet to get the HTTP request) the content will be already unencrypted.
See Does SSL also encrypt cookies?
I am new to web services and read about token based authentication which can be used with web services from What is token based authentication?. I searched on internet but its quite confusing how http based websites manage to do token based authentication without any security vulnerability.
What point I have?
I can sit in between server and client and store the token somehow by sniffing the traffic and make misuse of it before it expires. Am I wrong here?
EDIT
As mentioned on https://security.stackexchange.com/questions/46348/token-based-authentication-under-http.
"Facebook uses an OAuth token passed as a cookie or HTTP header and
protected by HTTPS."
How can I implement this as in that case the website will be http-based and only http-headers will be using https. Please correct me if I am wrong.
Your edit suggest a misunderstanding of what HTTPS does.
Normatively speaking, HTTP (meaning, the "language" that is spoken on the network, defined by https://www.ietf.org/rfc/rfc2616.txt) is a text based, "application level protocol", used over TCP sockets (TCP being the "transport level" layer).
In that sense, HTTP and HTTPS are the same "language", nothing differs in them. HTTP and HTTPS are both text based request/response protocols, each consisting of headers and an body, with requests specifying a verb such as GET, POST, PUT, ... No difference whatsoever.
What is different in HTTP vs. HTTPS, is that underneath this HTTP "language" (application level protocol), HTTPS uses TCP sockets that are encrypted using a SSL or TLS layer that provides encryption.
As the SSL/TLS layer happens under the HTTP layer, there can be no difference between what happens to the headers of a request and what happens to the body.
Back to your question :
How can I implement this as in that case the website will be http-based and only http-headers will be using https. Please correct me if I am wrong.
You can't have only the headers, and not the body using HTTPS in a single request/response cycle. It's all or nothing.
The conclusion is, as per the article you link to : token based authentication can only be secure if the token is always secured. Which, if you are always using HTTPS (in all request/response), is guaranteed (both the headers and the body are protected). If even one single request or response is not sent over HTTPS, then you have a flaw.
Cookies with secure flag can not be accessed when the SSL channel is not secure.
What about cookies without the secure flag? Are they sent to server when the certificate doesn't match the domain?
Thank you for your responses.
Yes, they are, which is consistent with RFC 6265 (A. Barth, HTTP State Management Mechanism)
I understand, we use SSL to encrypt sensitive data like user name and password to transported to server without people in the network eavesdropping. So then server returns a secure token over HTTPS and its stored in cookie. We switch to HTTP after we have secure token, we attach cookie/secure token header to every HTTP request.
Now anybody can see my secure token and they can eavesdrop it and impersonate me. Is my understanding correct?
The cookies can be set per protocol, so that HTTPS cookies are not used for HTTP and vice versa. Also, the properly constructed secure token should include an IP address and have short expiration time.
But in general the best idea is of course to keep the authenticated session in secure channel - SSL is not that heavyweight these days (as computers became much faster than when SSL was first introduced) and also the heaviest part is handshake, which is performed only once if persistent HTTP connection is used (or when SSL session resuming is used).