-3

Today I've been questioned in the interview that

If a browser does not support cookies, how can PHP maintain a session?

and the options are....

1. using an MD5 hash of the user's email address as the session identifier


2. using the browser's network address as the session identifier


3. including the session identifier as a parameter every GET and POST request


4. using the "secure cookie" header to force the browser to set a cookie

Can anyone tell me which is accurate and please gives a brief explanation?

Aamir Kalimi
  • 1,821
  • 2
  • 15
  • 19
  • 2
    Which answer do you think it is? Why? – Martin Feb 27 '19 at 08:22
  • I think it's may be 3. using GET and POST. – Aamir Kalimi Feb 27 '19 at 08:24
  • @AamirKalimi Why do you think that? – Martin Feb 27 '19 at 08:24
  • I just want clear explanation. That's set or documentation? – Aamir Kalimi Feb 27 '19 at 08:25
  • 1
    1. would require for a person to first enter the e-mail and then a way to store it between pages - which is usually done using session, so this one won't work. 2. is one way, you store data on the server and identify it by the IP address - but it's not without it's flaws 3. greatly insecure, but would work 4. sounds like a bait answer – JTinkers Feb 27 '19 at 08:25
  • 3
    [Read the docs](http://php.net/manual/en/intro.session.php), quicker and easier than posting here. – Tigger Feb 27 '19 at 08:26
  • 4
    @JCode - Using 2 will open up some very interesting bugs. Specially when there are more than one client from the same network. People will all over sudden start sharing sessions. – M. Eriksson Feb 27 '19 at 08:27
  • 1
    @MagnusEriksson Yes, definitely. It would work thought. Answer 3 could open the exact same bugs if you share your url with someone. – JTinkers Feb 27 '19 at 08:28
  • @JCode - Sure, but that's only if a user shares the session. If you use 2, it will automatically happen for everyone inside the same network which, imho, is way worse. – M. Eriksson Feb 27 '19 at 08:29
  • @MagnusEriksson I think a combination of both would work the best - identify sessions by IP and a unix timestamp in the URL. – JTinkers Feb 27 '19 at 08:29
  • 1
    Very much related to [How can I send PHPSESSID in the URL?](https://stackoverflow.com/q/1244087/283366) – Phil Feb 27 '19 at 08:38

5 Answers5

5

As we've discussed in the comments - 2 answers make sense and 2 don't.

  1. Is entirely session dependant, so it wouldn't work.
  2. Would work, but people in the same network would share same session.
  3. Is another way session could work, but the same bugs would happen as with 2nd if you shared the url.
  4. An obvious bait answer.

The suggested answer would be 2 and 3 combined (or 3 if you can only pick one), storing session identified by an IP address with a unix timestamp in the URL to differentiate between users.

JTinkers
  • 1,631
  • 9
  • 18
  • 2
    Given this is an interview question, the answer is most probably #3, ie the old `phpsessid` URL parameter which is what we had to use before browsers widely supported cookies. Similar to Java's `jsessionid` – Phil Feb 27 '19 at 08:37
  • @Phil Yes, definitely. Adjusted the answer not to misled. – JTinkers Feb 27 '19 at 08:38
  • 1
    @JCode there are lots of problems with IP as an identifier. There's a huge overhead for IP change mid-visit and in the parts of the world still using IPv4 there is a relatively tiny range of values of IP. It can be used as a qualifier as part of a wider answer (as you've later indicated). – Martin Feb 27 '19 at 08:47
  • @Martin in an ideal world you would just use sessions as they are now.. but in his example I think a combination of few solutions would reduce the invulnerabilities. Personally I would go with IP and a unique token in GET/POST - perhaps not a unix timestamp because that one could be more or less guessed/bruteforced. – JTinkers Feb 27 '19 at 11:20
4

A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.

I assume that this is third option but it's insecure choice.

See: http://php.net/manual/intro.session.php

Phil
  • 157,677
  • 23
  • 242
  • 245
xYundy
  • 83
  • 7
3

This is an explanation of the options available:

  1. using an MD5 hash of the user's email address as the session identifier

This defines how the session is identified but not how that indentity is given to the correct website visitor.

MD5 is insecure (a session link). It should not be used to parse identifying data. Email addresses are identifying data. This answer is deeply insecure and dangerous.

Result: The correct browser will not be identifiable. There is a high security risk.

  1. using the browser's network address as the session identifier

The browser network address (aka IP) changes between times depending on the ISP - you may be 123.234.345.456 one minute and then 243.534.346.41 the other while on the same website.

Also using 2 will open up some very interesting bugs. Specially when there are more than one client from the same network. People will all over sudden start sharing sessions. (Thanks).

And finally, IPv4 addresses are extremely limited in range so it would be easy for someone to brute force attack (ie try addresses until one works).

Result: The correct browser may be identified. However there is no guarentee and there will be false positives and interruptions. There is a high security risk.

  1. including the session identifier as a parameter every GET and POST request

This will append a session identifier to each webpage call and submission, as set by the coder. This is the best of the choices here. This answer means that anyone sharing a URL will also be sharing their authentication, which can also be deeply insecure unless there are various mitigating checks carried out by the website coder.

Result: The correct browser will be identified. However there is no guarentee and there will be false positives due to URL sharing by the client user. This is the single best answer of the choices given. There is a moderate security risk.

  1. using the "secure cookie" header to force the browser to set a cookie

This does nothing. This will force the session cookie to be sent encrypted; which may not be appropriate if the website domain is not encrypted. This will also not work around the issue that whilst the cookie is sent ok, the browser at the other end of the communication will still refuse to accept it.

Result: This will not do anything. This does not answer the question.

Read more here: How can I send PHPSESSID in the URL?

And read the manual.

Community
  • 1
  • 1
Martin
  • 22,212
  • 11
  • 70
  • 132
0

enter image description hereThe right answer is:

Including the session identifier as a parameter every GET and POST request

This screenshot from Web Applications for Everybody Specialization provided by University of Michigan quiz.

Go3shom
  • 9
  • 5
-1

Number 3, is the only real answer... but don't ever buy into that stupid idea that a cookie saved unique session identifier is anymore more secure than passing a unique session identifier via GET, POST, and PUT requests because both are equally insecure.

Stephanie Temple
  • 351
  • 2
  • 4