Cookie based AdminCP

[Luke]

I know the reason why the AdminCP isn't cookie based, nor does it share a session from the public side: Security. Someone could use a remote image with an internal/hidden redirect to make an admin perform an action without knowing it.

But the reason why this would be a problem is because the URL is known to the attacker. That is why the session is in the URL: So it's different for every session.

What I would suggest doing:

Make the session cookie based and share it on the public side. Take the session id (32 char hash), md5 salt it (configured as a define()), take the first 8 characters and require it to be in the URL. Then on the public side links to the AdminCP would always contain this 8 character code (otherwise it would require you to login like it does now).

The motivation behind this would be to only have to login once and not only have a generic "AdminCP" link, but also be able to link to related actions from the public side, like "Edit Member". The biggest problem in having to login a second time. By taking the session id from the public side and creating a "security code" out of it you make the URL dynamic (like it is now) to avoid security problems.

A security option that could be added is if an AdminCP link contains an invalid security code (when it is provided) the session could be invalidated (requiring the user to login). In the define salt I could do something like this:

define('ADMINCP_SALT', ((int)(date('i') / 5) * 5) . '$^&FGDid(&%');

This would make the security code expire after 5 minutes. If I were to walk away from the computer with the window open and an active session and someone came by 5 minutes later and tried to access the AdminCP it would invalidate the session if it was still active.

[Charles]

Doing this opens you to XSS and other such malicious attacks. The AdminCP's security isn't something we're going to tinker with :)

[Luke]

Charles I did mention that and proposed a solution to fix that. Did you read that part?