[PHP-DEV] Re: session_register warnings
phplib's solution has been to re-register s globals ll the $_SESSION vars. The register_globals=Off has been placed, I suppose, to prevent GET/POST (and any user_originated) var to overwrite uninitialized program variables. As session vars are not user_originated, and only the programmer can set it, I'd let them global as always, or write my own globalizing function after session start Sascha Schumann wrote: With PHP 4.3, it finally becomes possible to completely manage session variables without any dedicated functions. Just set or unset variables in $_SESSION and you are done with it. It could not be any easier. The streamlining of the serialization process also has another advantage -- the extension will notify developers that their script might be indeterministic. How? you ask. Imagine a section of code which intents to change a session variable. At the first execution, setting the global works. But when the section of code is run again, the exact same code will silently fail.[1] You have observed correctly that application developers have noticed that disabling register_globals has an effect on their session usage. Those developers have appropiately changed their applications to read from and write to $_SESSION. Now I ask you: Why should the same set of developers be afraid or incapable of making their scripts more reliable and not complete this transition? [1] I hope everyone sees how absurd it is to suggest that these kind of semantics were actually intended by the session authors. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Transparent SID support
There is a flagrant bug there that allows anyone to chose a session ID of his choice, instead of relying on the random device. I think this breaks some POSIX-MIT-RFC somewhere and can be the cause of easy exploits. I would then say hat for a bugfix release it should be reasonabe to fix it,. I am not saying that user choice of the unpredictable session-id couldn't be a valid method in some cases, as well as other method as suggested, but this the programmer must decide when and where. If you are talking about usecurity of trans_sid, then letting anyone decide it by an url, is even worse. Giancarlo Zeev Suraski wrote: - Transparent sid support is now disabled by default. (Yasuo) I haven't followed the trans-sid discussion closely, but did we decide to change the behavior within a bug-fix release?? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Rasmus Lerdorf wrote: On Mon, 19 Aug 2002, Rasmus Lerdorf wrote: But could you at least answer the question? What is the advantage of allowing user-supplied new session ids? I see no reason not to add a check for this. For example, I have a set of C programs for IRCG load testing. It uses a simple FSM to generate HTTP requests and waste incoming data (like 50K concurrent connections). If this client could not use arbitrary session ids (mysid$running_number), I'd have to actually analyze HTTP replies and the icky Cookie header. Hrm.. Ok, that's what I was looking for. A realworld reason to allow the client to specify the new sids. There are a lot of cases when that can be useful, but that should be controllable behaviour in limited places, not a general one. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Dan Hardiker wrote: Well, more worrisome would be if a bad guy tricks you into clicking on a link or simply sends you an image in an email that makes a request to my server with a valid-looking session id. Then if you go to this site (that I've debunked that scenario already a few times. The net result is that this class of attacks is impossible to prevent. The assumption in your scenario and the following is this: The attacker has access to a script X which calls session_start(). My scenario: 1.) Attacker A accesses X and stores the SID which PHP assigns to him. 2.) A crafts a link containing SID and sends it to victim V. 3.) A keeps SID alive by repeatedly accessing X using SID. 4.) V opens link and authenticates. 5.) A's script notices (4). A can overtake V's session. Ive extended the session handling so that upon session start, it takes a snapshot of the browser string (and maybe a couple of other javascript-retrieved variables about the user's os, eg: the resolution) and build up as much of a picture of the client as possible. So you should pick upt that 'initial propagation mode', so later someone can decide to block a client shift in that while pretending to remain the same client. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] gc_maxlifetime shouldn't always be INI_ALL
In a vhost environment, it seems tat any script can flush all existing sessions that use the common save_path by lowering his gc_maxlifetime and seting his gc_probability to 100%. Both gc_maxlifetime and gc_probability values are INI_ALL, even when the sessio.save_path is set to everybody's cauldron, on /tmp. This will make possible for any vhost to block other vhosts' session management. Maybe it should be INI_ALL *only* when a particular save_path is specified, so that will influence only his sessions? Or does it exist some fault setting by which anyone could have the privileges to force gc on some other vhosts' session by specifying *also* the other vhost's save_path? Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto:
Hrm.. Wait a second though, Giancarlo is saying that if the user passes
in a session id himself and that session does not exist, then that will be
the session id he will be given if a session is created on that request.
Is that correct, Giancarlo?
Well, yor browser has to be 'virgin' with regards to that cookie.
You musn't have received one already. to be an available victim
Giancarlo
From looking at the code and testing that assumption, it does not look
like that is the case. Try it yourself. Make 2 files:
file1.php:
?php
session_start();
session_register('a');
$a = Foo;
?
Setting $a to Foo
file2.php:
?php
session_start();
echo $a;
phpinfo();
?
Then (with register_globals on) load up:
file1.php?PHPSESSID=123
followed by
file2.php?PHPSESSID=123
You will find that the session cookie that is generated is not 123 and
the /tmp session file is not sess_123
-Rasmus
On Sun, 18 Aug 2002, Dan Hardiker wrote:
But the real issue here is about session hijacking. Yes, of course
people can send whatever session id they want to PHP. Since the
session id comes from the user we need to accept what is sent.
This is what I consider unconceivable.
Why ever should tickets issued by the user be accepted, to what pro?
Something clashes here with that 'very umpredictable dedicated device'.
I'd prefer no acceptance of user provided id, if not where expressely
configured.
There is a simple solution, make sure your the one generating the IDs,
and upon each proper session start (where no session id is passed in)
set a session I started this session variable. If a session ID has been
passed in, then check for that variable, if it exists - continue, if not
then show an error message.
Note: you will experiance the same problem if the session times out.
--
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software Systems Engineer
First Creative Ltd
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Il 00:13, lunedì 19 agosto 2002, hai scritto: Il 23:54, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto: Hrm.. Wait a second though, Giancarlo is saying that if the user passes in a session id himself and that session does not exist, then that will be the session id he will be given if a session is created on that request. Is that correct, Giancarlo? Well, yor browser has to be 'virgin' with regards to that cookie. You musn't have received one already. to be an available victim Even if you haven't received a cookie already, I don't think you can set the session id the way you describe. Can you get PHP to create /tmp/sess_123 given my example? Yes, I do [root@pong tmp]# ls -l sess* -rw---1 nobody 4294967295 12 Aug 19 00:31 sess_123 it contains: a|s:3:Foo; Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
On 02:45, sabato 17 agosto 2002, Rasmus Lerdorf wrote: Edin Kadribasic wrote: I absolutely agree with Stefan here. It is *not* PHP's job to secure a connection. SSL does this. Like that's going to stop users from pasting url with SID in it to an email, which is what this thread is about. Edin The issue is also that anyone can provide an URL wich can force the creation of any user-provided ID and, at_the_same_time, force the use of URL propagation instead of cookie propagation, on ANY cookie-enabled client. It is unconceivable that any user is given trust in supplying his 'unpredictable' session ID. At the moment only the (forthcoming?) session.use_only_cookies php.ini directive can block that. I know nothing can be secure 100%, but the fact that 'a horse with three legs can still walk' is no good reson not to shoot that leg (hey, I love horses, but this one is an enemy one...;-) But any user can just as easily provide his own cookie with the session id in it. The simple move from the URL to a Set-Cookie header in the request does not suddenly make it secure. -Rasmus Any propagation, doesn't matter. The passed id must exist, otherwise discarded and regenerated. I saw that php already creates the session at the start. The possibility to count on a stable name, because recreable anytime and though surviving gc, is a great weaknes for that tipe of snoop. php has to have the nicely dedicated devices to generate the id. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Rasmus Lerdorf wrote: Any propagation, doesn't matter. The passed id must exist, otherwise discarded and regenerated. I saw that php already creates the session at the start. The possibility to count on a stable name, because recreable anytime and though surviving gc, is a great weaknes for that tipe of snoop. php has to have the nicely dedicated devices to generate the id. And it does. The session ids are not predictable, especially if you set the entropy source to something like /dev/urandom in php.ini -Rasmus Sorry, but I feel like speaking with HAL.. The unpredictable choice has to be made by a dedicated device except whenever any user decides to create his favourite one? I mean by appending ?PHPSESSID=foo that is what happens. User choice is ginven priority over that dedicated device. User can force php to create and recreate anytime any known id of his choice. Gian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Il 02:48, domenica 18 agosto 2002, Rasmus Lerdorf ha scritto: But the real issue here is about session hijacking. Yes, of course people can send whatever session id they want to PHP. Since the session id comes from the user we need to accept what is sent. This is what I consider unconceivable. Why ever should tickets issued by the user be accepted, to what pro? Something clashes here with that 'very umpredictable dedicated device'. I'd prefer no acceptance of user provided id, if not where expressely configured. Perhaps a check should be added to make sure it looks like a proper session id before using it, but this can be done easily in user space and it really doesn't affect security in any way. We are trying to protect the existing sessions sitting behind the unpredictable PHP-generated session ids. Why would a normal user hack himself and choose a predictable session id? He'd induct someone else do it, by passing it in the URL, SSL or not, which takes us back at the beginning of this thread. Gian -Rasmus On Sun, 18 Aug 2002, Giancarlo wrote: Rasmus Lerdorf wrote: Any propagation, doesn't matter. The passed id must exist, otherwise discarded and regenerated. I saw that php already creates the session at the start. The possibility to count on a stable name, because recreable anytime and though surviving gc, is a great weaknes for that tipe of snoop. php has to have the nicely dedicated devices to generate the id. And it does. The session ids are not predictable, especially if you set the entropy source to something like /dev/urandom in php.ini -Rasmus Sorry, but I feel like speaking with HAL.. The unpredictable choice has to be made by a dedicated device except whenever any user decides to create his favourite one? I mean by appending ?PHPSESSID=foo that is what happens. User choice is ginven priority over that dedicated device. User can force php to create and recreate anytime any known id of his choice. Gian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] trans-sid warning?
Edin Kadribasic wrote: I absolutely agree with Stefan here. It is *not* PHP's job to secure a connection. SSL does this. Like that's going to stop users from pasting url with SID in it to an email, which is what this thread is about. Edin The issue is also that anyone can provide an URL wich can force the creation of any user-provided ID and, at_the_same_time, force the use of URL propagation instead of cookie propagation, on ANY cookie-enabled client. It is unconceivable that any user is given trust in supplying his 'unpredictable' session ID. At the moment only the (forthcoming?) session.use_only_cookies php.ini directive can block that. I know nothing can be secure 100%, but the fact that 'a horse with three legs can still walk' is no good reson not to shoot that leg (hey, I love horses, but this one is an enemy one...;-) Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] gc impossible if session.save_path depth 2 ?
Many hosted sites would like to keep their session.save_path separate, within their home dir, but are somehow prevented by the fact that gc wouldn't take place if the path depth is 2. Because they obviously see a problem in implementing their own garbage collection, as most hosting sites do not offer a shell nor the possibility to set up cron jobs to do that, most give up that, and decide to drop their session in the common cauldron. I went through php code, and it seems that this limit is just hardcoded in there. I mean, is there a valid technical reason for this limit to be there or... gian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_globals vs session.force_nocookie
Jani Taskinen wrote: I was wondering (I'm propably wrong, it's almost 6am here :) that wouldn't the real fix for this without having to add yet-another-ini-option have been to fix this so that logic with session.use_cookies and session_use_trans_sid worked like it was (?) meant to work. I agree. That should be the same. But what about use_cookie=1 and use_trans_sid=1 situation? When should we allow to fallback from cookie to URL propagation? Shouldn't the GPC rule apply here too? I know the problem with the very first hit, when we know nothing of cookies enabled or not.. But the session offered in the url is checked and eventually created, before the firts redirect/cookie_check. SO at this point, before the initial redirect, we know if this is a 'living' or a 'newborn' session. I wonder if, even at the application level, it would make sense to trigger this with the canges in the propagation mode, and block any downgrade in propagation mode. But I slept only a few hours too. It is unusual that the same client would switch cookies on/off amid the way, and if this happens we are probably facing a client qui pro quo. Once the client has proven to be cookie-enabled, why should we accept a lower level, if we don't expressly want it (use cookies if they are enabled). I know counting on the possibility to force a downgrade in the propagation mode is a very common practice of writing code, but we should be able to do the same with a little bit more of control. So these directive should be overridable on a per script basis. Giancarlo ie. session.use_cookies=1 and session_use_trans_sid=0 would not use any other session id but the one provided by the cookie? btw. Cookies can be forged too.. --Jani On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote: Hi. Last here, same period, I found that nasty thing in ?_PHPLIB[libdir]=http:// It was the nefarious start of the register_globals=off saga. Now Sascha has agreed to add a session.use_only_cookie directive, because session.use_cookie wasn't doing it really all the times. In fact, contrary to what advertised, session.use_cookie doesn't uses cookies if a SID is found in the URL, and can so be forced to use a user_provided variable when it should not. The winning argument, for the new session.use_only_cookies, has been that, with the actual settings, there cannot exist a situation in which PHP would discard the ID in the URL, and go cookie_or_nothing, as the banks do. It is forceable. Even if the client has cookies enabled. You know, really secure sites use *only cookies* propagation, or you don't do your home banking. Because cookies are the closest thing that can assure that we are speaking to the same client, that noone can takeover a session. The basis for this behavior of session.use_cookie is that we may not know when coookies are enabled, not on the very first hit, when I suppose a redirect to self is made and the cookie is then checked for presence. The aim to use cookies, if available, is because cookie is an acronym of 'not transferrable among clients that support cookies', that is it goes as close as possible to identify a single client. My interpretation of session.use_cookie is: if cookies are enabled, try to use them as a propagation because they cannot be transferred among clients (see the acronym above). If this is the aim, and on coming back from the redirect we found a cookie, still the presence of a user-provided SID in the url should make us suspicious. If we want to prevent session takeovers, here we are in presence of a transfer. We couldn't know that cookies were enabled the very first hit, but now we know it, and there is a SID in the URL... someone is forcing a transfer. Discard the sid and issue a new cookie. Once we know cookies are enabled we should stick to them, not because they are a better way of storage, but because tey guarantee uniqness of the client. So why should we allow a transfer from outside? All this is apart from other concerns, as the possibility to create session_id at will, with pleasing and easy-to-remember values, to be offered around for those 'social engineering' attacks, with no hope for the poor cookie-enabled victim to avoid it. Isn't his similar to the register_globals=on problem, where untrusted user provided values can make their way inside the script? Isn't this variable even more important, to let it in? Giancarlo Pinerolo -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_globals vs session.force_nocookie
Giancarlo Pinerolo wrote: Jani Taskinen wrote: I was wondering (I'm propably wrong, it's almost 6am here :) that wouldn't the real fix for this without having to add yet-another-ini-option have been to fix this so that logic with session.use_cookies and session_use_trans_sid worked like it was (?) meant to work. I agree. That should be the same. But what about use_cookie=1 and use_trans_sid=1 situation? When should we allow to fallback from cookie to URL propagation? Shouldn't the GPC rule apply here too? I know the problem with the very first hit, when we know nothing of cookies enabled or not.. But the session offered in the url is checked and eventually created, before the firts redirect/cookie_check. SO at this point, before the initial redirect, we know if this is a 'living' or a 'newborn' session. I wonder if, even at the application level, it would make sense to trigger this with the canges in the propagation mode, and block any downgrade in propagation mode. But I slept only a few hours too. I mean by writing, once we know the session has just been created, a mode=new variable into the session... Then, returning from the very first redirect (mode==new): if a cookie is available, change mode=cookie if a cookie is not available, change mode='get'. On subsequent reenters, comparing the availability of the cookie with the mode setting, simply do not accept any change that has 'cookie' in only one of the two. Does it make sense as an interpretation of 'use cookies if they are available'? Giancarlo It is unusual that the same client would switch cookies on/off amid the way, and if this happens we are probably facing a client qui pro quo. Once the client has proven to be cookie-enabled, why should we accept a lower level, if we don't expressly want it (use cookies if they are enabled). I know counting on the possibility to force a downgrade in the propagation mode is a very common practice of writing code, but we should be able to do the same with a little bit more of control. So these directive should be overridable on a per script basis. Giancarlo ie. session.use_cookies=1 and session_use_trans_sid=0 would not use any other session id but the one provided by the cookie? btw. Cookies can be forged too.. --Jani On Sat, 15 Jun 2002, Giancarlo Pinerolo wrote: Hi. Last here, same period, I found that nasty thing in ?_PHPLIB[libdir]=http:// It was the nefarious start of the register_globals=off saga. Now Sascha has agreed to add a session.use_only_cookie directive, because session.use_cookie wasn't doing it really all the times. In fact, contrary to what advertised, session.use_cookie doesn't uses cookies if a SID is found in the URL, and can so be forced to use a user_provided variable when it should not. The winning argument, for the new session.use_only_cookies, has been that, with the actual settings, there cannot exist a situation in which PHP would discard the ID in the URL, and go cookie_or_nothing, as the banks do. It is forceable. Even if the client has cookies enabled. You know, really secure sites use *only cookies* propagation, or you don't do your home banking. Because cookies are the closest thing that can assure that we are speaking to the same client, that noone can takeover a session. The basis for this behavior of session.use_cookie is that we may not know when coookies are enabled, not on the very first hit, when I suppose a redirect to self is made and the cookie is then checked for presence. The aim to use cookies, if available, is because cookie is an acronym of 'not transferrable among clients that support cookies', that is it goes as close as possible to identify a single client. My interpretation of session.use_cookie is: if cookies are enabled, try to use them as a propagation because they cannot be transferred among clients (see the acronym above). If this is the aim, and on coming back from the redirect we found a cookie, still the presence of a user-provided SID in the url should make us suspicious. If we want to prevent session takeovers, here we are in presence of a transfer. We couldn't know that cookies were enabled the very first hit, but now we know it, and there is a SID in the URL... someone is forcing a transfer. Discard the sid and issue a new cookie. Once we know cookies are enabled we should stick to them, not because they are a better way of storage, but because tey guarantee uniqness of the client. So why should we allow a transfer from outside? All this is apart from other concerns, as the possibility to create session_id at will, with pleasing and easy-to-remember values, to be offered around for those 'social engineering' attacks, with no hope for the poor cookie-enabled victim to avoid it. Isn't his similar
[PHP-DEV] Re: register_globals vs session.force_nocookie
[EMAIL PROTECTED] (Sascha Schumann) wrote: --- Let's analyze the meaning of session.use_cookies, shall we? http://php.net/manual/en/ref.session.php says: session.use_cookies specifies whether the module will use cookies to store the session id on the client side. Defaults to 1 (enabled). Please note the absence of words like only. The combination of session.use_cookies=1 and session.use_trans_sid=0 is working perfectly fine at the moment. This is also not about forgery. While cookies are user data, the thing Mr. Pinerolo worries about is tricking a victim into using session ids which are known to the attacker. While it is easy for an attacker to send a URL to the victim containing a session id, injecting a malice cookie into the victim's system is a much harder job. I would say it is impossible, if I would not know about user habits and the quality of the software coming out of Redmond. Despite the availability of patches, many systems are simply not updated in a timely fashion. You also cannot compare this issue to register_globals, unless you are used to compare apples and oranges. With register_globals=on, a malice user can directly cause harm and severe damage to a service, if the scripts are badly written. For example, an attacker could inject SQL directly and cause all tables to be dropped. With session.use_only_cookies=0, an attacker has a tool for planting social engineering attacks against unwitting users. It does not cause direct damage on the server side. It is one way of thousands to manipulate users. Just look at how many AOL accounts are pfished each day, because users ignore the warning that noone will legitimately ask them for their password. Mr. Pinerolo's example of online banking is immune to this scheme, because all bank transactions are protected by a one-time pad (called TANs in Germany). I would not have come up with the session.use_only_cookies idea, if I did not see an advantage for using it under some circumstances. These circumstances are rare though and do Frankly, what I think of this is that it is a piece of social engineering in itself. The new session.use_only_cookies directive, put like that, that can only be set on a per installation basis, will never be adopted. This will leave all sites in the world vulnerable to damn easy snooping. I understand there are historical reasons for trying to keep the status quo, probably too many applications rely on the actual weakness. I do not share that vision. Anyway this will come back to your face one day, I have no doubts about it. This is not my problem, I'll be fairly offshore for the next months, so really you do what you want, discuss it or impose it among yourselves, I've done my duty. Mr. Pinerolo not apply to all sites in general. Badly written PHP scripts are more common apparently which was the deciding factor for disabling register_globals. I do not foresee such a compatibility breaking step with regard to session.use_only_cookies. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] register_globals vs session.force_nocookie
Hi. Last here, same period, I found that nasty thing in ?_PHPLIB[libdir]=http:// It was the nefarious start of the register_globals=off saga. Now Sascha has agreed to add a session.use_only_cookie directive, because session.use_cookie wasn't doing it really all the times. In fact, contrary to what advertised, session.use_cookie doesn't uses cookies if a SID is found in the URL, and can so be forced to use a user_provided variable when it should not. The winning argument, for the new session.use_only_cookies, has been that, with the actual settings, there cannot exist a situation in which PHP would discard the ID in the URL, and go cookie_or_nothing, as the banks do. It is forceable. Even if the client has cookies enabled. You know, really secure sites use *only cookies* propagation, or you don't do your home banking. Because cookies are the closest thing that can assure that we are speaking to the same client, that noone can takeover a session. The basis for this behavior of session.use_cookie is that we may not know when coookies are enabled, not on the very first hit, when I suppose a redirect to self is made and the cookie is then checked for presence. The aim to use cookies, if available, is because cookie is an acronym of 'not transferrable among clients that support cookies', that is it goes as close as possible to identify a single client. My interpretation of session.use_cookie is: if cookies are enabled, try to use them as a propagation because they cannot be transferred among clients (see the acronym above). If this is the aim, and on coming back from the redirect we found a cookie, still the presence of a user-provided SID in the url should make us suspicious. If we want to prevent session takeovers, here we are in presence of a transfer. We couldn't know that cookies were enabled the very first hit, but now we know it, and there is a SID in the URL... someone is forcing a transfer. Discard the sid and issue a new cookie. Once we know cookies are enabled we should stick to them, not because they are a better way of storage, but because tey guarantee uniqness of the client. So why should we allow a transfer from outside? All this is apart from other concerns, as the possibility to create session_id at will, with pleasing and easy-to-remember values, to be offered around for those 'social engineering' attacks, with no hope for the poor cookie-enabled victim to avoid it. Isn't his similar to the register_globals=on problem, where untrusted user provided values can make their way inside the script? Isn't this variable even more important, to let it in? Giancarlo Pinerolo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: php4 /ext/session php_session.h session.c
Sascha Schumann wrote: I noticed this risk long time before and I think it's a kind of security fix as Sascha's comment, isn't it? That depends on your viewpoint. From my perspective, this is not urgent. It is not like an attacker can gain access to the server, it just makes it a bit harder for attackers to exploit ignorant people. That group will always be vulnerable to social engineering, something which can only be addressed by education. Technology is not able to upgrade your brain, after all. - Sascha We must watch out for technology not to downgrade it. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Forwarding: I found a FIX for a but and don't know who to contact.
Forwarded message (original was to [EMAIL PROTECTED]): --- Excuse me if I am writing to you, but this also concerns you: How may I contact PHP developers so to send them a bugfix? The php site doesn't say that, or I had not been able to find out. BTW, the bug is a very dangerous one: with ibase-php, all the numeric scaled fields (i.e. with decimals) are translated into php numbers without leading zeroes after the decimal dot. I.e.: PI= 3.1428... is correctly translated, but MY SALE = 19.09$ is translated into 19.6$ ! ARRG, this puts at risk all the e-commerce translations with PHP and Interbase... I posted a bugfix as bug report 14755. Please, tell me who could put this 10 lines bugfix in the code interbase.c code... All you can do is to post that bugreport. This is the usual flow of a bugfix going to be accepted. You may also write to [EMAIL PROTECTED] directly of you would like to get things going faster. This is holiday time now, so please count on this thing! Goba [one [EMAIL PROTECTED]] - END OF FORWARDED MESSAGE And so I did... Thanks to everyone for your help. Giancarlo -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #14755: 105.05$ becomes 105.5$ !!! - I found the fix.
From: [EMAIL PROTECTED]
Operating system: ALL
PHP version: 4.1.1
PHP Bug Type: InterBase related
Bug description: 105.05$ becomes 105.5$ !!! - I found the fix.
Hello. I found a nasty bug in interbase extension, and I
have the solution here. You have only to put it in the
source code; I would but I don't know how to do this. I
already posted the authors, but with no result.
104.05$ become 104.5$ !!!
When traslating scaled numeric fields (i.e. with
decimals), the routine _php_ibase_var_pval is faulty;
here is the original code:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
val-value.str.len = sprintf(string_data, %Ld.%Ld,
(ISC_INT64) (*((ISC_INT64 *)data) /
(int) pow(10.0, (double) -scale)),
(ISC_INT64) abs((int) (*((ISC_INT64 *)data) %
(int) pow(10.0, (double) -scale;
val-value.str.val = estrdup(string_data);
break;
#endif
You can clearly see that this code is fine if the decimal
part has no 0s before the first non 0 cipher. Here is
my correction:
#ifdef SQL_INT64
case SQL_INT64:
val-type = IS_STRING;
/* Experimental section by Giancarlo Niccolai */
if (scale) {
int i, len;
char dt[20];
double number = (double) ((ISC_INT64)
(*((ISC_INT64 *)data)));
for (i = 0; i -scale; i++)
number /= 10;
sprintf(dt, %%0.%df, -scale);
val-value.str.len = sprintf (string_data, dt ,
number);
}
else {
val-value.str.len = sprintf (string_data, %Ld,
(ISC_INT64) (*((ISC_INT64 *)data)));
}
/* End of experimental section */
val-value.str.val = estrdup(string_data);
break;
#endif
Please, since Interbase is used for e-commerce, all the
php-interbase applications can be at risk, if the site
deals with cents...
--
Edit bug report at: http://bugs.php.net/?id=14755edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12819: variables and constants in classnames
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.0.6
PHP Bug Type: Feature/Change Request
Bug description: variables and constants in classnames
it would be nice to have the possibility to create classes with variable or
constants in 'classname' and 'extends'.
eg:
define $myauth=myAuth;
define (_BASE_AUTH_CLASS, Base_Auth);
class {$myauth} extends {_BASE_AUTH_CLASS}
{...
etc
This way package delivery and integration would be a lot easier, as they
can presume the existance of already defined classes, and adopt them.
Giancarlo
--
Edit bug report at: http://bugs.php.net/?id=12819edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12383: $105.04 becomes $105.4!!!
From: [EMAIL PROTECTED]
Operating system: LINUX
PHP version: 4.0.6
PHP Bug Type: InterBase related
Bug description: $105.04 becomes $105.4!!!
GGG!! Interbase module has this orrible bug. It
transforms any BIG INTEGER (ISC_INT64) type with decimal
points are stripped of it's zeroes between decimal point
and the first non-zero decimal cipher
I.E. 150.0045 becomes 150.45.
This bug is very fast to find in the code, because the
transformation from Interbase to PHP data is done with an
instruction like
sprintf (buffer, %f.%f, [find integer part], [find
fractional part]); and no control over the zeroes in the
fractional part. Even wrose, this calculus are done with 2
heavy double pow calls, divisions and modules (with an
horrible waste of time...
Now, if I had done an error like that in a programming
execice, my teacher would have given 2 to me, (that is,
F), even if I have studied Economics, not IT. How could
this error have survived since now? It could cost a very
high price for users, if you think that all the
transactions in dollars, euros, punds and any currency
with a fractional part IS WRONG!
Now, I have patced the source; find the static int
_php_ibase_var_pval function in the interbase.c file, ad
substitute what is inside the #ifdef SQL_INT64 with the
following code:
#ifdef SQL_INT64
case SQL_INT64:
/* Experimental section by Giancarlo
Niccolai */
if (scale) {
int i, len;
sprintf (string_data, %Ld,
(ISC_INT64) (*((ISC_INT64 *)data)));
len = strlen(string_data);
for (i = 0; i = -scale; i ++)
string_data[len-i+1] =
string_data[len-i];
string_data[len-i+1] = '.';
val-value.str.len = len+1;
val-value.str.val =
estrdup(string_data);
}
else {
val-value.str.len = sprintf
(string_data, %Ld, (ISC_INT64) (*((ISC_INT64 *)data)));
val-type = IS_STRING;
val-value.str.val =
estrdup(string_data);
}
/* End of experimental section */
val-type = IS_STRING;
/* OLD CODE */
/*val-value.str.len =
sprintf(string_data, %Ld.%Ld,
(ISC_INT64) (*((ISC_INT64 *)data)
/ (int) pow(10.0, (double) -scale)),
(ISC_INT64) abs((int)
(*((ISC_INT64 *)data) % (int) pow(10.0, (double)
-scale;
val-value.str.val =
estrdup(string_data);*/
break;
#endif
The code is faster (you'll have in the wrost case of all
about 18 iterations on a char array), cleaner and work
always.
Now, I hope you'll put this code in the PHP dists as soon
as possible, and give a STRONG evidence of this problem in
your site, possibily warining all PHP-INTERBASE users,
that, as I know, are a LOT.
P.S. I found the same error in the PERL DBD::Interbase
module; I will soon track it down and send a remark to the
perl community.
Thanks in advance,
Giancarlo Niccolai.
--
Edit bug report at: http://bugs.php.net/?id=12383edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
