Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I know that when cookies get sent from server to browser with a server language setting them, it happens through http or ssl or https. So where does a javascript cookie go, once the script: “document.cookie=”, is executed in the browser, and through which protocol/transmission scheme?
A browser simply sends all unexpire HTTP cookies (not SSL related!) in its “cookie jar” which match the domain (and possibly path) of the outgoing HTTP request: once in the “cookie jar”, the cookie is sent automatically for all future requests. Cookies sent from the server via the
Set-Cookieheader are automatically added to the “cookie jar”, but, as noted, cookies can also be added from JavaScript*. In both cases the client/browser sends the cookie back to the server via theCookieheader.This is why, like all user input, cookies should be treated with caution and must be backed/verified on each request for “security-sensitive” operations. Generally a session cookie is used that provides this protection by being a form of a nonce as they are (or should be) large cryptographically-sound random numbers that are never reused and are impossible predict.
The session cookie/nonce is then just a look-up into a persistent store (usually database) containing state such as the “user ID”. It is a combination of the separation and nonce characteristics which prevents clients from choosing their own “user ID” based just on the value of a cookie, but…
…”security” is a complex topic, and session cookies do not prevent against all malicious JavaScript, such as that which employs CSRF or similar, and they offer no help against man-in-the-middle attacks or eavesdropping, and are only effective against replay attacks insofar as their expiration time. Another (often overlooked) approach to verify a cookie is to use a tamper-proof verification hash, such as what ASP.NET does with view state.
A server program that blindly used/trusted
LoggedInUserIdorIsAdministratorcookies would be very insecurely designed indeed! 🙂Happy coding.
*All of the most recent browsers support HTTPOnly cookies, which cannot be read/overwritten by JavaScript: they can still be spoofed by other programs, however! (Some browsers only gained support as of late: e.g. Chrome 12, iOS4, Safari 5.)