Is it possible for some hackers (Although it is encrypted in Laravel) to session hijack and pretend themselves as another user for example?
How about the simple ones? for example if I put in logged_in session the value of 1 to have some extra capabilities to users, can they create it themselves by cookie manager or some other browsers addons when it is as simple as one number or boolean?
Thanks
For an attacker in order to access your Session he needs to retrieve the cookie of a user.In this case he can pretend he is the specific user into your application.
But it's not that easy . It would be easier to find some user's information by hacking them personally than trying to penetrate laravel's Session.
Still it's possible.But even if he manages to do this laravel you can take extra precautions to make hacker's access by default very restricted .
From the other side that's why apis should be stateless.Because a hacker can have access to the shared Session between client and api pretty easily and penetrates your System's Session
Related
My question may be answered here, Are sessions needed for python-social-auth, but I feel as if I'd be making assumptions and would like to be positive regarding my understanding (NOTE: I'm not using django, I'm using mongo express react node, I'm guessing django might come with sessions built in or something). I followed this guide https://medium.com/hyphe/token-based-authentication-in-node-6e8731bfd7f2 to add token authentication and user login to my CRUD web app, works great, users are authenticated properly, routes are protected. However, everywhere I read about the fundamentals of session and session management states that "every web application in the world that maintains user data has to deal with sessions" (source: https://nodewebapps.com/2017/06/18/how-do-nodejs-sessions-work/). Currently, my react client uses setInterval to regularly check if the access token will expire soon enough to receive a new one via the refresh token. Is implementing sessions required for my app? If so, what is it that they add that I am missing?
It depends on the type of application.
If the resources being accessed using a token are not user specific, then sessions are not useful.
However, in a scenario where the resources are unique for different users (e.g. one has to sign in, etc), then it's wise to implement both sessions and access tokens.
Remember that tokens can also be saved within a session. Checkout 'express-session' to implement sessions in expressjs.
I am developing a web system in php using the laravel framework, I arrived at the part of authentication of users, where it is not allowed the type of user x access to page y. What is the best way to do this with laravel? I thought about creating a session and saving the id of the user, so every time he accesses a certain controller I check if he has access to the id or not. so I had some doubts.
Is this a good way to perform this authentication?
Is this really safe?
is there any way for the client to change my session?
What would be a better method for authenticating user access?
Laravel provides a very good authentication system out of the box. Even though Hacking is inevitable it provides very good protection and since Laravel is pretty popular framework you don't have to worry about the security part. if there is any security bug, patches will be available almost immediately.
And your second concern can a client can change the session ? the answer is NO, if you code it properly. session resides in the server unlike cookies, so there is no direct way for a user to change the session. if you follow good coding practices you are good to go.
And how do you limit userA from accessing pageB. This is a pretty common feature needed in almost all the applications. As of now Laravel does not provide an out of the box solution for this. but this is pretty simple, you can add a role column to the users table, and check whether user have appropriate permission in each page. Laravel keeps the user object in the session, and it is avilable via the auth() helper or Auth Facade. if you want a little sophisticated solution there is a package out there [entrust][1]. it seems a good choice.
You may want to read about
Authorization
Csrf Protection
Authentication
I hope I have addressed all your concerns
Laravel provides a simple way to authorize action thats purpose built for what you need:
https://laravel.com/docs/5.5/authorization
This is a follow-up question to Is Forms Authentication as described in the Nancy docs susceptible to session hijacking?
I understand now how Nancy Form Authentication works and also the idea behind it, thanks to Steven Robbins' answer.
However, for my application that approach is not sufficient. It must not be possible to gain eternal access for an attacker if he manages to steal the auth cookie once. Thus, I'm currently investigating possibilities to switch to a session-based approach to authentication, so I can invalidate sessions when the user logs out and also after a fixed amount of time.
Nice thing about Nancy, such things can be customized!
My question is, does it make sense to reuse Nancy.FormsAuthentication for that purpose? One solution I have in mind is making the user identifier only temporarily valid. That way I would delete the GUID identifier from the user database when the user logs out, and create a new one everytime a user logs in.
I'm asking because the docs state:
It is also important to know that the identifier should be treated as
permanent for the user that it was generated for and will be reused
across requests and application sessions.
Are there any unwanted side-effects when I ignore that and make the identifier non-permanent?
Yes and no.
If you change it each time the user logs in then you are effectively logging the user out.
You could create a Session / Identity table which allows the same user to login multiple times (assuming that the browser is different) which would allow you to manage the timeout / extending the timeout on each authentication.
That would require no changes to the Forms Auth, you would simply change the IUserMapper to authenticate against your Session / Identity table rather than the user directly.
(hope all that makes sense)
Background story: We run a website with thousands of users and a handful of admins. Some of these admins don't need all-access to the website, so I want to restrict their access by giving them individual permissions.
My plan is to set a Session on user login with the users perimissions, if given any. However, I'm concerned that this might be an unsafe action.
Can a Session be manipulated by a user client side? In this case a regular user could gain access to the admin features if they knew the permission names and set a Session for themselves.
I found some related questions on Stackoverflow, but they didn't give give me enough information on the subject.
You are already providing the login for admins and users so save type of permission they have and give them rights to modify data according that..And as long as your session state is encrypted it is very hard to manipulate on client side.
If you have concern about security of your existing session and cookies here is link to make it secure.
Secure your Session
This is full Article how to make your session and cookies secure...
You can indeed store server variables such as the user-agent, the ip address and so forth (and even JavaScript variables), but they are only good for validating that the persistent cookie data matches the client's new connection. The ip address isn't a good idea except when you know that the client (like you only) isn't going to change on every page load (a la AOL).
Modern web browsers and 3rd party services like LastPass can store login credentials that only require a key press (and sometimes not even that) to send the data to the login form. Persistent cookies are only good for those people who refuse to use what's available otherwise. In the end, persistent, non-session cookies are not really required anymore.
There is no such thing as secure cookie UNLESS it's transmitted over SSL only. It can be mitigated some when using a persistent non-session cookie (like remember me), by doing exactly what you're doing, but not in the same way you're thinking of doing it.
I'm currently making a site using GWT, being hosted on AppEngine. I'm making it with my own logins that I'm making (I know Google provides something with GWT, but I need my own login system), and I've been trying to figure out sessions for quite a while now. I've found a few tutorials, and one of the sites that I was reading is http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
There is a section there on "How to Remember Logins". I know how to get the session ID and store it on the client in a cookie through an RPC call. What I don't understand is, eventually after a day or so, the user comes back and I'm supposed to get the session ID from the cookie and send it back to the server. What am I supposed to do on the server in order to securely evaluate if session ID is still legal, and pull up all the necessary information about the user?
Additional questions:
1. What would make the session ID change?
2. What if the user was on a laptop, and the user went somewhere else. Would he still be able to be securely logged back in without having to type in his login and password again?
Thanks!
~Scott
Similar question: question on GWT, Cookies and webpage directing.
One important thing you should remember: don't rely on cookies alone - transfer the session ID/token in the payload of the request too and compare it with the cookie value on the server side. This will prevent XSRF attacks. That's the sort of thing you should be worried about.
The policy on how to deal with session IDs depends on how seriously you take security in your application and what type of application is it. For example, you can login with the same token on GMail from different IPs - I presume they allowed this because it's common that the user's IP changes over sessions. They did however add a feature that allows you to see from which IPs the user logged in recently. And don't forget about users with dynamic IPs (quite a large number) - if you keep track of tokens and IPs you will basically disallow those users to be kept logged in between sessions.
What am I supposed to do on the server
in order to securely evaluate if
session ID is still legal, and pull up
all the necessary information about
the user?
You should keep track of the session IDs/login pairs in your DB.
What would make the session ID change?
Either it expires or the user tries to log in with a token that is not bound to their IP. You could add your own rules too - like the number of logins, etc. For additional security, you can generate a new session ID/token on every new login/session (the user authenticates with the old token, the server checks that it's valid and sends back the user the new token he/she should use from now on).
To remember logins you need to securely generate a unique session id. Normally, this is placed in a cookie. I would recommend using a framework that does session cookies for you. Getting it wrong can leave your site wide open to abuse. Things to consider include:
Do you need to worry about cookie stealing. The user's IP address should be encoded in the session id, or linked to the session id. Check the IP address on every page access.
Ensure your logins are on encrypted sessions. Otherwise, you expose credentials in plaintext on the network.
How long should sessions last. They should time out after a fixed time limit. This can be hours or days long.
Remember me should be different functionality on a different cookie. It needs to contain something that can be used to indentify the user. Depending on your security requirments it may need to be an encrypted value. This cookie can have a longer timeout.
Answers to your additional questions are.
Nothing on the client side is likely to change the session id. The session id should be regenerated every login.
Depending on how secure the session id is, they may have to login. Secure session cookies often encode the IP address to prevent cookie stealing. If so, the laptop user would need to login again.