This is an absolute no-brainer for financial institutions of any kind. If you're worried about session hijacking - and you really should be - use a HTTPS protected connection.Regenerate a new cookie with timed expiration, say, every 5 or 10 minutes. Create a background JavaScript process in the browser that sends regular heartbeats to the server.I am inundated with session timeout messages every day from a variety of sources, but I've never once seen a session expiration message from gmail, for example. Is it really so unreasonable to start doing something in your web browser, walk away for an hour - maybe even for a few hours - then come back and expect things to just work?Īs programmers, I think we can do better. Far from it.Īs a user, I can say pretty unequivocally that session expiration sucks. That's the why of browser session timeouts from the programmer's perspective. The best option, short of encrypting the entire connection from end to end via HTTPS, is to keep a tight expiration window on the session cookie, and regenerate them frequently. This is serious stuff, and mitigation strategies are limited.
If that cookie never expires, you have an infinitely long vulnerability window to session hijacking. The magic cookie that stores your session can potentially be stolen. If this data wasn't expired and dumped on some schedule, it would quickly blow up the web server. It's even worse if you think about it in terms of user information cached in memory a measly few kilobytes of memory state per user doesn't sound like much, but multiplied by a few million, it absolutely is.
If the website tried to keep sessions alive for an entire month, that could cause the session table to grow to millions of records. So why does the server choose to arbitrarily forget about you in an hour? If anything, the server has all the information it needs to remember you, even if you walked away from your computer for a week. Still, that doesn't explain why the web server mysteriously forgets about us. For performance reasons, some chunk of session information also ends up in the server's memory there's no need to reach all the way out to the database the next twenty-six times you obsessively refresh your Facebook profile page. This is usually stored in a database of some kind, keyed by your session identifier. It's up to the server to correlate the unique session identifier sent by the browser with your individual identity, context, settings, and preferences. The browser definitely isn't the forgetful party here. While it is possible to maintain state without cookies, it's painful and awkward.Įvery web request to that server will include its own cookie and associated session id until it expires, usually many months or even years hence. While there are privacy concerns with cookies, it is a generally accepted practice today - at least for the first-party cookie flavors. The way modern web applications get around this is by telling the browser to send a small, unique value back to the website with each request - this is known as a HTTP cookie. That means every individual request your browser sends to a web server is a newborn babe, cruelly born into a world that is utterly and completely oblivious to its existence. The HTTP protocol that the web is built on is stateless. I'm not sure either one of these reasons are particularly justifiable.Īs a programmer, I understand why session expiration occurs. I know my bank website zealously logs me out of its web interface if I'm idle for more than five minutes. Most programmers look at these sort of browser session timeouts as a necessary evil - sometimes even as a security "feature".
You have to manually log in again, remember what you were doing, then navigate back to where you were and resume your work. What's worse is that you're usually kicked out of whatever page context you were working in. If you're anything like me, the answer is lots. How many times have you returned to your web browser to be greeted by this unpleasant little notification:
0 kommentar(er)
