Talk:Session fixation

Merger proposal

This topic is already mentioned on the Session_hijacking article and the two issues overlap greatly. It seems it would be easiest to deal with both at once. Blackthirteen 22:33, 25 September 2007 (UTC)

This article contains good examples and useful information. I fear that woudl be lost in a merger. This article should be kept as a drill-down page of Session Hijacking. --jodastephen (talk) 12:26, 16 April 2008 (UTC)

Session_hijacking is a distinctively different issue than this, it would be misleading to merge this. AlexLehm (talk) 18:43, 4 July 2008 (UTC)

6 months later and it has not been merged so I am going to remove the merge template and begin a copy-edit. —Preceding unsigned comment added by Glubbdrubb (talk • contribs) 14:45, 20 January 2009 (UTC)

Title

The title of this article has a typo. It should be Session Fixation.

Spelling and Grammar

I tried to polish this article's writing somewhat. I tried to eliminate as many adjectives as I could and clean up the "I am giving you a tutorial" tone of the article. Much remains to be done, of course. There needs to be more information and slightly less tutorial. However, I kept everything that was there in some form because, reading this for information, I found it helpful. Bluesprite 00:49, 8 April 2007 (UTC)

PHP use in article

A lot of the examples in this article make reference to the PHP language. I'd like to see one of the following: either (a) the code is rewritten in easy-to-read pseudocode, or (b) the code is fixed so it is syntatctically correct PHP. A Pattern O 04:13, 11 April 2006 (UTC)

I fixed the PHP a few hours ago, but pseudocode, or removing the examples entirely and making the article less of a howto, would be better. --Matt Nordhoff (talk) 08:07, 20 November 2006 (UTC)

Saldo?

In the sample attack, what the hell is a 'saldo' feature? Is that some kind of metasyntactic variable that I've never heard of? Audiodude 04:28, 8 May 2006 (UTC)

It is the Dutch word for balance, so I assume that's what it means.Bluesprite 00:11, 8 April 2007 (UTC)

PHP Wikibook on Sessions

The tutorial-style content from this article would be good to include in the PHP Wikibook: Wikibooks:Programming:PHP/sessions#Avoiding_Session_Fixation. —Sam Wilson (Australia) (talk) 23:36, 7 May 2008 (UTC)

The PHP code requires some fixes. Calling session_regenerate_id() after session_destroy() is useless, the session is already destroeyed, hency session_id() returns an empty string. Calling session_start() immediately after session_destroy() has almost the same effect, it generates a new session id. 14:43, 01 January 2009 (UTC) —Preceding unsigned comment added by 212.80.224.243 (talk)

Clarification

What exactly does this mean:

"However, session identifiers are often accepted from GET/POST as well on these standard systems."

I am trying to improve the grammar but I occasionally need to know what the author means. Please help. --Glubbdrubb (talk) 15:15, 20 January 2009 (UTC)

The lumping of GET and POST requests as posing the same risks in this case is over broad. The author of that section just mentioned does not specify the risk of a session identifier being in the POST body, unless they are referring to unencrypted traffic, which is not that common any more and is its own risk outright. Also, the assertion in the heading "Do not accept session identifiers from GET / POST variables" follows with supports that only apply to GET requests. Exactly how are POST body variables obtainable by an attacker except through unencrypted traffic, which is again, its own, separate issue? POST should be struck from these arguments, it is over broad and not supported. 67.130.13.130 (talk) 13:35, 24 September 2020 (UTC)

https://DiD/ ?

Could anyone explain why we are looking for this in $_SERVER['HTTP_REFERER'] in example in section "Defense in Depth"? It's possibly good idea to explain it in the actual article as well. Sadi (talk) 22:45, 2 March 2009 (UTC)

I'm sorry, could you explain your question? Sephiroth storm (talk) 00:11, 4 March 2009 (UTC)

It appears that HTTP_REFERER is no longer mentioned in the Article's section on Defense In Depth. 71.215.203.202 (talk) 22:00, 13 March 2015 (UTC)

Client IP in cookie?

Would it be a valid countermeasure to store client's IP in the cookie when the cookie is created, and on subsequent requests check that the client's IP matches the IP stored in the cookie?

No. If only it worked, but there are too many cases where the IP address can change. See below. 21:53, 13 March 2015 (UTC) — Preceding unsigned comment added by 71.215.203.202 (talk)

'loose' IP check?

"A simple workaround to this, but by no means robust, is to carry out a 'loose' IP check whereby you can check the first three out of the four numbers within the IPv4 Address."

This is worthless. Whoever wrote this needs to read up on CIDR. They also need to read up on IPv4 address notation. An IP is just a number and can be represented many different ways. Even the dot notation has many different valid forms. For example: A.B.C.D and A.E can represent the same IP if E is a 24 bit number representing B.C.D. —Preceding unsigned comment added by 173.178.6.171 (talk) 16:31, 5 April 2011 (UTC)

It's even worse. More and more private networks (e.g. large corporations, or even smaller corporations with forward-thinking IT departments) are using dynamic NAT (DNAT) or IPv6 or other protocols wherein the IP address can change to widely varied addesses. I've seen cases where the client web browser's IP address randomly flips between an IPv4 and an IPv6 address, which causes any session-to-IP check to fail. — Preceding unsigned comment added by 71.215.203.202 (talk) 21:52, 13 March 2015 (UTC)