Re: Bug #3517 Updated: HTTP_COOKIE_VARS, HTTP_POST_VARS, HTTP_GET_VARS open to manipulation

Hi Joey (or co-writers), thank you for your very quick answer. It's basically right what you're saying to session fundamentals. A lost session ID - and only a new session begins. But that's not (completely) the issue, I meant. Bug Database schrieb: > > ID: 3517 > Updated by: joey > Reported By: naklar@altavista.net > Status: Open > Bug Type: Misbehaving function > Assigned To: > Comments: > > This seems to only be a concern if all you are doing for "session management" is > testing /IF/ a variable is set, > rather than using sessions the way that (AFAIK) they are meant to be used...ie, make sure that > whatever > session vars are passed by user still exist, either in DB or filesystem, however you > implemented your sess. > management. Please let me explain: Primary: The actual situation gives me the idea, that at any time a clever organized person could deliver information this way, which is unwanted and could cause any trouble. Especially, if GET-Variables are delivered and at the same time Cookie-Vars overwritten. You alternatively could introduce - a variable state information, which provides to each imported var the source information, so that one could ask: is_getvar, is_postvar, is_cookievar, ... - Or the explicit overwrite with $HTTP_x_VARS[] is programmatically ignored/suppressed but I don't know, whether these methods would be better, because: Systematically to the CGI var Arrays: 1) They provide information, which is static. Changing takes place without any effect and would indicate something, which is wrong in the sense of the original meaning of the Arrays (providing source dependant information). If I like to change something, I would use the global Variables themselfes. 2) The arrays then would be a senseless redundancy, if they loose their role as relyable source indicator. 3) If someone wants to operate on the vars he can easyly make a copy of the arrays. 4) Beginners will not realize the possible implications. 5) None of the arrays provides, working like now, really relyable information. But Containers for CGI Variables should do this to avoid them to become anyhow obsolete or even dangerous. Further Example: In my session management I make an important distinction between Cookie based session and GET based ones, which are treated with more restrictions and in another way of handling. So if a fallback to GET after the initial negotiation happens, the state manager has to know about this, because another session handler now becomes active: At least the session ID must be published in the URL. With cookies not necessary. The session manager also has a setup option to reject GET sessions - this job can only be done if it knows the variable source. Seen from the other side, I will go shure, that a shure fallback to GET happens, in the case of wrong or missing Cookie infos. To assure, that a cookie is set or not I now use the lower level function getenv("HTTP_COOKIE") function, which cannot be overwritten. Shure, these are cases and issues from a certain border of requirements. And I really don't know, whether in practice they will become a hard implication. But I dont't believe this a good idea to be awaited and tested. > There are times when I actually dig into the HTTP_POST_VARS for very good reasons, as do some > others, > so making these read only is not, IMO, a good idea. > > I am not denying that this /may/ be a security risk to some degree, but your bug report > A) Does not (IMO) give a valid example of /HOW/ this could be abused > B) Your suggested fix does not seem to be the best way around such issues. > > Full Bug description available at: http://bugs.php.net/?id=3517 Thx again, and Regards, oK.