From: Tyler A. <fi...@ru...> - 2001-04-17 02:24:50
|
> + if (!isset($validate_php)) > + include("../src/validate.php"); Can't even this be overridden with ..../compose.php?validate_php=true&etc=blah ? Perhaps we should switch from if (! isset($something_php)) include("../src/something.php"); to include_once("../src/something.php"); but that requires PHP 4.0.1pl2. Perhaps we could write our own nifty function? Then at the beginning of any file we just use include("../functions/nifty.inc"); Which, of course, would only load itself once, and then we use nifty_include("../src/something.php"); and the nifty file would only include that thing once.... ... .. . . I don't know -- maybe this will trigger an idea for someone else. The current validation stuff we have seems to be vulnerable to what it is trying to protect us from. |
From: Lewis B. <lbe...@ab...> - 2001-04-17 02:56:39
|
> but that requires PHP 4.0.1pl2. Perhaps we could write our own nifty > function? Then at the beginning of any file we just use > I am against making a clumsy bit of code (no matter how good it is) that will make things slower when a perfectly good piece of language construct that is fast is already in php. So what if someone needs to upgrade to 4.0.2 or something. For God's sake, PHP is about to come out. The dev is already on 4.0.6. Not that I should have any say in anything since I haven't been doing squat! |
From: Luke E. <leh...@cs...> - 2001-04-17 04:01:25
|
Matt suggested an even better method to me, and I just committed it. It's really slick too. Just added this to the top of all function files: if (defined ('file_php')) { return; } else { define ('file_php', true); } This way we don't have to worry at all when including files. The included files take care of themselves. This also maintains backwards compatability. Matt had the good point that most people if they have an older version of PHP installed, won't upgrade just for this security fix. They'd prefer to stay with the older version to save the headaches of upgrading. I'm not condoning that pattern of thinking, but quite frankly, that's how it is. This method hurts nobody, and is no slower than what we had before. It's much more secure though, and easier to use. Luke On Mon, 16 Apr 2001, Lewis Bergman wrote: > > but that requires PHP 4.0.1pl2. Perhaps we could write our own nifty > > function? Then at the beginning of any file we just use > > > I am against making a clumsy bit of code (no matter how good it is) that > will make things slower when a perfectly good piece of language construct > that is fast is already in php. > > So what if someone needs to upgrade to 4.0.2 or something. For God's sake, > PHP is about to come out. The dev is already on 4.0.6. > > Not that I should have any say in anything since I haven't been doing squat! > > > -- _ . . Luke Ehresman - "Codito, ergo sum" / v \ lu...@sq... /( )\ http://www.css.tayloru.edu/~lehresma ^^ ^^ |
From: lbergman <lbe...@ab...> - 2001-04-17 13:26:47
|
> This method hurts nobody, and is no slower than what we had > before. It's much more secure though, and easier to use. > > Luke I am curious as to how it is more secure. I am not arguing, I just don't understand it. It seems the same, or is defining something different than setting it? I guess I better hit the manual. I also wonder if it might noyt be a good idea to strip the ARG_V and ARG_C when they aren't needed. This would stop someone from successfully posting those type of URL based exploits. Those vars could just be nulled. Probably won't work but a shot in the dark. -- Lewis Bergman Texas Communications 4309 Maple St. Abilene, TX 79602 915-695-6962 |