A look into sessions and security
Part #0: The concept
Index
Part #0: The concept (You’re here!)
Part #1: The setup
Part#2: Storage, Access and Meta Data
Part #3: The Score approach
“Final” Part: Eternal sessions of the clueless user
What exactly is a session? A bit of theory and history.
A session is an identified space where data can be stored and read, therefore making it possible for data to be persisted between web pages.
The web was originally created to be an anonymous architecture. From dynamic IP Addresses to the absence of data storage mechanisms, the “user” was originally a kind of abstract concept: there was no way you could know for sure that the UserA visiting PageX at a given time was the exact same user who was at PageY 5 minutes earlier.
Although great for privacy issues, this anonymity was a hindrance to producing authentication on the web, a crucial step to build systems and applications. In that scenario, the user would be “forced” to authenticate itself at each page of the system, since there was no way to persist it’s identity.
I might be wrong but it’s fair to assume that authentication was the main reason why sessions were created.
How is it possible?
A session is created and identified in the server. The same identification is “transmitted” (usually through a cookie) to the client. It’s basically the fact that both the client and the server match the correct identification that makes possible to “recognize” a user and therefore work on persistent data.
The above figure shows a simplification of the concept. Depending on the language/library/framework you’re working with the process may vary.
So, what’s the problem?
The main security concern with sessions is independent of technology and is actually inherent to the web itself: Since sessions depend on the client to “tell” it’s ID there’s no real way of knowing for sure that the user isn’t trying to hijack a session owned by someone else.
Since the client is part of the concept and is well known by security professionals to be inherently risky (since we have no control over what happens in the client’s machine, we don’t trust it by default), there’s no perfect solution for this.
What we can — and should — do is taking precautions to avoid security issues and that’s what I’ll be discussing in this series.
I will be using Apache 2.4, PHP 7 and PostgreSQL 9.5, but the theory in this series should be universal, since the most important part of an article, in-my-not-so-humble-opinion is the theory.
See you in Part 1!
