I want to run session_regenerate_id() on login to prevent fixation attacks. My problem is that by the time I handle the login form, some output has already been outputted to the user, so session_regenerate_id() doesn't quite work because it's too late to set the user's cookies.
What I was thinking about doing is setting a session variable, say regenerate_session_id, and checking it on the next page load. This would result in the session id not being regenerated on login, but rather the next page.
I don't think this would present any issues, specifically security wise, but was wondering if anyone sees any potential problems.
Thanks,
Shawn
session_regenerate_id not quite on login
Moderator: General Moderators
-
shawngoldw
- Forum Contributor
- Posts: 212
- Joined: Mon Apr 05, 2010 3:38 pm
Re: session_regenerate_id not quite on login
Well, there would be a window of opportunity where a fixation attack would still work. You can almost completely mitigate it by issuing a browser redirect on login, but still not 100%.
For 100%, you'll need to fix that login script. Try the output buffering functions.
For 100%, you'll need to fix that login script. Try the output buffering functions.
-
shawngoldw
- Forum Contributor
- Posts: 212
- Joined: Mon Apr 05, 2010 3:38 pm
Re: session_regenerate_id not quite on login
Right now I regenerate on successful login, which gets validated after things have been printed to screen, this is by design and will not change unless there is a security hole so output buffer isn't going to help.
What about if I regenerate even if the login fails? I could set it up to regenerate on login submission, whether it is successful or not. That should fix the problem, right?
Shawn
What about if I regenerate even if the login fails? I could set it up to regenerate on login submission, whether it is successful or not. That should fix the problem, right?
Shawn