session handler 403 error should be optional

[mark81]

There is a problem in DB session handler. When client IP changes F3 throws 403 error and session is being destroyed. This looks like session hijack prevention, but in mobile scenarios it's causing serious problems. It's very easy to reproduce this error on any F3 website using DB session handler.

Example

Let's say there is a website using DB session handler, follow these steps:

• Init session - open your website on mobile device on 3G (network)
• Connect to WI-FI (or change IP address some other way)
• Refresh website. Session is wiped.

It happens because session handler compares previous IP with current IP, as well as previous USER_AGENT with current one.

I understand in some scenarios this is important for security, but I think there should be a way to configure session security features and make both checks optional.

@bcosca can you liaise on solution?

For now I had to manually change the code in /db/sql/session.php to prevent it, which is not perfect. It's important for my app to preserve session on mobile devices, for given amount of time.

cheers

[ptdev]

I also came across this issue (if we can call it an issue) using the cache based session handler (session.php).

To avoid changing the framework's core files, I've created a custom error handler that detects 403 errors and, in my case, show a "session has expired" type message or redirect to login. This still logs the user out but at least you can define some action to take or message to show after that. It also has the disadvantage that you'll lose all other default errors from f3 so you'll probably also want to add some code to manage or display the other status codes on your handler.

As for your specific case, mobile users are in fact much more likely to have ip changes during the session, so I guess the option to completely disable the ip verification would be the way to go.

Personally, I'd like to see the ability to define some sort of callback (like ONERROR and ONREROUTE) that get's called when csrf protection kicks in. Maybe something to consider for v4.

[mark81]

@ptdev, yes, it is an issue mainly because of mobile users, I would like to avoid writing my own handlers, since F3 already does the job. It would be enough to just make them more flexible in terms of level of security checks.

[bcosca]

Have you considered extending the DB\SQL\Session class instead? It's a lot simpler to override the constructor than go the circuitous route of passing the buck to the error handler.

[mark81]

@bcosca thanks for reply. Yes but the problem is db\sql\session.php constructor calling its own parent::_construct() so its not obvious to overload it.

Another option is to duplicate DB Session handler and invoke it into the project like:

namespace DB\SQL;

class MySession extends Mapper {
    //whole code from db\sql\session.php + your changes
}

Why not to add something like 'SESSION_SECURITY` setting in hive which could control the level of session security checks? This would solve the problem all the way without any hacks.

[KOTRET]

i've taken a look into the class and yes - the security-check should be externalized into its own function to be overwriteable. The hive should not be touched in this case - its a module / extension, not core.

[ptdev]

Agreed, I want to be able to control what happens when csrf kicks in. I believe most people will want to redirect to login and/or show a "session expired" or "session has been terminated" message when that happens. The csrf protection should have a configurable output function.

[mark81]

sounds good @KOTRET. In the meanwhile I just duplicated session handler (copied the whole class) into separate file and just modified security checks.

[ikkez]

you can now set a custom handler for suspicious sessions as 4th parameter

[Rayne]

@ikkez Third parameter for Jig and Mongo.

[ethanpil]

Can we have some sample code and more information in the documentation?

[ikkez]

Alright, I've written it down now. http://fatfreeframework.com/session#onsuspect