In my application the value for cookie for one user is getting overridden by another user's cookie value.
For example, User A logs in, when I print the cookie value in log it gives me User A cookie value.
But, once User B logs in I am getting same values for both the user A & B in the log.
Interesting thing is there are some token values which I am extracting from cookie and storing it in client variable. The client contains correct value for the respective users.
Tried writing the cookie values to the application log to verify.
writeLog(text="DEBUG: User Cokkie Details - { COOKIE : " & cookie.toString() & "}", application=true);
It looks pretty straight forward, but could I be writing it wrong?
Not an expert regarding the subject of matter, any help/suggestion is appreciated.
FYI : I recently started observing this issue, but no code change has been done in quite a time. Application uses CF2018 version.
Related
I am just playing around with google app engine, webapp2, and python; I am just building a small toy app for fun. A small side note, using ndb for google app engine datastore.
With building a small webapp, comes sessions.
I was reading the webapp2 documentation on sessions, as well as the most popular threads on this website on how to setup sessions. What I don't get about this process is this small piece of code in the config.
config = {}
config['webapp2_extras.sessions'] = {
'secret_key': 'my-super-secret-key',
}
I am pretty new to web development. However, building other smaller apps with this same framework, I done the following to build somewhat secured hashed cookies.
user_key = user_key.id()
user_cookie = self.request.cookies.get('user_cookie', None)
and
self.response.headers.add_header('Set-Cookie','user=%s|%s' % (user_cookie, hash_string(user_cookie)))
self.write('Thank you for sigining up! And, welcome %s' % user.name)
Is that what the first bit of code above for the config is trying to accomplish?
In other words what is this secret key for?
Also, lets say I want to set the 'sessions' cookie to the user id.
Would the code below be the correct way to do this?
self.session[name] = user_key.id()
session_info = self.session.get(name)
Thank you.
The secret_key is used by the server to digitally sign the cookie data that you are reading when you are calling self.request.cookies.get('user_cookie', None).
The cookies are continually passed from client to server along with the digital signature. When the client presents the cookie values to the server with each request it does so with the digital signature given by the server. Each time the server signs the current cookie values, if the signature passed in by the client does not match the current server values the server knows the parameters of the cookie have been tampered with. This guards against a malicious client trying to impersonate another user or otherwise perform an unauthorised action.
This scheme only works if the key is only known to the server, otherwise any client could also sign cookies that the server would accept. Hence secret_key.
The default signature algorithm in webapp2 is HMAC-SHA1.
Also, quickly, when I look at the cookie set by instantiating sessions, it is an extremely long string
This is the code that the server uses to authenticate a cookie if you are curious. You'll notice that the cookie is base64 encoded json document.
Now I suppose that the value of secret_key can then be any string that you'd like it to be, correct?
As they spell out from RFC 2104 on this security thread any string of 20 or more randomly chosen bytes should do for HMAC-SHA1.
Also, lets say I want to set the 'sessions' cookie to the user id
I think this is probably the example you are looking for.
I was reading up on cookie validation and came across the question of how exactly does Django validates its cookie?
If I remember correctly, Django stores session id in the cookie for later use. Does that mean that anyone who fakes the cookie will be able to use arbitrary session data?
The validation itself is damn simple: against the data in in the session backend. As you can see here, the data you receive in a cookie comes from your session, session_key attribute. Where it is being stored depends on your session backend, by default it's the database.
It is impossible to "fake" a cookie. Unless someone stole your SECRET_KEY. More detailed info here.
If someone steals a cookie from a client, the thief can use the client's session till it expires. You cannot prevent it. If you are aware of such a case, the client's password needs to be changed ASAP, as it will lead to invalidation of ther user's existing sessions (starting from Django 1.10).
Upd: your question made me curious whether the session backend actually stores the value as is... Figures, it does. (I got also impressed there's pgAdmin for Windows)
I'm implementing a login system very similar to that of Stack Overflow in one of my websites.
When we login to Stack Overflow, it creates a cookie named usr with some value.
If I delete this cookie, I will be logged out...
So, all that I can think is that it uses something like sessions, but in the database, to record the user sessions.
Is this right? Is it secure?
It's much like any other properly built login/session system. When you log in, the SO system generates a pseudo-random string to identify you uniquely - the session ID, which gets sent out via a cookie. When you return, the cookie is sent back to SO.
SO then takes the value in the cookie, looks up in its session system (could be flat files, could be a database, you just can't tell), finds the session represented by that session ID, and loads it up to process the request.
Deleting the cookie severs the link between you and the site - on your next visit, the session cookie (which you deleted) isn't sent, so SO has no way of identifying you, so it assumes a brand new user, and doesn't show you any of the "logged in" portions of the site.
I'm having trouble with cookies on my site's registration form.
When a user creates an account, PHP sets one cookie with their user id, and one cookie with a hash containing their user agent and a few other things. Both of these cookies are set to expire in an hour.
This is the code that sets the cookie after creating your account
$registerHash = hash( "sha512", $_SERVER['HTTP_USER_AGENT'] . $_SERVER['HTTP_HOST'] . $_SERVER['DOCUMENT_ROOT'] );
setcookie("register_user_id", $newUserID, time() + 7200, "/");
setcookie("register_hash", $registerHash, time() + 7200, "/");
The next page is a confirmation page which sends an email and then optionally lets the user go on to fill out more account information. If the user goes on to fill out more, it uses the cookie to know what account to save it to. It works correctly in Firefox and IE, but in Chrome the cookie is forgotten as soon as you go to the next page. The cookie simply doesn't exist.
You can see the problem here:
http://crewinyourcode.com/register/paid/
If you use Chrome, you will get a registration timeout error as soon as you try to advance past the confirmation page. However on Firefox it works fine.
It turns out this actually was a problem of the files being in different directories, despite my cookie being set for "/", and it was forgetting across multiple. I solved it by moving all the files into the same place.
I wanted to know the interactions of a browser (i.e. Firefox ) and a website.
When I submit my user name and password to the login form, what happens?
I think that website sends me some cookies and authorizes me by checking those cookies.
Is there a standard structure for cookies?
Update:
Also, how I can see the cookies of specific URL sent to my browser if I want to use that cookie?
Understanding Cookies
Cookies are given to a browser by the server. The browser reveals the cookies as applicable only to the domain that provided the cookie in the first place.
The data in the cookie allows the server to continue a conversation, so to speak. Without the cookie, the server considers the browser a first-time visitor.
Have a look at these to know about browser cookies
Understanding Browser cookies
http://internet-security.suite101.com/article.cfm/understanding_computer_browser_cookies
http://www.willmaster.com/library/cookies/understanding-cookies.php
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-22_11-6063884.html
Explanation via Pictures
Simple Explanation by Analogy (via a story)
Freddie works at the Government Taxation Office (IRS/HMRC/ATO/CBDT etc). He deals with millions of people who come to see him everyday. And he has a very poor memory.
In a World Without Cookies:
One day a customer walks in to Freddie's customer care desk:
Customer 1: "Good morning Freddie, so did you change my address like I asked you to?"
Freddie: "I'm sorry. I don't remember who you are? Who are you?"
Customer 1: "Dude, I spoke to you last Monday regarding this issue! How could you forget!"
Unfortunately, the HTTP protocol is stateless. There is no way Freddie (the server) can identify different customers (clients) apart from each other. He doesn't remember. He has a very short memory. There is a solution though:
The World WITH Coookies:
The customer walks in to see Freddie (his name is Brian), but this time, the customer gives Freddie his taxation office ID card:
Brian May: "Good morning Freddie, My name is Brian May...so did you change my address like I asked you to?"
Freddie: "ah yes...hmmm......Brian May, Queen, Lead Guitarist, We Will Rock you......very interesting, I have your records here on my back end system.........let me bring up the records pertaining to your address........YES: I did in fact change your address. BTW since you gave me your ID that's all I need, you don't need to tell me your name is Brian May. Just give me your ID and I will be able to see that on my system".
Explanation of Analogy
You can think of a cookie as kinda like an ID card: if you identify yourself to the server, the server will remember who you are and will treat you accordingly:
e.g. it will remember what you've already ordered in your cart so far.
it will remember that you like reading your website in Tamil / Cantonese / Swahili etc.
it can (basically) identify who you are.
In this particular case, it is the Government Taxation Office who issues out the ID cards.
Granted the analogy is a little strained and very simplified but hopefully, it will help you understand and remember the underlying concept.
Usually the cookie contains a session id number. The id number is then connected to session data that is stored on the server. The usual process is then:
Send login form
Server checks username and password
If correct, the username is stored in a session file on the server, along with various other useful information about the user (if it's a site admin, moderator, userid and so on).
The server sends back a cookie containing an id number that identifies the session file
The browser sends the cookie with each request to that server, so the server can open the session file and read the saved data.
Usually the password is not sent more than once (at login in step 1).
It depends, because there are many scenarios and abilities of usage of cookies.
One of scenarios is:
User submits login form.
Website authorizes the user and set cookie visible in website domain with user name, password (i.e. MD5 hashed) and sometimes other information.
Cookie is sent with each request, which allows website to check if request is came from the authorized user.
For more details read Wikipedia article about cookies.
After logging , the request to server is sent. At server side, it checks the visitor's identification against an ID that identifies whether it is a new user or the older one.
If it determines it a new visitor,it then creates a cookie for it and sends it back in its response to browser. Cookie that is generated in response to Server has a name and unique identification is sent back to a user end. AT the user end ,after every visit to the same URL, browser rechecks cookie list and if it has the cookie for the same url , it is sent to server which identifies cookie ID and server shows the related history for this user then .
Cookies are small data packets that the Web Pages load on to the browser for various purposes.
Every time you re-visit a URL, the browser sends back a tiny package of this information back to the server which detects that you've returned to the page.
Cookies are the reasons that keeps you logged into sites so that you don't have to enter ID and password every time you visit the website.
Webmasters can use these cookies for monitoring the activity of Internet users.
Some sites use third-party cookie to track your Web habits for marketing purposes.
I found some information at this site that was really helpful to me and figure it might be of use: Webfundamentals - Cookies. It goes through what a cookie is, how they work, and the headers that are used to send them.
It says in summary that, cookies are pieces of information that are sent in HTTP requests inside the 'Set-Cookie' header from the server to the client/browser, or in the 'cookie' header in the client/browser to the server.
HTTP is stateless, meaning that one request to another has no knowledge of the state of the page you are browsing. Cookies were made to help address this issue, allowing users be 'known' by the site for as long as the cookie is set to be stored. By default cookies are stored until the client is closed, unless specified otherwise.