In essence, session management ensures that the client currently connected is the same person who originally logged in. Unfortunately however, sessions are an obvious target for a malicious user, because they may be able to get access to a web server without needing to authenticate.
A typical scenario would involve a user logging on to an online service. Once the user is authenticated, the web server presents this user with a "session id." This session ID is stored by the browser and is presented wherever authentication is necessary. This avoids repeating the login/password process over and over. It all happens in the background and is transparent to the user, making the browsing experience much more pleasant in general. Imagine having to enter your username and password every time you browsed to a new page!
The session ID itself is simply a string of characters or numbers. The server remembers that the session ID (SID) was given to the user and allows access when it is presented. As a result, the Session ID is of great value and malicious users have, for years, searched for ways to compromise it and use it to circumvent authentication mechanisms. Session Management is all about protecting this session ID, and in modern day interactive web applications this becomes critical.
So how to get your hands on a Session ID? There are a number of techniques attackers use to compromise a Session ID. The most obvious is to attack the server. The server often stores the session ID somewhere, and more worryingly, the server sometimes stores the session ID in a world-readable location. For example, PHP stores its session variables in the temporary /tmp directory on Unix. This location is world-readable, meaning that any user on that system can easily view the session IDs with basic utilities that are part of the Unix API. This is serious risk, particularly on shared hosts since many users will be active on the system. This issue has since been addressed but it is just one example.
Another method is to attack the client. Microsoft Internet Explorer, for example, has had numerous flaws that allowed web sites to read cookies (often used to store the Session ID) to which they did not belong. Ideally, only the site that created the cookie should have access to it. Unfortunately, this is not always the case, and there are many instances of cookies being accessible to anyone. On top of this, a browser's cache is often accessible to anyone with access to that computer. It may be a hacker who has compromised the computer using some other attack, or a publicly accessible computer in an Internet café or kiosk. Either way, a cookie persistently stored in the browser cache is a tempting target.
Unencrypted transmissions are all too common and allow communication to be observed by an attacker. Unless the HTTPS protocol is used, a Session ID could be intercepted in transit and re-used. In fact, it is possible to mark cookies as 'secure' so they will only be transmitted over HTTPS. This is something I have rarely seen developers do. Such a simple thing can go such a long way.