I'm creating josi, a web framework for node.js. And I'd like to add session storage. What would be the best way to implement this? I'm assuming it probably has to be cookie based, but I'm interested in knowing if any other frameworks have a different approach.
I had a look at josi a few days ago. Very nice work!
Other than cookie based, you could use infamous session tokens (e.g. JSESSIONID, PHPSESSID and ASPSESSIONID) and put them in hidden forms or the URL query string.
Cookies are really the best option. They work perfectly for the job.
You always need to reference the server session somehow, cookies are the de-facto standard for this sort of stuff.
How the session is stored on the server side is usually up to you... I really like PHP's approach with session_start(); which does all the session storage and cookies setting for you.
PHP for example stores the session data in a file, making it cross-platform (all platform's have disk storage APIs). Other session mechanisms use a relational-database like MySQL, but that's not really cross-platform unless you want to target those type of users.
Related
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
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
We are using Asp.net Session in our application for state management. By default, In-proc mode is being used. But now, we have to look for an alternative as we have been asked to remove Session from our application by our client due to performance issue.
One of the way is to keep everything at Client side say in hidden field on Postback. It's not a good approach for sure.
Is there any other way of doing it? Im sure there would be an alternative.
PS: Please don't suggest Querystring.
Thanks,
Sumit
Something close to that is HttpContext.Current.Items but has a shorter life span
Items collections of HttpContext is and IDictionary key-value
collections and that are shared across a single HTTPRequest. Yes,
HttpContext.Current.Items valid for a single HTTPRequest. Once
after processing, server information is sent back to the browser,
the variables that were set in the Items[] collection will lost. Where
as for Session Variable, information valid for multiple request as
this is user specific. The session variable only expires either on
Session Time Out or explicitly clear the values.
More from these articles
When we can use HttpContext.Current.Items to stores data in ASP.NET
Recently I was asked to add an XML API to one of the Symfony modules in my project. I did it, and it works well. For authentication, we use sfGuardPlugin. Symfony version is 1.3.11. Using Propel, not Doctrine.
The most recent request to me is this:
We will embed a Flash game into the website.
The Flash will do requests to the XML API.
The guy who is coding the Flash application says that it doesn't share cookies with the browser.
We want the Flash to be able to reuse the session of the currently logged in user (we won't allow to be even shown if no user is logged in).
I did try this would-be solution: (taken from other SO articles and various Google search results)
I was told that the Symfony session resides in the symfony cookie.
I was told that if I copy this value in another client (in my case, wget) and do session_id("stolen_session_id") I will be able to duplicate the session, have the same user logged in, etc.
This turned out to be wrong. Say my cookie symfony had the "blabla" value. I did this: wget --post-data='session_id=blabla' X.X.X.X:NN/api/bla.xml -O-. My server PHP code parses this POST parameter and feeds it to session_id function. It then reported in the logs that the session_id('blabla') was returning 1. However, calling $this->getUser()->getGuardUser() returns null.
I need a way to map a passed session_id to a valid sfGuardUser. Or find an alternative way of reusing a session which already exists.
Suppose I have full access to the cookies. I want to know which one of them (or all of them?) to duplicate in order to achieve this.
BTW, I am seeing in my Chrome dev tools that the symfony cookie is of a session type. So it's no wonder at all as to why my method doesn't work, but I am little lost as to how do I do this in Symfony, while using the sfGuardPlugin.
I do realize this is not one of the most informed questions, but ditto, I just need help.
Thanks for your time.
(Dimitar P.)
Oops, forgot to mention which cookies I see on my domain:
symfony
sfRemember
__utma
__utmb
__utmc
__utmz
I am guessing the last four are for Google Analytics, though.
I didn't want to do this, but I was unable to find other alternatives:
$ wget --header='Cookie: symfony=blabla' X.X.X.X:NN/api/bla.xml -O-
I wanted my XML API to be REST, but evidently, Symfony doesn't allow authenticated requests other way than using cookies (and to enable the session ID to be always included in the URL is not an option at all).
Still, if somebody shows up with a fully REST alternative, I will upvote his/her answer.
You will need some way of specifying which user is executing the (wget) request. And PHP sessions use a session ID by default.
A common way to do this is token-based authentication. The most common way to achieve this is OAuth, which has a lot of default libraries (both for Symfony and for your API consumers).
If you're the only one using this API, you can also create a custom token (random sha1 string) per user per session (you can store this somewhere in your database). Now you would create something like ` wget X.X.X.X:NN/api/bla.xml?token=asdfhdsfhf
Ok, I'm new to web development, so I might be getting some of these terms wrong. I apologize in advance.
I am having trouble understanding the different elements of authentication. Every method seems to be advised against by someone, though not always with clear reasons. I am building a web app for a company that will have access to a database, so I would like to make sure it is secure.
So the there are three places I have seen commonly used to store information.
FormsAuthentication.SetAuthCookie(). This stores a session cookie that will exprire with the browser, and nothing sensitive is on the client. However, it can only store one value. This stackoverflow answer shows a method of storing multiple values here, but the guy who gives it says not to use it, though not why.
FormsAuthenticationTicket. I don't know where this information is stored, but it allows for a simple method of storing multiple values. Securing it, according to the documentation requires calling Encrpty() to store, and decrypt() to retrieve. This seems wasteful, but what do I know.
Session["SomeRef"] = new CustomObject(). The second answer in this question explains how to do this, but a comment to it calls it dangerous because it can be stolen. This looks like the best method to me, because the information is still stored on the server, and can store multiple values.
I cannot find any comparisons for these methods, or good explanations on the "best practice" way of storing multiple pieces of information after authenticating a user. The information is just the User's name and their userId.
Here is some further clarification to help you decide.
SetAuthCookie can be implemented in a way to store multiple values. In practice, however, you usually can't store enough to avoid a database lookup. It's best to store the user name (unique identifier) and load more information during the request. As your question suggests, you shouldn't store sensitive information on it. You should assume that all information sent in a cookie can be decrypted and read and you should take precautions that that information can't be used maliciously. All session cookies can be stolen and I'll explain why in a moment.
FormsAuthenticationTicket is the same API as SetAuthCookie but at a lower level in the Framework. With SetAuthCookie, Encrypt() and Decrypt() should be happening anyway (it's the default configuration.) It's not wasteful but use method 1 instead because it's easier.
Session has some limitations. Notably, by default it's process-dependent. That means that when the server restarts or more than one web server is involved, your session is lost and you have to authenticate again. It is the easiest to use and fastest when using the default memory session storage (InProc). You can use sql storage or a dedicated session server to overcome the process-dependency.
All three methods are considered dangerous for the same reason all cookie-based authentication systems are dangerous: because the cookie's value can be sniffed over wireless and reused to take over a session. This is known as sidejacking and it also applies to scenarios 1 and 2. The way to prevent this is to implement HTTPS. Then, the cookie transimission (and everything else) is encrypted at the network level and can't be stolen.
TLDR; Use SetAuthCookie and HTTPS
NOTE this answer has been edited several times for clarity.