I did an HttpOnly cookie using the article:
https://learn.microsoft.com/pt-br/dotnet/api/system.web.httpcookie.httponly?view=netframework-4.7.2
the creation of HttpOnly cookie is the following:
// Create an HttpOnly cookie.
HttpCookie myHttpOnlyCookie = new HttpCookie("LastVisit", DateTime.Now.ToString());
// Setting the HttpOnly value to true, makes
// this cookie accessible only to ASP.NET.
myHttpOnlyCookie.HttpOnly = true;
myHttpOnlyCookie.Secure = true;
myHttpOnlyCookie.Name = "MyHttpOnlyCookie";
Response.AppendCookie(myHttpOnlyCookie);
// Show the name of the HttpOnly cookie.
Response.Write(myHttpOnlyCookie.Name);
Ok, I saw this article that says:
https://latesthackingnews.com/2017/07/03/what-is-httponly-cookie/
HttpOnly tells the browser to save the cookie without displaying it
to client-side scripts. A secure flag, on the other hand, forces the
browser to send cookies through an encrypted channel such as HTTPS,
which stops eavesdropping, especially when an HTTPS connection is
downgraded to HTTP through tools such as SSLStrip and so on.
Ok,
but I did an http-only cookie in my .aspx webpage but I could see it through Chrome's cookies file:
C:\Users\<user>\AppData\Local\Google\Chrome\User Data\Default\Cookie
I set the flags:
myHttpOnlyCookie.HttpOnly = true;
myHttpOnlyCookie.Secure = true;
Question 1- if HttpOnly tells the browser to save the cookie without displaying it to client-side scripts, why could I access the name of the cookie within Chrome's cookie file?
Question 1.1- Is its content accessible, but just not using scripts?
Question 2- It's silly, but I can't access the HttpOnly cookie via aspx using the code:
HttpContext.Current.Request.Cookies["test_MyHttpOnlyCookietest"]
Is it the only way to access it via server side?
Question 3- When I put myHttpOnlyCookie.Secure = true;
I can't acess it via a non HTTPS connection - is that right? Just using https I can access it?
Question 4- If I use myHttpOnlyCookie.Secure = true, there is an encryption and decryption.
How costly is this in processing power?
Http Only cookies are not exposed to client scripts, of course the browser has access to it since it supposed to send it back to the server.
You can access it using Request object in Asp.net like any other cookie.
Setting "Secure" attribute means that the cookie can be used only in a secure connection i.e. https, so it won't work under http. The overhead of encryption/decryption is not specific to cookie, actually it happens in TCP level for all data transfers, and the overhead is like any other https connection (which are not that much considering today's servers). The size or number of cookies can affect the overhead because the data is being transferred in any call.
Related
I'm using Flask-JWT-Extended and double submit cookie method from there for my Flask backend and React Frontend. So when user logs in from frontend, backend sets total of 4 different cookeis: csrf_access_token, csrf_refresh_token, access_token_cookie, refresh_token_cookie. Out of these 4 cookies, access_token_cookie and refresh_token_cookie should be HTTPonly cookie, and thus not accessible by JS and csrf_access_token and csrf_refresh_token are non-HTTPonly cookie. So the idea here is that HTTPOnly cookie holds user's session information with CSRF token and non-HTTPonly cookie holds the CSRF token and when POST request is made, CSRF token accessed by JS is sent to backend along with the other cookies.
This was working just fine in my development environment, two of the cookies were accessible by JavaScript and thus I could send csrf_acccess_token along with the request with withCredentials True, but when I deploy this to test environment with TLS using Nginx (Both backend and frontend), it is setting all 4 cookies as HTTPOnly cookie, and thus, I cannot make any POST request.
I'm not sure whether this was caused by the Nginx, but from what I can tell, I don't see much options to turn off 2 of the HTTPOnly cookies being registered from the backend.
Below is my configuration for flask-jwt-extended
CORS_HEADERS = "Content-Type,X-CSRF-TOKEN"
JWT_TOKEN_LOCATION = ["cookies"]
JWT_COOKIE_SECURE = True
#JWT_COOKIE_SAMESITE = None
JWT_ACCESS_TOKEN_EXPIRES = 600
JWT_REFRESH_TOKEN_EXPIRES = 1200
JWT_CSRF_IN_COOKIES = True
JWT_COOKIE_DOMAIN = ".mydomain.com"
#JWT_ACCESS_COOKIE_PATH = '/'
#JWT_REFRESH_COOKIE_PATH = '/'
JWT_COOKIE_CSRF_PROTECT = True
JWT_SECRET_KEY = "secret"
Any advice would be greatly appreciated!
Flask-JWT-Extended should never be setting the csrf cookies as httponly. I wonder if there is an nginx setting that is converting all cookies to httponly (something like proxy_cookie_path)?
If that’s the case, another approach you could take it to set JWT_CSRF_IN_COOKIES to false, and use https://flask-jwt-extended.readthedocs.io/en/stable/api/#flask_jwt_extended.get_csrf_token to grab the csrf token when a JWT is created, return it as part of the JSON payload, and store it in localStorage instead of in those non-httponly cookies so that your JavaScript can still grab it when making requests.
I'm working on making a Symfony website secure. I have taken a look at this page: How to set secure and httponly attributes on Symfony 4 session
and applied the suggested change into framework.yaml:
session:
handler_id: ~
cookie_secure: true
cookie_httponly: true
When I log in, in the network tab I see three instances of Set-Cookie. The first is a cookie removal, having secure and HttpOnly attributes. The second is a cookie creation, where the cookie identifier has the secure and HttpOnly attributes. The third is setting some parameters in an HTTP-encoded manner, this one also has the secure and HttpOnly attributes. So far so good. However, when I go to any page, I have a Cookie attribute among the Request Headers which has the same identifier as the one which was created earlier, but the secure and HttpOnly attributes are not specified.
So, when I log in and the cookie is created I have the attributes I expect, but later, on visiting separate pages I no longer see them. Why is the secure and HttpOnly attribute not specified on later, after-login Request Headers? Did I miss something?
The security attributes are set by the server in the Response headers and the browser uses them to determine if it has to send the cookie along in the Request, but it never sends the attributes themselves, just the cookie value. If you inspect an ajax or unsecure request the cookie header should not appear in the request at all.
You can see some examples in the RFC6265.
I am attempting to change an MVC web site that was storing some info in Session to store it in a cookie but am having some issues with the expiry of the cookie.
Scenario
While logging in to the site a cookie is created and added to the current HttpContext Response cookies collection. The code piece used to write the cookie is as follows :
HttpCookie userCredsCookie = _context.Response.Cookies.Get(Constants.Web.UserCredentialsCookieName) ?? new HttpCookie(Constants.Web.UserCredentialsCookieName);
userCredsCookie.HttpOnly = true;
userCredsCookie.Secure = true;
userCredsCookie.Value = user.ID.ToString();
userCredsCookie.Expires = DateTime.Now.AddMinutes(user.CompanySessionTimeout + user.TimezoneOffset);
_context.Response.Cookies.Add(userCredsCookie);
I have experimented with removal of the line that sets the expiry of the cookie and have found that the cookie is generated and stored at the client as expected.
When i inspect the response from the server using Fiddler i can see that the userCreds cookie is being returned :
Response sent 111 bytes of Cookie data:
Set-Cookie: UserCreds=e2ce8200-fb38-45b9-8aec-4d93e6640a84; expires=Mon, 09-Oct-2017 16:20:43 GMT; path=/; secure; HttpOnly
when the expiry is not set the response has :
Response sent 72 bytes of Cookie data:
Set-Cookie: UserCreds=e2ce8200-fb38-45b9-8aec-4d93e6640a84; path=/; secure; HttpOnly
As long as the expiry is not set, the cookie is accepted by the browser and sent on the subsequent requests made from the browser.
It feels like the problem is due to the format of the date in the response but i cannot find anything to allow me to change that format.
Any help would be greatly appreciated.
Regards
Monty
Update - Possible cause located
I have found that the problem i am having is to do with timing. It seems that my dev pc may be processing the responses from the ajax call that is setting the cookie too fast (??? is that even possible ???).
While i was debugging the front end code to ensure things look fine from that perspective i found that by placing a break point just before the line which was setting the window.location to a url that is in the result of the ajax call, the subsequent call was made with the cookie being on the request.
Perhaps, by causing the processing of the callback to pause, gave the system time to persist the cookie. I assume the process of persisting a cookie is to do a validation check then store the data. That would mean that it takes a little longer to validate the cookie when their is an expiry date set. Perhaps the reason why a cookie with no expiry set was persisting but ones with an expiry were not was cause the load of a new url interrupted the process, thus causing the cookie to not get stored.
By adding a 1 millisecond delay (yep, just 1 millisecond) in the success handler of the ajax call i was able to successfully have the cookie persisted to the browser and included in the call made to load a return url that is in the ajax response.
Does this sound even possible?
try with this code
int result = Convert.ToInt32(user.CompanySessionTimeout.ToString()) + Convert.ToInt32(user.TimezoneOffset)
and then pass
userCredsCookie.Expires = DateTime.Now.AddMinutes(result);
Ive made some configurations to (finally) have my cookies set on HTTP only.
"Seem" to work.
Ive tried them with postman and I have the following:
When I hit the login page:
On the cookies section, my cookie with name JSESSIONID appears to be HTTP only (it has the check)
When I enter to the logged area , the same result...
The headers dont give me more details.
Then,
I check it with google chrome. I open the developers toolbar.
I load the login page.
At the headers on the response headers I get
Set-Cookie: JSESSIONID=434434..... HttpOnly
So, its fine (I guess).
Then I reload the page (or sign in).
Then the problem:
No response headers received.
The Request Headers brings my cookie (with the same ID at then the previous one) without the httponly, host info or any other cookie value I set before.
At the cookies tab I get Request Cookies only and no Response cookie.
And the request cookie is non http-only
At my resources tab, the Cookie is there, as HTTP only and with the previous values I set.
My question now is... Is it a really http-only cookie? Or my configuration is not properly set?
Should I always get the response cookie or the request cookie should be always http-only (In case I am trying to set it as http-only) or is this behavior normal (or at least accepted) ?
When I try to print my cookie with Javascript at both scenarios I get a null as response (what makes me think then it is correct).
Ideas?
Client doesn't send cookie attributes other than name and value back to server.
See also RFC6265 section 4.2.2 (emphasis mine).
4.2.2. Semantics
Each cookie-pair represents a cookie stored by the user agent. The
cookie-pair contains the cookie-name and cookie-value the user agent
received in the Set-Cookie header.
Notice that the cookie attributes are not returned. In particular,
the server cannot determine from the Cookie header alone when a
cookie will expire, for which hosts the cookie is valid, for which
paths the cookie is valid, or whether the cookie was set with the
Secure or HttpOnly attributes.
Everything's behaving as specified.
Since session and cookies are both used to store temporary data, what is the difference between them?
As for may knowledge:
If you set the variable to "cookies", then your users will not have to log in each time they enter your community.
The cookie will stay in place within the user’s browser until it is deleted by the user.
But Sessions are popularly used, as the there is a chance of your cookies getting blocked if the user browser security setting is set high.
If you set the variable to "sessions", then user activity will be tracked using browser sessions, and your users will have to log in each time they re-open their browser. Additionally, if you are using the "sessions" variable, you need to secure the "sessions" directory, either by placing it above the web root or by requesting that your web host make it a non-browsable directory.
The Key difference would be cookies are stored in your hard disk whereas a session aren't stored in your hard disk. Sessions are basically like tokens, which are generated at authentication. A session is available as long as the browser is opened.
hope following links will further clarifying your doubts
http://wiki.answers.com/Q/What_is_the_difference_between_session_and_cookies
http://www.allinterview.com/showanswers/74177.html
Cookies store a user's data on their computer.
Session implementations store a user's temporary data on a server (or multiple servers, depending on the configuration).
In each HTTP response, the server has the opportunity to add a header Set-Cookie: {cookie-name}={cookie-data}; {cookie-options}.
The browser will, in every subsequent HTTP request (or as specified by the options), add a header Cookie: {cookie-name}={cookie-data}.
Request #1:
POST /auth/login HTTP/1.1
Host: www.example.com
username=Justice&password=pass1234
Response #1:
HTTP/1.1 307 Temporary Redirect
Set-Cookie: user_id=928
Location: http://www.example.com/dashboard
Request #2:
GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: user_id=928
Response #2:
HTTP/1.1 200 OK
Content-Type: text/html
<html>
<head>...</head>
<body>...</body>
</html>
All future requests will also include the Cookie header.
Cookies are stored on the client as either small text files on the files system (persistent cookies) or in the browsers memory (non-persistent cookies) and passed to the server and returned to the client with each request and response. Persistent cookies will still be available between browser sessions as long as the expiry date has not passed. Non-persistent cookies will be lost once the browser is closed.
Session is stored on the server in memory. Cookies are very often used as a way of preserving the reference to the users session between requests however this can also be done with querystring parameters if cookies are disabled on a clients browser.
A cookie is client side a session is server side
Sessions are stored server side. You can have inproc sessions, which will be stored in memory, or you can store the sessions in an SQL database. You can read more here.
Cookies are stored on the client's computer. This means that it's not recommended to store important details in a cookie, because clients could easily manipulate them.
Cookies are a small text file stored on the client that can hold domain specific information,
a session is held server side in either memory, a database or a seperate server and keyed via a session key, they are meant only to persist for a 'session' where as a cookie can persist for a length of time or indefinately therefore being usable in multiple sessions.
They are not the same thing. A Session is a concept whereby the state of a single user's browsing session is stored.
Cookies are a good means of implementing this concept, thus the widespread practice of "Session cookies".
The main difference between data stored in session and cookies is that data stored in session is stored on the server side (user can't operate on such data), while cookies are stored on a client side. They might be manipulated somehow by user. If you have a really sensitive data - then store it in session. But all other data you can store in cookies not to overload the server.