Cookies received from Server is Secure But Cookies sent to Server is not secure ASP.NET

Question

In my ASP.NET Web application, i have made the below changes to make the ASP.NET_SessionID and .ASPXAUTH Cookies Secure by adding the below entries to web.config

<httpCookies httpOnlyCookies="true" requireSSL="true" />

and adding the below tag

<forms requireSSL ="true" /> 

But my issue here is that, the Cookies received from Server(Network->Cookies->Direction Column has a value of received) has Secure and HttpOonly flag set to true. Found the information when i debug using IE 11 Developer tools, but the cookies data sent to Server(Network->Cookies->Direction Column has a value of Sent) does not have any Secure or HttpOnly flag set to true.

Is this the default behaviour? If so, why the data sent to server is not having the Secure and HttpOnly flag set? How to set it other than the above changes made to the config file.

Nagpur

Answer 1

Cookie flags, like Secure and HttpOnly, are only sent from the server to the client. You won't ever see them in traffic going the other way. If you want to make sure that a cookie is Secure, have the browser make a request over HTTP (instead of HTTPS) and see if the cookie is still present (it shouldn't be). If you want to make sure a cookie is HttpOnly, open your site in the browser and then check the value of document.cookie using the JS console in the dev tools; you should see any non-httponly cookies you have but no httponly cookies.

Cookies are an inherently client-side thing. They are a way for a server to tell the client "every time you make a request to me, include this bit of info". The Secure flag modifies that to say "Every time you make a request to me over a secure connection, include this bit of info (but don't ever divulge it over insecure connections)". A conforming user agent - that is to say, a web browser - is supposed to obey those directives. However, there are no equivalent directives the other way; servers don't have to do anything at all with cookies the client sends them, and there is no "client sets a cookie on the server" equivalent of the way servers can set cookies on the client. Directives (including Secure, HttpOnly, Domain, Expires, etc.) are only used when setting a cookie.

Rosalia

Thanks @Rosalia for the reply. But i have one more question, i have created a Jquery cookie using the Secure keyword as below '$.cookie('Name', 'Value', { path: '/' ,secure:true});'. So If it try to access the cookie using http protocol will it not be there. So that seems the cookie is secure? – Nagpur

Yes, you can also create cookies using JavaScript and, as with when they are set by the server, you can control the cookie's parameters including options like Secure. The same test I described before - check the traffic to the server, HTTPS should have the Secure cookie but HTTP shouldn't - will work whether the server set the cookie or a script did. – Rosalia

As per your suggestion, i have checked the traffic of the site using Fiddler for a cookie which is set using javascript, there is no secure cookie set. Also i did not get your point italic - will work whether the server set the cookie or a script did. italic. Sorry for that. Can you brief that line. – Nagpur

The test I was referring to is "visit https://yourdomain.com, observe all the cookies including the Secure ones. Then visit http://yourdomain.com, observe that only the non-secure cookies get sent". This happens no matter how the cookies are created. – Rosalia

You seem to be expecting the Secure flag to appear in the traffic that the browser sends. THIS WILL NEVER HAPPEN because that flag is ONLY used when creating a cookie, and cookies are only created BY THE SERVER in a response it sends to the client, or by script running on the client. A request FROM the client is never creating a cookie, so it will never include the cookie flags. Another way to put it: the Secure flag is only used on the Set-cookie header (which is only in server responses, never in browser requests), not the Cookie header (which is in requests, not responses). – Rosalia

The browser remembers the flags on a cookie from when the cookies was set (created). So if a server says, in a response to an HTTPS request, Set-cookie: cookiename=securevalue; Secure then the browser will create (or update) a cookie for that site, called cookiename, with the value securevalue, and will remember that it is a Secure cookie. But it doesn't need to tell the server that it's a Secure cookie; the server doesn't care. – Rosalia

I am clear with the explanation.I am really getting clear picture now. One thing you have mentioned is that Cookies can also be created by script running on the client right in the above comment? So how do i see if the secure attribute is set for that client side cookie set in script. – Nagpur

There's no way, in general, for a browser to tell you whether a given cookie is secure. It knows, but it doesn't expose that info anywhere. To find out, send two requests to the server, one over HTTP and one over HTTPS. If the cookie is in both of them, it's not secure. If it's only in the HTTPS one, it's secure. If it's not in either, it didn't get set correctly or has expired or something else like that. – Rosalia

Got it :) thanks a ton for spending this much time in answering the questions which i have asked. – Nagpur