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.
Related
My web application's authentication mechanism currently is quite simple.
When a user logs in, the website sends back a session cookie which is stored (using localStorage) on the user's browser.
However, this cookie can too easily be stolen and used to replay the session from another machine. I notice that other sites, like Gmail for example, have much stronger mechanisms in place to ensure that just copying a cookie won't allow you access to that session.
What are these mechanisms and are there ways for small companies or single developers to use them as well?
We ran into a similar issue. How do you store client-side data securely?
We ended up going with HttpOnly cookie that contains a UUID and an additional copy of that UUID (stored in localStorage). Every request, the user has to send both the UUID and the cookie back to the server, and the server will verify that the UUID match. I think this is how OWASP's double submit cookie works.
Essentially, the attacker needs to access the cookie and localStorage.
Here are a few ideas:
Always use https - and https only cookies.
Save the cookie in a storage system (nosql/cache system/db) and set it a TTL(expiry).
Never save the cookie as received into the storage but add salt and hash it before you save or check it just like you would with a password.
Always clean up expired sessions from the store.
Save issuing IP and IP2Location area. So you can check if the IP changes.
Exclusive session, one user one session.
Session collision detected (another ip) kick user and for next login request 2 way authentication, for instance send an SMS to a registered phone number so he can enter it in the login.
Under no circumstances load untrusted libraries. Better yet host all the libraries you use on your own server/cdn.
Check to not have injection vulnerabilities. Things like profiles or generally things that post back to the user what he entered in one way or another must be heavily sanitized, as they are a prime vector of compromise. Same goes for data sent to the server via anything: cookies,get,post,headers everything you may or may not use from the client must be sanitized.
Should I mention SQLInjections?
Double session either using a url session or storing an encrypted session id in the local store are nice and all but they ultimately are useless as both are accessible for a malicious code that is already included in your site like say a library loaded from a domain that that has been highjacked in one way or another(dns poison, complomised server, proxies, interceptors etc...). The effort is valiant but ultimately futile.
There are a few other options that further increase the difficulty of fetching and effectively using a session. For instance You could reissue session id's very frequently say reissue a session id if it is older then 1 minute even if you keep the user logged in he gets a new session id so a possible attacker has just 1 minute to do something with a highjacked session id.
Even if you apply all of these there is no guarantee that your session won't be highjacked one way or the other, you just make it incredibly hard to do so to the point of being impractical, but make no mistake making it 100% secure will be impossible.
There are loads of other security features you need to consider at server level like execution isolation, data isolation etc. This is a very large discussion. Security is not something you apply to a system it must be how the system is built from ground up!
Make sure you're absolutely not vulnerable to XSS attacks. Everything below is useless if you are!
Apparently, you mix two things: LocalStorage and Cookies.
They are absolutely two different storage mechanisms:
Cookies are a string of data, that is sent with every single request sent to your server. Cookies are sent as HTTP headers and can be read using JavaScript if HttpOnly is not set.
LocalStorage, on the other hand, is a key/value storage mechanism that is offered by the browser. The data is stored there, locally on the browser, and it's not sent anywhere. The only way to access this is using JavaScript.
Now I will assume you use a token (maybe JWT?) to authenticate users.
If you store your token in LocalStorage, then just make sure when you send it along to your server, send it as an HTTP header, and you'll be all done, you won't be vulnerable to anything virtually. This kind of storage/authentication technique is very good for Single-page applications (VueJS, ReactJS, etc.)
However, if you use cookies to store the token, then there comes the problem: while token can not be stolen by other websites, it can be used by them. This is called Cross-Site Request Forgery. (CSRF)
This kind of an attack basically works by adding something like:
<img src="https://yourdomain.com/account/delete">
When your browser loads their page, it'll attempt to load the image, and it'll send the authentication cookie along, too, and eventually, it'll delete the user's account.
Now there is an awesome CSRF prevention cheat sheet that lists possible ways to get around that kind of attacks.
One really good way is to use Synchronizer token method. It basically works by generating a token server-side, and then adding it as a hidden field to a form you're trying to secure. Then when the form is submitted, you simply verify that token before applying changes. This technique works well for websites that use templating engines with simple forms. (not AJAX)
The HttpOnly flag adds more security to cookies, too.
You can use 2 Step Authentication via phone number or email. Steam is also a good example. Every time you log in from a new computer, either you'll have to mark it as a "Safe Computer" or verify using Phone Number/Email.
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)
We are using WSO2 IS as our enterprise identity platform. One of our tenants must restrict the number of concurrent sessions per user for security reasons.
The expected behaviour is the following: when a user logs in, if he/she already has logged in previously and the session is still valid, the new session must overwrite the previous one, so the login ends ok and he/she gets logged out from the first device/browser. Summing up: the new session always invalidates the old one.
I've been researching sites like this or http://soasecurity.org/ searching for answers, but I couldn't find any.
I think that I need to store the WSO2 IS session id (the one that comes in the commonauthId cookie and gets stored in session cache/persistence store) in the user store, so I can check what's the current user session and log out the user if the cookie id and the store id don't match. But there are two main concerns:
Where do I store the user session id? My main user store is LDAP, but I'd like to avoid one extra attribute there, because it's shared with many other applications and promote changes like this could be difficult for many reasons. Is there any way to put this data into a secondary store?
What's the most appropiate extension point in WSO2 IS to add code for storing the session id in a user store? I've been looking through the authentication framework and found that the method concludeFlow in DefaultAuthenticationRequestHandler class is where new sessions are created when there isn't a previously cached one available. It seems a bit "tricky" to extend that method, but I couldn't find a better solution. Maybe you can customize the authenticator or the user store, but I think that's not a good point of extension inside the authentication flow, because the new sessions are created later, in the request handler.
Thanks in advance.
The WSO2 identity server actually doesn't care about the number of open sessions. IMHO the identity server is not the best enforcement point where to check for the open sessions. Once the user is already logged in, you don't have much control over the framework and the user assertions (or an Oauth token) are returned.
Where do I store the user session id?
If you enable the session persistence, the session information (user session, saml SP sessions, ...) are stored in the database. However - it is intended for internal use. If the user logs out or closes the browser, the records may be still there. There's no information about the user web session.
Just a hint - we've used a VPN proxy (Juniper SA as SP) and WSO2IS as IdP to enforce a unique user session (for a new session the old one is invalidated).
Have fun
I have this one question in mind that in login sessions does client have to maintain anything so that server uniquely identify client and in multiple client requests response to correct client. I don't understand this sessions and cookies. I asked many about this some say that its server job to maintain sessions and client just send normal request.
Yes, the client must keep track of something, called a session ID. Most commonly, it is a cookie. However, a less used approach is to rewrite all links to pass the session ID in the URL.
Example ID names are ASP.NET_SessionId and PHPSESSID.
Matthew's answer is correct.
It is the server's job to keep track of login sessions, and it's the client web browser's job to keep track of cookies. When you provide username & password on a site, a cookie is provided by the web server to your browser, which will automatically be provided along with subsequent requests to the web server. This cookie uniquely identifies a session which belongs to a particular user on the site (even the "guest" user). So, the server keeps track of all client sessions, and each client remembers its session cookie & provides it along with all its requests. It's a simple scheme. Using Firebug for example, you can see what the web requests look like when you log into a site. You might find that interesting to look at.
It is the server which will maintain the sessions. And it is the server responsibilty to allow session tracking happen. Clients need not bother about sending any information explicitly. As Cliens also sends Cookies saved on the client along with every request, server might use Cookies for sesssion tracking.
Note: Cookies are just one of the way to implement Session Tracking. It is also the best way
So server Cookies as one of the ways to handle session tracking.
It can also be done in other ways:
URL rewriting - the application/server should append the session id in all URL's/Links. When those are invoked from the client the session comes to the server along with the URL.
Hidden Form Fields - The forms may contain hidden input type with session id as field value. When the form is posted, the session id comes along with the form data.
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.