Hi all,
I noticed the newly introduced warning that phpMyAdmin emits when Suhosin is enabled in PHP. I expect that Suhosin will be enabled more and more, because the demands on security of web applications are ever increasing. It provides valuable protection of PHP which doesn't have the best security history. For example Debian's next release will have Suhosin enabled by default, and other distributions are doing or have already done the same. So I doubt that adding such a warning is a viable solution to the problem.
The problem seems to be that when a table doesn't have a key defined, phpMyAdmin encodes the entire row in the request URL, in order to make sure to match the right row. Suhosin trips over this when that URL gets very long.
I propose to resolve this problem in a different way. Wouldn't it be an idea to take the contents of the entire row, run it through md5() or sha1(), and pass that in the URL? This value could then in the query be used when specifying something like "WHERE MD5(CONCAT(field1,field2,field3)) = url_submitted_md5"? This would, in my opinion, resolve the problem in a more elegant way that works for all configurations. Even when not having Suhosin enabled, passing an URL of many kilobytes long isn't desirable anyway.
Of course you could only do this when the row length exceeds some minimum length if you want to.
What do you think?
Thijs
Thijs Kinkhorst schrieb:
Hi all,
I noticed the newly introduced warning that phpMyAdmin emits when Suhosin is enabled in PHP. I expect that Suhosin will be enabled more and more, because the demands on security of web applications are ever increasing. It provides valuable protection of PHP which doesn't have the best security history. For example Debian's next release will have Suhosin enabled by default, and other distributions are doing or have already done the same. So I doubt that adding such a warning is a viable solution to the problem.
The problem seems to be that when a table doesn't have a key defined, phpMyAdmin encodes the entire row in the request URL, in order to make sure to match the right row. Suhosin trips over this when that URL gets very long.
I propose to resolve this problem in a different way. Wouldn't it be an idea to take the contents of the entire row, run it through md5() or sha1(), and pass that in the URL? This value could then in the query be used when specifying something like "WHERE MD5(CONCAT(field1,field2,field3)) = url_submitted_md5"? This would, in my opinion, resolve the problem in a more elegant way that works for all configurations. Even when not having Suhosin enabled, passing an URL of many kilobytes long isn't desirable anyway.
Of course you could only do this when the row length exceeds some minimum length if you want to.
What do you think?
especially on shared hosters, where the most 'bad' database structure will exist, this could have very heavy impact on performance of the MySQL server, or?
On Tue, March 4, 2008 12:35, Sebastian Mendel wrote:
especially on shared hosters, where the most 'bad' database structure will exist, this could have very heavy impact on performance of the MySQL server, or?
I'm not backed by any facts. but my common sense says that parsing a many-kB long request uri should at the very least be comparable to calculating an md5 sum. Note also that on the total use of the database, editing or deleting these rows are relatively rare operations.
Thijs
Thijs Kinkhorst schrieb:
On Tue, March 4, 2008 12:35, Sebastian Mendel wrote:
especially on shared hosters, where the most 'bad' database structure will exist, this could have very heavy impact on performance of the MySQL server, or?
I'm not backed by any facts. but my common sense says that parsing a many-kB long request uri should at the very least be comparable to calculating an md5 sum.
parsing ONE "many-kB long request uri"
vs.
calculating MD5 for EVERY row in the table ... (or at least till the offending was found)
and what about normal tables with many fields or large text fields (when inserting or editing)?
Note also that on the total use of the database, editing or deleting these rows are relatively rare operations.
"these rows"? why do you think someone will edit or delete "these rows" less than any other row?
Thijs Kinkhorst a écrit :
Hi all,
I noticed the newly introduced warning that phpMyAdmin emits when Suhosin is enabled in PHP. I expect that Suhosin will be enabled more and more, because the demands on security of web applications are ever increasing. It provides valuable protection of PHP which doesn't have the best security history. For example Debian's next release will have Suhosin enabled by default, and other distributions are doing or have already done the same. So I doubt that adding such a warning is a viable solution to the problem.
The problem seems to be that when a table doesn't have a key defined, phpMyAdmin encodes the entire row in the request URL, in order to make sure to match the right row. Suhosin trips over this when that URL gets very long.
I propose to resolve this problem in a different way. Wouldn't it be an idea to take the contents of the entire row, run it through md5() or sha1(), and pass that in the URL? This value could then in the query be used when specifying something like "WHERE MD5(CONCAT(field1,field2,field3)) = url_submitted_md5"? This would, in my opinion, resolve the problem in a more elegant way that works for all configurations. Even when not having Suhosin enabled, passing an URL of many kilobytes long isn't desirable anyway.
Of course you could only do this when the row length exceeds some minimum length if you want to.
What do you think?
Thijs
Thanks Thijs for this idea. I think we could implement it (at least try it) for performance purposes, but I am afraid that the warning about Suhosin in general must remain.
Even on a table with a primary key, if the table has many fields and you want to do a simple INSERT, the suhosin.post.max_vars threshold may be reached.
http://forum.hardened-php.net/viewtopic.php?pid=1444
Or the suhosin.post.max_value_length when uploading a file to a BLOB.
Marc
Maybe a value could be set in the config file, e.g., $cfg['maxSuhosinLength'] = 1000; and the warning only be triggered when a $_POST/GET possibly will reach that limit?
Then could someone please check whether
ini_set('suhosin.request.max_vars', $GLOBALS['cfg']['maxSuhosinLength']);
has the desired effect (I don't have access to a suhosin protected box):
Jürgen
Jürgen Wind a écrit :
Maybe a value could be set in the config file, e.g., $cfg['maxSuhosinLength'] = 1000; and the warning only be triggered when a $_POST/GET possibly will reach that limit?
Then could someone please check whether
ini_set('suhosin.request.max_vars', $GLOBALS['cfg']['maxSuhosinLength']);
has the desired effect (I don't have access to a suhosin protected box):
Jürgen
Sorry, it does not work. Changing these is restricted to php.ini.
Marc
Marc Delisle wrote:
Jürgen Wind a écrit :
Maybe a value could be set in the config file, e.g., $cfg['maxSuhosinLength'] = 1000; and the warning only be triggered when a $_POST/GET possibly will reach that limit?
Then could someone please check whether
ini_set('suhosin.request.max_vars', $GLOBALS['cfg']['maxSuhosinLength']);
has the desired effect (I don't have access to a suhosin protected box):
Jürgen
Sorry, it does not work. Changing these is restricted to php.ini.
Marc
but ini_get('suhosin...') could be used to warn users only if neccessary, couldn't it?
Jürgen Wind a écrit :
Marc Delisle wrote:
Jürgen Wind a écrit :
Maybe a value could be set in the config file, e.g., $cfg['maxSuhosinLength'] = 1000; and the warning only be triggered when a $_POST/GET possibly will reach that limit?
Then could someone please check whether
ini_set('suhosin.request.max_vars', $GLOBALS['cfg']['maxSuhosinLength']);
has the desired effect (I don't have access to a suhosin protected box):
Jürgen
Sorry, it does not work. Changing these is restricted to php.ini.
Marc
but ini_get('suhosin...') could be used to warn users only if neccessary, couldn't it?
It could, but I'm afraid that on a shared server, showing such warnings (just if necessary) to end users is not the optimal solution. They might not be the ones who can adjust Suhosin.
This is, assuming we can find every place where such warnings are appropriate.
Hi
On Tue, 4 Mar 2008 11:40:41 +0100 (CET) "Thijs Kinkhorst" thijs@debian.org wrote:
I noticed the newly introduced warning that phpMyAdmin emits when Suhosin is enabled in PHP. I expect that Suhosin will be enabled more and more, because the demands on security of web applications are ever increasing. It provides valuable protection of PHP which doesn't have the best security history. For example Debian's next release will have Suhosin enabled by default, and other distributions are doing or have already done the same. So I doubt that adding such a warning is a viable solution to the problem.
Even if we find a solution for tables without indexes, the warning will have to stay there. For example if you edit several rows from table, you can quite easily reach limit for number of parameters or request size and there is no workaround for this.
The problem seems to be that when a table doesn't have a key defined, phpMyAdmin encodes the entire row in the request URL, in order to make sure to match the right row. Suhosin trips over this when that URL gets very long.
I propose to resolve this problem in a different way. Wouldn't it be an idea to take the contents of the entire row, run it through md5() or sha1(), and pass that in the URL? This value could then in the query be used when specifying something like "WHERE MD5(CONCAT(field1,field2,field3)) = url_submitted_md5"? This would, in my opinion, resolve the problem in a more elegant way that works for all configurations. Even when not having Suhosin enabled, passing an URL of many kilobytes long isn't desirable anyway.
Of course you could only do this when the row length exceeds some minimum length if you want to.
I think this is a good idea how to handle tables without primary key.
-
Jürgen Wind -
Marc Delisle -
Michal Čihař -
Sebastian Mendel -
Thijs Kinkhorst