Well, for safety i will ask this: I have my table´s "user" and "userright", which have all the informations for my current user. I store the unique id of each user into theyre own session via. session::set('id' => $userid). Now, when i wanna check inside my action for the rights, i wanna get the userid inside the session, look which numeric value inside "userright" permits entry (public function checkUser(), checkAdmin(), etc.pp.) and then decide either to throw an error or permit. Is it safe to assume that nothing bad can happen with this, or is it that some other guy can manipulate the session-id? And if he can, what can i do against it? Always check database?
If you use Fuel's session class, and you use either the cookie driver + encryption, or you use a server-side storage driver ( = all others), and you make sure you haven't disabled session id rotation, you are quite safe against session hijacking as per the latest SANS recommendations.
A hacker can still access your application if you are vulnerable to cross-site scripting, since that will use the valid session of the real owner to inject the hackers own code. So you need to protect your application against that.
As for data input (forms, API), always use a csrf token, and always validate server side. Never trust client side validation (for example javascript before form submission).
When generatiing output, always encode all data (this is the default in Fuel for every View and Presenter) to make sure no javascript or other horrors can be injected via input.
Well, i know that alreay. Just wanted to make sure. I only store general userid, username, his rights and his inside the user-table existing group, so with this, if i wanna check for the rights, i will extend my Controller_Main and call a function, like $this->checkForGuest() or $this->checkForAdmin(), so that he, before he can access the site, will get checked. The only problem, and thats why im a little curiose is, that when someone wants to get the id, he will, at some point, get it, with all means possible.
I am retrieving data via Input::post(), then i take the trim()-function to take all spaces before and after the input so that i can then use filter_var like this:
And im always checking the status. If something is not right it will always throw an exception. Just to make sure nothing irregular happens.
Well, now here comes my last question for this: If i wanna use a "rememberMe" cookie, lets say the normal 60 * 60 * 3600 lasting one, how would i implement the login? I had tried the Auth-package, but it does not suit my site (its waaay more complex, with teams, squad, from a site-admin given right to access different pages and much more, so that if the admin wants to make a more complex system, he has the possiblity to do that (yeah, i know, always validate and sanitize and encode)).
Because if i use a "rememberMe" cookie, i would need to store smth inside it to identify the user. But a userid or username would be way too simple and could easily get hijacked that way. So either i store a temp-session-variable, the duration is exactly the same as the cookie, with a random md5 or sha1-hash to make it unique, then bind it to the userid. Only if the server-side temp-session-variable and the cookie-stored information are identical, i could then identify the user and log him in. Still im sure there are ways to hijack even this. So a little help would be much appreciated.
Fuel's Auth package stores the userid in the remember-me cookie, using a second session instance of type "cookie", with encryption.
The rest doesn't make much sense. No matter how you do it, you need something in the remember-me cookie that uniquely identifies the user. If you can hijack that, you can get in, no matter what that value actually represents.
By why would it be "easy to get hijacked"? Fuel's sessions are secure if implemented correctly.
Well, at second thought you are right. I think i was overthinking. Just forget the question, you helped me already. I just wanted to make sure that Sessions are secure in the way of saving userspecific data.
Donate
