In the context of web apps, session hijacking is generally a matter of obtaining and using someone else's session id. Assuming the target isn't going around posting the value of their session cookies on forums, this generally involves either compromising their computer or using one of the internet hosts that their traffic passes through to sniff the session ids from that traffic.
In the first case, there's not really anything you can do about it. If the user's computer has been compromised, then the attacker can access any information available to the user's browser, including doing so in real time if he really wants to. Game over; attacker wins.
The second can be defended against in various ways. Using a cookie for the session id instead of putting it in the URL is the most basic defense and one that I recommend in all cases unless there's a specific reason to expect cookies to be unavailable.
The next level of defense is to record the IP address associated with each session and reject any requests that don't come from that address. Personally, I don't do this because proxies and NAT routers (including any home "broadband router" or cable/DSL modem which supports connecting multiple computers) collapse multiple users into a single IP address and reverse proxies (such as AOL) can cause each request from the same user to come from a different IP address. It's still fairly common, despite those issues.
The ultimate defense is to accept https connections only. The SSL transport encryption will defeat attempts by intervening hosts to sniff the exchanged data and includes its own protection against hijacking of the SSL session. If you're really concerned about attackers getting access to legitimate users' sessions, this is the way to prevent that, but it comes at a cost in CPU utilization, performance when establishing a connection, and money for buying a proper SSL cert from a recognized CA (unless you want your users to get scary "This cert may be forged! Run away!" warnings from their browsers).
