I have been struggling for the past month on the solution to this.
When the user get's logged in, a session token is created in the DB and stored in the localStorage. This enables me to validate the user (by sneding the sessionID to the server and comparing its value to the value stored on the DB) every time a critical server call is made, but if I copy a particular session ID from the localStorage of any user I can paste on my localStorage and be validated too. This is a very big gap that I need to fill. What is the correct approach to validate the sessionID and avoid someone from copy and pasting it? How to I make the localStorage encoded to the user?
Notes: SessionID is created using JWT,
session token is completely random and created after logging in,
the value gets stored on a column of the user's column and saved on the localStorage
There is not anything you can do to completely protect against something like this. If an attacker has physical access to a machine to be able to copy and paste from local storage, there is nothing you can do to stop them.
There are a few things you can do to slightly mitigate it, but they are more window dressing than anything else, and they usually cause more problems than they solve. One of this is pinning the session to an IP address. If the session begins at one address, and then moves to another address, you can invalidate the session and force the user to re-authenticate. However, this causes many problems with legitimate users as their machine hops across networks. Mobile devices have exacerbated this, but even stationary machines have trouble keeping a steady IP address.
Related
My Setup
I am using React and Django as frontend & backend. For authorization purposes I chose Django-rest-knox, which works via tokens stored in a database.
My Problem
Now if an attacker gets a hold of the token (stored in local storage on the client side after a login), he can do anything that the user is able to. There is some expiration on the token and the ability to destroy all tokens of the user by the user himself. But I'd like to be on the safer side.
My Solution
My idea is to map all tokens to the IP address (of the user) that was used to login. That way the token would only be usable on the machine that was used to login. That token-to-IP-address relation would be checked on the backend.
My Questions
Is the idea feasible at all or is there anything in the nature of those IP addresses that breaks my intent?
What is the best way to get the client IP-address?
Do you think that is a secure approach?
Thanks for the help!
The idea is feasible but not efficient. The main problem is, not everyone using static ip address and this will cause you a big feedback by your users because everytime some user's ip address change(via modem reset, power cut, provider problems etc.) he/she/it will have to be authenticated again.
You use 'HTTP_X_FORWARDED_FOR' meta for almost all backend framework as well as django. you can check this link. How do I get user IP address in django?
This idea may come with security but i ll give you a better one that i am currently using on my own application.
My solution: Refresh tokens. With refresh tokens, every time an access token expire(avarage 15 min ideal) user will request a new access token via his/her/its refresh token. With this way even an attacker get user's access token, he/she/it will be only available for 15 minutes(you can make 5-10-15-... mins as well)
I working on security and I 'm storing a session key inside a cookie. I will use it to check if the user is actually connected and if he didn't tried to change some info.
at first I think to just check if the session key is inside the database, but I think it would be more secured to check if the current user has the session key instead of just finding a user that have that key and assume that he must be the one connected.
I know I should use session storage, but since I'm using AngularJS, I don't know how to achieve that, so no need to point out that I should use session instead.
-Would it be safe to put the username inside the cookie?
-Would just using the session key and assume that the user that got the key most be the connected one be a good idea (it would simplify some of my request to the database later on)?
It sounds like essentially what you are trying to achieve by storing the username in a cookie is to make the username a 2nd factor in a 2-factor authentication scheme. The problem is, the username always travels in a cookie alongside the session id and so when one is exposed, the other is too. So no security is gained.
Furthermore, there is no valid security argument to storing username in a client cookie and then trusting that this username is the same one associated with a session. The client can trivially change the value of the cookie before submitting a request. And any attacker that has already managed to have sniffed out the session id from a cookie could probably just have easily read the username cookie too, making a session hijack attack practically the same difficulty. At best, you've achieved no higher security and added unnecessary complexity to your code. At worst, you've betrayed usernames which wouldn't have otherwise have been visible to an attacker. eg. in the case of expired sessions.
OWASP Recommendation:
Session ID Content (or Value)
The session ID content (or value) must be meaningless to prevent information disclosure attacks, where an attacker is able to decode the contents of the ID and extract details of the user, the session, or the inner workings of the web application.
The session ID must simply be an identifier on the client side, and its value must never include sensitive information (or PII). The meaning and business or application logic associated to the session ID must be stored on the server side, and specifically, in session objects or in a session management database or repository. The stored information can include the client IP address, User-Agent, e-mail, username, user ID, role, privilege level, access rights, language preferences, account ID, current state, last login, session timeouts, and other internal session details. If the session objects and properties contain sensitive information, such as credit card numbers, it is required to duly encrypt and protect the session management repository.
It is recommended to create cryptographically strong session IDs through the usage of cryptographic hash functions such as SHA1 (160 bits).
-- https://www.owasp.org/index.php/Session_Management_Cheat_Sheet#Session_ID_Content_.28or_Value.29
I have an angularjs app that is on a separate domain than my backend, and the users from my backend all have roles and permissions that allow them access to various areas and elements of my frontend.
Before, I was just storing to a cookie and checking as I needed through the use of angular services and whatnot, cool.
Now the permissions datum have reached the point where they are too big to store in a cookie in the browser. And I'm avoiding Localstorage for fear of user tampering.
The Question:
How do I store the users sensitive data (or anything sensitive, really) that are too big for cookies on the client side in a manner that is safe and doesn't require API calls all the time to get?
I don't want to have to phone home every page change to get this data direct from the server when I need it, because I feel this would be really detrimental to the speed and flow of the site, not to mention the frequency at which this would need to happen would be ridiculous for my app.
Keep in mind that I do proper permission checking on the backend before carrying out any actions, but I'm more concerned about users tampering with their permissions to show certain elements that were removed on the frontside before.
What would be your solution or your advice on this?
If it ends up on the user's computer, regardless of whether it's in a cookie, in local storage, in the URL, in the browser's cache, or anywhere else on the user's computer, assume that the user can see it and mess with it. (You could encrypt it, but if your client-side logic knows how to decrypt it, you're back to step one.)
The best that you can do is exactly what you've described - be sure that the server only carries out authorized actions, and never trusts what the user tells it.
I've seen so many plugins which are using Cache to store the results like results from a third part api, and directly taking the
results from the cache instead of sending request to the third party servers again.
1.) But what is the case if the results coming from the server changes from time to time.
2.) Suppose let us assume that we're saving the no.of login attempts made by user into the cache and we'll check this count
for securing the user's account. i.e. if user made 5 wrong login attempts then his/her account will be locked for 5mins and allow
the user to login only after 5mins.
There may be a situation can be happen like this:
Now user has made 3 login attempts from one machine and count will be saved into the cache (cache name will be as username) .
rest 2 login attempts he made from another system and count become 5 then it'll show a message that "you've done 5 incorrect login
attempts, please try after 5mins."
Instead i can use session here to get the best results.
In that case what's the importance of Cache here ?
please tell me, Thanks in Advance.
1) You don't cache results if you rely on changes. There are different APIs, some APIS send an expiration date with the result that can be used to cache the result. Sometimes you simply don't need to get new data with every request, then you cache it. Geolocation is a good example here that can be cached nearly forever.
2) This doesn't make any sense, you can't use session if you try the access an account from multiple devices. Each device will get a new session id. But in this case I would not use a cache engine at all but write it to the users table, the table needs to be queried in any case to get the login data. So it's just a write more for each attempt.
I'm implementing session management and am currently storing 4 types of info in the db:
user_id
session_id (hash)
insertion_time (for timeouts)
persistency (if user
has a persistent cookie)
It is possible for the user to have multiple sessions open with different devices. If the user logs out, how do I know which of those sessions I should delete?
What unique information is usually stored along with the info I've already got? IP address does not really work as it could be shared. Should I store the browser info, but what if it is the same?
You should only use a single session id/hash to recognise a session.
When a user logs in (e.g. with username/password) you will tell them what their session id/hash is.
When a user is browsing, they will tell you their session id/hash for every page load. That's how you know it's an existing logged in user, and not some random new user.
When a user tries to loggout, they will still tell you their session id/hash. You can use that to find and delete the correct single session.
You have to store Last access time Last Modify Time of the Session to calculate the Idle time for Session Timeout.
To Identify the User Session you have to store the browser Id. Browser Id and User Id mapping will lead you to figure it out which session of the User you have to delete.