Req #60655 [Opn]: add max_input_vars for json/serialize
| From: | laruence@php.net | Date: | Thu, 05 Jan 2012 14:47:22 +0000 |
| Subject: | Req #60655 [Opn]: add max_input_vars for json/serialize | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-166245@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1
ID: 60655
Updated by: laruence@php.net
Reported by: laruence@php.net
Summary: add max_input_vars for json/serialize
Status: Open
Type: Feature/Change Request
Package: *General Issues
PHP Version: 5.3.9RC4
Block user comment: N
Private report: N
New Comment:
sesser, I am not good at algorithm, so if you can help me, I will appreciate.
just a guess, what about change the zend_hash_func, add some new seed like:
register ulong hash = 5381 + nKeyLength;
thanks
Previous Comments:
------------------------------------------------------------------------
[2012-01-05 14:44:32] sesser@php.net
It is not "a theory", The whole disclosure from n-runs was about colliding the DJB
hash function with alpha numerical keys.
------------------------------------------------------------------------
[2012-01-05 14:14:08] laruence@php.net
<laruence> I got you point, and agree in theory, yes, the string hash value could
be the same, does anyone have a method to compute it in real?
<nikic> yes
<laruence> I really doubt that if we can find so many string keys with the same
hash value to be able launch a attach, and won't reach the max post size
------------------------------------------------------------------------
[2012-01-05 14:05:52] laruence@php.net
oh, I got you, thanks.
------------------------------------------------------------------------
[2012-01-05 14:04:50] laruence@php.net
yes, the hash value of string index is the same, but the index = hash_value %
nTableSize,
we don't use the hash value as index directly,
didn't I misunderstand you?
------------------------------------------------------------------------
[2012-01-05 11:53:37] sesser@php.net
You are mistaken to believe that randomizing the TableSize will stop predictable
collisions: This is only true if you try to exploit the problem with numerical
indicies.
The moment you use alpha numerical keys and produce collisions in the DJB
hashing function the table size does not matter anymore, because the return
value of the hash function is the same.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=60655
--
Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1