Ok, I am getting lost in all those threads. I guess it's time to vote. I'll try to summarize the issues:
- remove grab_globals, moving the GLOBALS overwrite protection into common.lib.php
- everywhere in the code, find the variables that were set from grab_globals and replace them by $_REQUEST['foo'] if they originated from GET, POST or COOKIE, or by a reference to $_FILES, $_ENV or $_SERVER. Possibly taking into account that $_ENV might not be readable (use of getenv() ?)
- sanitize individually what can be echoed (like $message) with PMA_sanitize(), for XSS protection. Any need to sanitize something else?
- (later) in an effort to clean global space, replace $str by constants
Comments, please :)
Marc
On Thu, 08 Dec 2005 11:49:45 -0500 Marc Delisle Marc.Delisle@cegepsherbrooke.qc.ca wrote:
Ok, I am getting lost in all those threads. I guess it's time to vote. I'll try to summarize the issues:
- remove grab_globals, moving the GLOBALS overwrite protection into
common.lib.php
Okay.
- everywhere in the code, find the variables that were set from
grab_globals and replace them by $_REQUEST['foo'] if they originated from GET, POST or COOKIE, or by a reference to $_FILES, $_ENV or $_SERVER. Possibly taking into account that $_ENV might not be readable (use of getenv() ?)
Yes, getenv should be safer choice.
- sanitize individually what can be echoed (like $message) with
PMA_sanitize(), for XSS protection. Any need to sanitize something else?
IMHO not.
- (later) in an effort to clean global space, replace $str by constants
Okay.
Hi!
- remove grab_globals, moving the GLOBALS overwrite protection into
common.lib.php
+0 :)
- everywhere in the code, find the variables that were set from
grab_globals and replace them by $_REQUEST['foo'] if they originated from GET, POST or COOKIE, or by a reference to $_FILES, $_ENV or $_SERVER. Possibly taking into account that $_ENV might not be readable (use of getenv() ?)
+1
- sanitize individually what can be echoed (like $message) with
PMA_sanitize(), for XSS protection. Any need to sanitize something else?
I'm +1 for sanitizing all output depending on whether HTML is allowed or not. However I admit I haven't looked at the current code for ages. :(
- (later) in an effort to clean global space, replace $str by constants
+1
Regards, Garvin
On Thu, 8 Dec 2005 20:44:43 +0100 (CET) "Garvin Hicking" phpmyadmin@supergarv.de wrote:
- sanitize individually what can be echoed (like $message) with
PMA_sanitize(), for XSS protection. Any need to sanitize something else?
I'm +1 for sanitizing all output depending on whether HTML is allowed or not. However I admit I haven't looked at the current code for ages. :(
You can not do any sanitizing on data inserted to MySQL - field values, SQL commands etc. ... And that's most of data we handle ;-).
Hi!
I'm +1 for sanitizing all output depending on whether HTML is allowed or not. However I admit I haven't looked at the current code for ages. :(
You can not do any sanitizing on data inserted to MySQL - field values, SQL commands etc. ... And that's most of data we handle ;-).
I was speaking of the output of strings, not the "input". When we display the SQL commands to the user, we should be able to apply htmlspecialchars, right?! [In this case I think we're doing it allready, but how I understood Marc, he wanted to make sure that we always do that]
Regards, Garvin
Marc Delisle schrieb:
Ok, I am getting lost in all those threads. I guess it's time to vote. I'll try to summarize the issues:
- remove grab_globals, moving the GLOBALS overwrite protection into
common.lib.php
+1
- everywhere in the code, find the variables that were set from
grab_globals and replace them by $_REQUEST['foo'] if they originated from GET, POST or COOKIE, or by a reference to $_FILES, $_ENV or $_SERVER. Possibly taking into account that $_ENV might not be readable (use of getenv() ?)
+1
- sanitize individually what can be echoed (like $message) with
PMA_sanitize(), for XSS protection. Any need to sanitize something else?
use htmlspecialchars() and PMA_sanititze() only if html tags allowed
- (later) in an effort to clean global space, replace $str by constants
0
i dont know, i have no knowledge about the difference how variables and constants handled by PHP
i dont think that this gives performance boost, as not like in other languages constants defined first and than replaced in code before compiling!
i know the disadvantage of a function i suggested, but using a function is much more flexible, f.e. in case of errors or reformating, more felxible than sprintf()
it would be possible to load only contextual strings, not with current lang files, but possible later with optionally in db saved strings with context information
and i dont know if it is a good practice to use constants for strings
On Sat, 10 Dec 2005 20:51:57 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
Marc Delisle schrieb:
- sanitize individually what can be echoed (like $message) with
PMA_sanitize(), for XSS protection. Any need to sanitize something else?
use htmlspecialchars() and PMA_sanititze() only if html tags allowed
Yes.
- (later) in an effort to clean global space, replace $str by constants
0
i dont know, i have no knowledge about the difference how variables and constants handled by PHP
i dont think that this gives performance boost, as not like in other languages constants defined first and than replaced in code before compiling!
i know the disadvantage of a function i suggested, but using a function is much more flexible, f.e. in case of errors or reformating, more felxible than sprintf()
Function is flexible, however I'm afraid of performance impacts. When we want to avoid having strings in global namespace, I see only fast solution with constants.
it would be possible to load only contextual strings, not with current lang files, but possible later with optionally in db saved strings with context information
What would be reason to store strings in DB?
and i dont know if it is a good practice to use constants for strings
Why not?
Michal Čihař schrieb:
it would be possible to load only contextual strings, not with current lang files, but possible later with optionally in db saved strings with context information
What would be reason to store strings in DB?
DB was only an example ... you could set the strings into context, f.e. not always loading strings for server status
only load the strings needed on page
PMA_str_load('main');
loads only strings needed in main and makes them available, as constants or whatever
additionally you could use
PMA_str() to retrieve strings not in current context but needed, f. e. in case of an error
i do not say that it is necessary to make a function call for every single string
and i dont know if it is a good practice to use constants for strings
Why not?
i dont know ... ;-)
On Sun, 11 Dec 2005 18:47:54 +0100 Sebastian Mendel lists@sebastianmendel.de wrote:
DB was only an example ... you could set the strings into context, f.e. not always loading strings for server status
only load the strings needed on page
PMA_str_load('main');
loads only strings needed in main and makes them available, as constants or whatever
I don't see much benefit of this. This would mean to split files into smaller ones, what means more maintenance. For most things splitting will be tricky or will end in main category.
-
Garvin Hicking -
Marc Delisle -
Michal Čihař -
Sebastian Mendel