Hi all
while looking at user preferences I've noticed that it uses serialize/unserialize for storing the data in database. As this functions is quite famous in terms of security, I think we should avoid this.
Any reason for not using json encoding there instead? It encodes just the data and would not possibly call PHP code as unserialize could do because of objects with __wakeup() methods.
Le 2011-02-09 05:28, Michal Čihař a écrit :
Hi all
while looking at user preferences I've noticed that it uses serialize/unserialize for storing the data in database. As this functions is quite famous in terms of security, I think we should avoid this.
Any reason for not using json encoding there instead? It encodes just the data and would not possibly call PHP code as unserialize could do because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature.
Hi
Dne Wed, 09 Feb 2011 05:31:19 -0500 Marc Delisle marc@infomarc.info napsal(a):
Le 2011-02-09 05:28, Michal Čihař a écrit :
Hi all
while looking at user preferences I've noticed that it uses serialize/unserialize for storing the data in database. As this functions is quite famous in terms of security, I think we should avoid this.
Any reason for not using json encoding there instead? It encodes just the data and would not possibly call PHP code as unserialize could do because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature.
I don't think we use that code in PHPExcel and TCPDF, however basically same what I wrote applies to tracking. Anyway now we have chance to make preferences use something safer, without hurting backward compatibility, with tracking it would be harder and some backward compatibility probably would have to be maintained.
To exploit this, somebody would have to write custom data to pmadb...
2011/2/9 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 09 Feb 2011 05:31:19 -0500 Marc Delisle marc@infomarc.info napsal(a):
Le 2011-02-09 05:28, Michal Čihař a écrit :
Hi all
while looking at user preferences I've noticed that it uses serialize/unserialize for storing the data in database. As this functions is quite famous in terms of security, I think we should avoid this.
Any reason for not using json encoding there instead? It encodes just the data and would not possibly call PHP code as unserialize could do because of objects with __wakeup() methods.
It's also used in PHPExcel, TCPDF and tracking feature.
I don't think we use that code in PHPExcel and TCPDF, however basically same what I wrote applies to tracking. Anyway now we have chance to make preferences use something safer, without hurting backward compatibility, with tracking it would be harder and some backward compatibility probably would have to be maintained.
To exploit this, somebody would have to write custom data to pmadb...
I think we can safely change user preferences to use json_encode/decode. It's a simpler and faster solution.
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I think we can safely change user preferences to use json_encode/decode. It's a simpler and faster solution.
I think as well, that's why I've opened this topic.
On 09-02-11 20:18, Michal Čihař wrote:
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I think we can safely change user preferences to use json_encode/decode. It's a simpler and faster solution.
I think as well, that's why I've opened this topic.
Using that should not pose a problem for user preferences.
As it's introduced in 3.4 the only problem would be preferences saved by a 3.4 beta version. Losing these would not be a huge issue, as long as log as pma does not feakout over 'corrupted' preference data.
W dniu 16 lutego 2011 17:07 użytkownik Herman van Rink rink@initfour.nl napisał:
On 09-02-11 20:18, Michal Čihař wrote:
Hi
Dne Wed, 9 Feb 2011 19:25:47 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
I think we can safely change user preferences to use json_encode/decode. It's a simpler and faster solution.
I think as well, that's why I've opened this topic.
Using that should not pose a problem for user preferences.
As it's introduced in 3.4 the only problem would be preferences saved by a 3.4 beta version. Losing these would not be a huge issue, as long as log as pma does not feakout over 'corrupted' preference data.
When json_decode() fails it does it silently and returns a null, we can check for it and return an empty array.
Hi
Dne Wed, 16 Feb 2011 17:25:26 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
When json_decode() fails it does it silently and returns a null, we can check for it and return an empty array.
Sounds good enough, can you please provide patch for the change.
2011/2/16 Michal Čihař michal@cihar.com:
Hi
Dne Wed, 16 Feb 2011 17:25:26 +0100 Piotr Przybylski piotr.prz@gmail.com napsal(a):
When json_decode() fails it does it silently and returns a null, we can check for it and return an empty array.
Sounds good enough, can you please provide patch for the change.
Pushed to master.
-
Herman van Rink -
Marc Delisle -
Michal Čihař -
Piotr Przybylski