67

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)?

Improve this question

5 Answers 5

Reset to default
86

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.

Improve this answer
8
  • 1
    Also note, cookies are stored on the hard drive, leaving far more traces.
    – ewanm89
    Commented Apr 23, 2012 at 21:39
  • 3
    @ewanm89 and urls are stored in browser history (and bookmarks)
    – ratchet freak
    Commented Apr 23, 2012 at 21:51
  • 1
    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.
    – Charles
    Commented Apr 23, 2012 at 22:11
  • 2
    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.
    – rook
    Commented Apr 24, 2012 at 4:03
  • 7
    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.
    – Charles
    Commented Apr 24, 2012 at 4:35
24

Most of the websites store their user's login state into the session, and if an attacker has the session id, he has got the privileges of the logged in user as well. In other words,the two concerns of maintaining the session and authentication are often coupled.

One problem is that, it is easy to make session fixation attacks. In this case an attacker would send a prepared URL with a known session id to the user. If the user clicks this URL and does a login, the attacker would have a session with priviledges. If the website requires a cookie though, then a prepared URL in an email won't be enough.

If a site uses HTTP mixed with HTTPS, the id would be transmitted plaintext in the URL for all HTTP requests (even for an image request). So if the attacker can read a single HTTP request after the user has logged in, he knows the session id.

A way out of the problem would be to separate the two concerns, maintaining the session and authentication. You could then leave the session id unprotected, only for maintaining the session, and use a separate cookie to check for the login state. This cookie must be configured to be sent to HTTPS pages only.

Improve this answer
0
16

In addition to what Charles and Martin have said, putting anything in the URL makes it more likely that it will leak. This can be through a Referer header in a linked resource, from access to the endpoint with browser history records, from brute force history sniffing, inappropriately protected web logs, and so on. So it's generally inadvisable to put anything you want kept secret in a URL/query string.

I've not seen PayPal using server-session IDs in URLs. There's no way it would really be more secure than cookies; the reason it was typically done in the past was to support browsers without cookies enabled. This is less and less a concern these days, and the usability problems of not being to share links, in addition to the session fixation attacks, mean that session-in-URL is usually avoided today.

Improve this answer
2
  • "from brute force history sniffing" how?
    – curiousguy
    Commented Jul 11, 2012 at 17:13
  • Most significantly good old CSS :visited link history sniffing. There have been other history leakage problems (eg timing attacks) but they're much harder to carry out.
    – bobince
    Commented Jul 11, 2012 at 17:42
8

Something I've seen a few years ago was that someone copied a URL (WITH sessionid) into twitter. All followers then had full access to that persons account on that site.

So yes, putting a sessionID in the URL is a bad idea.

Improve this answer
0
-2

Session ID adds to the security when cookies are already used. Imagine if there is a link that transfers money out of your bank:

https://mybank.com/transferMoney?sum=10000&destAccount=someAccount

If you rely on cookies alone, then this link can be given to you in a scamming email. When you open it and click this link, since you do have a cookie in your browser, it will actually be functional. You will successfully (and unwittingly) transfer money out of your account to someone else's.

If the link were:

https://mybank.com/transferMoney?sum=10000&destAccount=someAccount&sessionId=jow8082345hnfn9234

then malicious scammer could not send you the email like the one above because guessing your current session ID is nearly impossible.

Improve this answer
1
  • 2
    The question is why is it insecure?. You seem to be answering why is it secure?
    – user13695
    Commented Mar 15, 2018 at 8:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .