[Phpmyadmin-devel] unserialize in user preferences
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. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
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. -- Marc Delisle http://infomarc.info
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... -- Michal Čihař | http://cihar.com | http://blog.cihar.com
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. -- Piotr Przybylski
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. -- Michal Čihař | http://cihar.com | http://phpmyadmin.cz
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. -- Met vriendelijke groet / Regards, Herman van Rink Initfour websolutions
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. -- Piotr Przybylski
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. -- Michal Čihař | http://cihar.com | http://blog.cihar.com
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. -- Piotr Przybylski
participants (4)
-
Herman van Rink -
Marc Delisle -
Michal Čihař -
Piotr Przybylski