[PHP] why manual says 'don't use session_register'?
The manual has many cautions that say 'do not use session_regiister,, session_is_registered, session_unregister, when the ini setting is register_globals=off. But they still do work, it seems. Or how exactly do these function work differently than with reg_globals On? Can I still continue to use them with reg_globals=off, as they seem to work anyway? Gian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] disabled cookies and sessions
Nick Wilson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * and then Chris Sechiatano declared You have to code the PHPSESSID into your URL if your browser has cookies disabled or else it won't work. No. As I said, i have php compiled with --enable-trans-sid Php session work differently from PHPLIB. PHPLIB will generate a session, if no cookie and no SID in URL is found, then append it to the URL and redirect you there. In this situation, phplib used to accept and adopt any SID in the url, if there was one. Now no more: phplib will accept a session in the url only if it exists. PHP session don't quite work the same. if no cookie nor SID in url, you have to provide it in the URL, and it will be the session. In fact, if you provide it in the url, it will adopt it and create it even if you have cookies enabled! Great feature for spies. Gian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: emulating --enable-trans-sid -- project idea?
Justin French wrote: Hi all, About 2.30 in the morning I started kicking around an idea, based on the recent discussions on sessions, and what --enable-trans-sid did. From my understanding: + if there is no session cookie, set a cookie AND append a session ID to URLs on the first (session start) page AND do a redirect to self. This is how phplib worked. How do you distinguish the 'first page' from the others? + on the next page, the session is carried, and it checks to see if the cookie set on the prev. page can be found - if it can, it now knows (presumably by setting a session var) that cookies are okay - if it can't, it assumes cookies are not avail, and it knows that the session must be appended to each URL Not quite like that. This is the same as saying: if there's a session in the URL ad no cookie, presume cookies are not available. Wrong presumption. This is the reason why now it is spoofable by opening any page with a user-provided session in the URL + if the session ID must be appended, it waves a magic wand over every .php page and appends a session id... i GUESS through buffering or parsing the entire output. So, couldn't this be emulated by : + following the same set/check routine above + if needed, wave a magic wand over the output before it's sent to the page, by the use of output buffering? If some enough ppl on this list believe it's a good idea to pursue this, and don't think it will result in a big performance drop or anything, I'm keen to start work on it as an opensource project, hopefully with the support of this list to make sure it stays on the right track. On the other hand, there may be a huge flaw in my idea :D Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: emulating --enable-trans-sid -- project idea?
Justin French wrote: Hi all, About 2.30 in the morning I started kicking around an idea, based on the recent discussions on sessions, and what --enable-trans-sid did. From my understanding: + if there is no session cookie, set a cookie AND append a session ID to URLs on the first (session start) page + CREATE THAT PHP SESSION as soon as the sid is generated. And THEN redirect to self + on the next page, the session is carried, and it checks to see if the cookie set on the prev. page can be found - if it can, it now knows (presumably by setting a session var) that cookies are okay - if it can't, it assumes cookies are not avail, and it knows that the session must be appended to each URL + IF THE SESSION IS FOUND EXISTENT. It should, because you created it when generated the sid, before doing the redirect to self. Otherwise someone is spoofing. I've recently modified the PHPLIB behavior about session creation policy, to behave like this. The patch is commited and published at the project's site. + if the session ID must be appended, it waves a magic wand over every .php page and appends a session id... i GUESS through buffering or parsing the entire output. So, couldn't this be emulated by : + following the same set/check routine above + if needed, wave a magic wand over the output before it's sent to the page, by the use of output buffering? If some enough ppl on this list believe it's a good idea to pursue this, and don't think it will result in a big performance drop or anything, I'm keen to start work on it as an opensource project, hopefully with the support of this list to make sure it stays on the right track. On the other hand, there may be a huge flaw in my idea :D Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] the ?PHPSESSID=spoofme 'bug'
Can I tell you more than what the subject says? proceeding: Close the browser, clean all your cookies, and open any page with that ?PHPSESSID=spoofme appended. And see what happens. 1) No cookies are left 2) a session 'spoofme' is created Do you need more? Javascript url injection ad cross site scripting become obsolete with this 'feature'. PLS! I mean, as the zend site doesn't quite work like this (do the same test proceeding as described above...) Their session to append to your cookie-enabled browser location are Zend_Session_DB=whatever and Zend_Session_DB_SECURE=whatever2 on their login page. I don't know if this is related to the free downloadable version, and the one they sell and adopt is more 'fortified'... they should clearly state it then! Gian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: the ?PHPSESSID=spoofme 'bug'
I myself wrote: Can I tell you more than what the subject says? proceeding: Close the browser, clean all your cookies, and open any page with that ?PHPSESSID=spoofme appended. And see what happens. 1) No cookies are left 2) a session 'spoofme' is created Do you need more? Javascript url injection ad cross site scripting become obsolete with this 'feature'. PLS! I mean, as the zend site doesn't quite work like this (do the same test proceeding as described above...) Their session to append to your cookie-enabled browser location are Zend_Session_DB=whatever and Zend_Session_DB_SECURE=whatever2 on their login page. I don't know if this is related to the free downloadable version, and the one they sell and adopt is more 'fortified'... they should clearly state it then! Gian I've commited the latest PHPLIB version (php-lib-stable) that humbly tries to prevent this unsecure behaviour, as I said in one of my prev messages. I can't extend it to the so-called PHPLIB4 (that uses native PHP4 session) tree, because PHP is truely holed in that. Gian -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: the ?PHPSESSID=spoofme 'bug'
Giancarlo Pinerolo wrote: I myself wrote: Can I tell you more than what the subject says? proceeding: Close the browser, clean all your cookies, and open any page with that ?PHPSESSID=spoofme appended. And see what happens. spoofme is not the exact term. ?PHPSESSID=hijackme should be more appropriate, but I avoided it for well known 'historical' reasons :-| G -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] session security
Why can a user force php to create a session he's giving the name in the URL? Do you want me to list an half a dozen ways to get rich now with this holes? Does anyone understand the malice of this? Anyone can offer you a click on a session he's going to visit later and hijack from you? Anyone can post data in a black hole of his own and pass it around secretly? Anyone can place precise strings in a precise file location on a server? How is it that a user can force to have any session string, passed in the URL, being created, even when cookies are fully funcional and enabled? Is it possible that there is no policy on creating a new session? There so much fuzz about register_globals, and we let the user create the sessions they want? Shouldn't we check that's us who issued the ticket? How is it that I cannot find a decent reply to these questions? Giancarlo -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
