7 ms·
> PHP already landed a change (which will ship with PHP 5.3.9) which will add a max_input_vars ini setting which defaults to 1000. This setting determines the m
by rufibarbatus 15y ago
> PHP already landed a change (which will ship with PHP 5.3.9) which will add a max_input_vars ini setting which defaults to 1000. This setting determines the maximum number of POST/GET variables that are accepted, so now only a maximum of 1000 collisions can be created.
Wait, where did we establish that less user input = less array insertions?
- pavel_lishin 15y agoWell, the point of that change was to prevent a hostile user from DoSing your server with malicious GET/POST requests. I imagine it would actually be fairly difficult to accidentally recreate this issue, or let it slip through testing. No amount of patches in the world will protect you from idiots with access to your codebase
- subwindow 15y agoI think the most obvious exploit path is using thousands of query parameters, which are inserted into an "array" in PHP. An ini setting seems like a terrible and incomplete fix to the problem.
- maratd 15y ago> An ini setting seems like a terrible and incomplete fix to the problem. Why? It solves the problem entirely.
- subwindow 15y agoIt only solves the exploit path, not the vulnerability. The true issue is that their hashing algorithm sucks. Any patch that doesn't fix the hashing algorithm is a band-aid and not a true fix.
- nikic 15y agoIt is somewhat risky to fundamentally change the hashing algorithm late in the release cycle (RC4). It is bound to cause problems. The ini-Option prevents the obvious threat without doing deep changes to the core.
- 1880 15y agoMaybe they're referring to the $_POST array? You can't fix that in your app code.