Hello,
I think the second argument of parse_str/mb_parse_str
should be changed from optional to mandatory.
parse_str(string encoded_string [, array result])
-> parse_str(string encoded_string , array result)
It is to reduce the risk of vulnerability, and it has neary same risk
as register_globals which is removed from PHP 5.4.
The vulnerability against code injection attack found in a recent
version of
phpMyAdmin is just a example.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2505
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-2506
The current implementation of parse_str changes
the active symbol table in the function.
I think that it has the possible security risk like,
http://www.php-security.org/MOPB/MOPB-26-2007.html
The side effect is that thhe old code like parse_str($query_string) should
be changed, but, I think it is good direction to improve the security.
Rui
--
Rui Hirokawa <hirokawa@php.net
Hi!
I think the second argument of parse_str/mb_parse_str
should be changed from optional to mandatory.
This would create BC problems.
You can mess up you code with any function, I do not think it warrants
BC break.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Am 11.09.2011 06:31, schrieb Rui Hirokawa:
Hello,
I think the second argument of parse_str/mb_parse_str
should be changed from optional to mandatory.
parse_str(string encoded_string [, array result])
-> parse_str(string encoded_string , array result)
no because there is no reason and all what will happen is
parse_str($a, $b);
extract($b);
so please leave us in peace with the need to add the second line
It is to reduce the risk of vulnerability, and it has neary same risk
as register_globals which is removed from PHP 5.4
it has not, inside a function this is absolutely safe and if
you are writing spaghetti-code nothing can help you