Passing Session Id via Url

Harm of passing session id as url parameter

1) You should ask whoever designed the application your red box is covering. URL can be anything you want; the convention of key=value&key2=value2 is just that - a convention. In this case, it's Java, and it commonly uses the convention of ;jsessionid=.... for its SID.

2) It's not that big of a deal. Normal users can't copy-paste cookies like they can copy-paste a GET parameter, but power users can do whatever they want (using Mechanize, wget, curl and other non-browser means, or even browser extensions). And if you allow it for some users and disallow for some, it's not really much of a security precaution, is it? Basically, cookie SID will make the attack a bit harder, but it's like putting your front door key under the mat - definitely doesn't keep your door secure. Additionally, cookies are shared between tabs: if a site wants you to be logged in with two accounts at once, you can't do it with cookies.

3) Serverside security, yes. One effective countermeasure is one-time SIDs (each time you visit a page, the server reads the session from the current SID, then starts a new session with a new SID for the next request). A less effective but still good method is to validate other information for consistency (e.g. - still same IP? Still same browser?)

4) Yes, if you know someone's valid SID, and the server does not adequately protect against session fixation, you can "become" that person. This might enable the attacker to, say, pay his bills with your money, for instance.

Session id in url

Thats to support browsers with deactivated cookies / without cookie support. PHP also supports session authentication via URL parameter (with session.use_only_cookies set to 0) instead of a cookie.

To disable it set session.use_trans_sid to 0 with ini_set. You also might wanna set session.use_only_cookies to 1 to be sure PHPSESSID in URL won't be used at all.

is it reasonable to get sessionid from url other than cookie? something about express-session

It is generally not advisable to add the session as a query parameter, you have to jump through lots of hoops to get them to near the same level of security as cookies.

The main problem is that it is much more vulnerable to session fixation or session hijacking, which is where an attacker can steal and use another user's session.

Some key points to take into consideration

• Query parameters are stored in browser history, bookmarks and referrer headers (just to name a few) which
  could allow an attacker to use another users session on a shared
  environment. Query string based sessions are much easier to leak outside their intended scope.
• Cookies have better security mechanisms built in such as the
  httpOnly flag which makes the cookies in-accessible to JavaScript
  (whereas query strings are always accessible). The secure flag makes
  sure that cookies are only sent over a secure connection (You could
  perhaps use HSTS to help guard against MITM attacks for query string).
• A user who share a link with their sessionID in the query string
  which would allow any other user to assume their identity.

If you do decide to use the sessionID in the query string make sure you set an expiration time for the session and always to use TLS to securely transmit the session (same applies to any authentiction method).

Saying that, If you can avoid using query string based sessions, I would advise you do.

How can I send PHPSESSID in the URL?

Using a cookie or not is configured by these PHP options :

• session.use_cookies
• session.use_only_cookies

If the first one is set, cookies will be used if possible.

PHP should detect if cookies are enabled or not, and use them only if they are supported by the client.

To enable passing of the session id by GET instead of cookies, you might have to activate session.use_trans_sid, which is disabled by default (Which means that, by defaut, session id is only passed by cookies -- never by GET).

But note that, with this option activated, PHP will pass the session id by GET at least for the first page each user of your site will come to... as they won't have the cookie at first, and the only way to check if they support cookies is by setting one, and trying to read it back on the next page.

And users that don't support cookies, including search engines I'd probably say, will have that session id -- and that is not nice :-(

And, you might also want to take a look at session.name to set the name of the key (set to to "token" instead of "PHPSESSID", I mean)

For more details, you can take a look at the Session Handling section of the manual :-)

---

Related Topics