Why is passing the session id as url parameter insecure?
I recently followed a discussion, where one person was stating that passing the session id as url parameter is insecure and that cookies should be used instead. The other person said the opposite and argued that Paypal, for example, is passing the session id as url parameter because of security reasons.
Is passing the session id as url parameter really insecure? Why are cookies more secure? What possibilities does an attacker have for both options (cookies and url parameter)?
Is passing the session id as url parameter really insecure?
While it's not inherently insecure, it can be a problem unless the code is very well-designed.
Let's say I visit my favorite forum. It logs me in and appends my session ID to the URL in every request. I find a particularly interesting topic, and copy & paste the URL into an instant message to my friend.
Unless the application has taken steps to ensure that there's some form of validation on the session ID, the friend that clicked that link may inherit my session, and then would be able to do anything I can do, as me.
By storing session identifiers in cookies, you completely eliminate the link sharing problem.
There's a variation on this theme called session fixation, which involves an intentional sharing of a session identifier for malicious purposes. The linked Wikipedia article goes into depth about how this attack works and how it differs from unintentional sharing of the session identifier.
Why are cookies more secure?
Cookies can be more secure here, because they aren't something that normal users can copy & paste, or even view and modify. They're a much safer default.
What possibilities does an attacker have for both options?
Neither of these methods is secure from man-in-the-middle attacks over unencrypted communication. Browser addons, spyware and other client-side nasties can also spy on both methods of storing session identifiers.
In both cases, server-side validation that the client that claims to own a session ID is best practice. What this validation is composed of is up for debate. Keep in mind that users behind corporate proxies may hop between IP addresses between requests, so locking a session to an IP address may accidentally alienate people. The session fixation article mentions a few other helpful alternatives.
And of course, neither is true if your browser is configured to either not save history/cookies or it's running in a privacy mode. However, that *won't* stop MitM attacks over unencrypted channels, and is only a minor barrier to spyware or malware attached to the browser from spying anyway.
@ratchetfreak depends on other settings, maybe, maybe not, a cookie always lands on disk for at least the session.
@Rook, I prefer constructive feedback to downvotes. I've added a reference to session fixation attacks.
Ok, i just generally disagree with this post. Who cares about regular users modifying it. There are real attacks exposed by passing the cookie around with GET, no one should use this method, this post is just misleading.
You are more than welcome to provide your own answer, if you find mine lacking. I speak from extensive experience in the real world, not just from a purely security-oriented point of view. When supporting applications designed before developers understood the implications of such things, *accidental* session identifier passing was a far more visible, far more troublesome thing than the actual attack vector it presents. Now that it's well-understood to be an attack vector, steps *must* be taken to mitigate it.