Session hijacking is nothing new. Since the invention of cookie-based authentication and session tracking, session hijacking has been a possible, but unlikely avenue of attack. Before wireless internet access was wide-spread, hijacking sessions was more of an art, requiring technical expertise and a bit of patience to accomplish.
A worrying new trend is emerging however: so-called "plug'n'play hacking".
Tool kits for hacking have existed for years, and are often used by "script kiddies" to hack into systems using known exploits, but these tools still require a bit of work to use them.
There is a new tool on the market however in the form of a FireFox plug-in. Once installed, you are two clicks away from hijacking any session you can see, and being able to access an account like the original user.
This is worrying for one reason: anyone can do it.
To understand the problem, we need to separately examine WiFi networks, security thereof, and what session cookies are and how they work.
A WiFi network is a wireless way of creating a network of two or more computers, and are typically used to enable wireless clients to access the internet. They can be found in most cafes, and are often free to use in public areas. Because of this availability, people are starting to use them much like they use their mobile phone (that is, without really considering the security implications).
You may think that if you use public WiFi that uses security that you are safe. You are not.
Encrypted WiFi links only prevent attackers from outside of the WiFi network from seeing your data, they do NOT prevent OTHER users of that WiFi access point from seeing your data! Some wireless access points have the option to prevent one WiFi client from communicating with another, but it is not wise to rely on this function even if it is enabled (whilst it may prevent two computers communicating with each other, it will not prevent an attacker from being able to monitor your communications and decrypt your data sent/received via that access point).
A session cookie is a regular cookie stored by your web browser that contains a unique ID that identifies you to the server you are communicating with.
For example, if you access www.somesitehere.com and log in, it is highly likely that the server creates a session ID, and sends it to your browser to store in a cookie. As you browse the site, the server will request this cookie to get the ID from it, so it knows you are you, and can show you your details, etc...
The security problem occurs because during login you often see https:// and the padlock icon for the duration of the log in (denoting a secure connection), but after that, it goes back to a regular http:// (unsecured) connection. The primary reason for this is that to encrypt and decrypt pages takes some time on the client and the server, and so the capacity of the server to serve lots of clients is reduced. On large sites, this can be significant.
If you are logged into a site, on most pages it will need to check if you are logged in or not. As part of this, the server will request your session cookie. Many developers think that protecting the creation of the session cookie at login is sufficient, but it is not. During your browsing of the site (using http://), every time the server needs to know who you are, this session cookie *is sent back to the server unencrypted*. An attacker is able to look for the session cookie being sent over the network, grab it, copy it to their system, and look like they are you.
The reason this works is because in most cases, the session cookie stores a random ID. During the period you are logged in, the server has a long list of IDs, and asks "who are you?". You send your cookie back, it looks it up in its list of logged in users and their session IDs, finds you, and serves your data. Unfortunately, the server can't track whether it is your computer or an attacker it is talking to, so if the attacker uses your cookie, he can see your session the same as you, and do anything with the account that you can.
In the 1980s and 1990s, business applications and data were largely confined within and protected by a Local Area Network (LAN). The 2000s introduced a significant change. Download this white paper now to learn why the shift to the cloud is changing how companies think about and manage their IT infrastructure. more
Microsoft moved to the cloud in 2014, and, as a result, Office 365 is taking off. Now, Okta customers are connecting to Office 365 in increasing numbers. This eGuide explains why IT departments should plan and deploy solutions around identity and mobility management in concert with their Office 365 roll out to get maximum user adoption. more
For most companies, Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) play a central role in coordinating identity and access management policies. When on-premise applications are integrated to Active Directory or LDAP, users get the best possible experience. That's why Okta's cloud-based identity and access management service provides a highly useful single integration point. more
With more and more businesses adopting Software-as-a-Service (SaaS) applications, enterprise IT is fundamentally changing. This whitepaper presents the eight biggest Identity and Access Management (IAM) challenges associated with adopting and deploying cloud and SaaS applications, and discusses best practices for addressing each of them. more