2

In a class we were told that it's dangerous to put the session key in the URL because it could be cached, either by the browser or a proxy etc. Is this correct? Even if it was cached shouldn't the session key get regenerated each session? I guess it may be a problem with sites that don't log you out after you close the browser. Do I understand the problem correctly?

Also what's the difference between a session key and session value? I use session key to refer to the string stored on a local computer that associates itself with the session the server is aware of for a logged in user.

  • If it's the part of URLs, the session should always be bound to IP address. – Rápli András Apr 3 '16 at 8:13
  • @RápliAndrás I heard that doesn't always work due to proxies and shared IP addresses and dynamic IP addresses. – Celeritas Apr 3 '16 at 9:37
  • 2
    It's not a 100% solution of course, but adds a layer of security. – Rápli András Apr 3 '16 at 9:38
1

Also what's the difference between a session key and session value?

There are basically two ways to maintain information about a session:

  • Put the information into the database and associate these with some unguessable (i.e. random) key. Use this key inside some cookie or similar when communicating with the client. Lookup the information based on this key whenever you need these. In this case you have a session key (cookie) and session value (information in database).
  • Encode all information into some string and protect this session token against manipulation and guessing. In this case you have no value in the database but can extract all information from the token.

.. dangerous to put the session key in the URL because it could be cached, either by the browser or a proxy etc. Is this correct?

Since the session key is often used to identify a logged in user it should be treated like a temporary password, i.e. it should be treated as secret. This means it should be protected with HTTPS against sniffing. This means also that it should not be logged because somebody might get access to the logfiles even without hacking which usually contain the full URL. And it should not be forwarded to a third party, i.e. neither automatically with the HTTP Referer header nor manually by the user when sharing the current URL.

| improve this answer | |
  • It is worth noting that sessions in the URL are not always dangerous. Done correctly they can provide a secure medium to prevent CSRF and users from clicking malicious links. A site I work on has them on the Admin CP for this very reason (they do IP and other checks on each page request, as well as have a relatively short timeout window). – Chase Haddleton Jun 2 '16 at 13:46
0

Answer for Question 2:

Lets first clarify on the terminology.

Session ID's are often used to identify a user that has logged into a website, they can be used by an attacker to hijack the session and obtain potential privileges. A session ID is often a long, randomly generated string to decrease the probability of obtaining a valid one by means of a brute-force search.

Example session id in GET: SESSIONID=AIsdlasdklMVgyfrfksoskeikskZPF63erf

Session [Key,Value]: The user is typically identified by the server using the session ID sent via cookie or through GET/POST parameters. For example,lets take a case where session data on the server are stored in files like sess_AIsdlasdklMVgyfrfksoskeikskZPF63erf.session. This file contains data stored in [Key,Value] pairs for that sessionid.

And on server side Welcome page validation may be like below

session_id( '$_GET['SESSIONID'] );  //Sets session id to the value received via GET parameter i..e session_id('AIsdlasdklMVgyfrfksoskeikskZPF63erf')
$username=$_SESSION['username'] //sets $username to Alice
echo "Welcome".$username;   //Prints "Welcome Alice"

Here username is a Key and Alice is the corresponding value for that key in session variable.

Answer for Question 1:

Yes it is dangerous if the session id is in URL. Also, its similar having your username or password in URL via GET.

Even though the session is for just valid for short period of time (from login to logout/session expiry) , it can be missused if the attacker can get the sessionid while its valid.

Once he gets the session id, he can send spoofed the requests on the users behalf.

In above example if attacker gets the session id of Alice and send requests using it he too will get "Welcome Alice" message.

| improve this answer | |
  • 2
    You shouldn't do session_id( '$_GET['SESSIONID'] );, it opens you up to session fixation. – tim Apr 3 '16 at 9:44
  • @tim Thank you for your comment.I meant to use session_id( '$_GET['SESSIONID'] ); in code only for reading session id and NOT for Generating session id. Please suggest me if you think anything else can be done better. – Sravan Apr 3 '16 at 10:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.