Bug #76671 [Nab]: bypass strpos verification

Edit report at https://bugs.php.net/bug.php?id=76671&edit=1 ID: 76671 Updated by: yohgaki@php.net Reported by: guilhermeassmannn at gmail dot com Summary: bypass strpos verification Status: Not a bug Type: Bug Package: Strings related Operating System: MacOS High Sierra & Ubuntu 16.04 PHP Version: Irrelevant Block user comment: N Private report: N New Comment: In general, multiple decodes should not be done for security reasons. I don't see problematic multiple decodes in this script, but I see improper validation. i.e. URL protocol must be validated always by whitelist and URL decoded value $x must not include % almost always by whitelist. If pathname that has '%' is allowed by app spec, the programmer must implement proper validation for it by themselves. "Security feature/software/code" is not "Software security". i.e. Developers must establish "Software security" by their own. This is good example. Previous Comments: ------------------------------------------------------------------------ [2019-01-28 06:47:34] spam2 at rhsoft dot net yes, in front of the keyboard when use low-level string functions for things they are not made for ------------------------------------------------------------------------ [2019-01-28 05:41:55] aa963577242 at gmail dot com ok,,,,,,,i am sorry, i think this is not strpos function bug,but this is another bug...... ------------------------------------------------------------------------ [2019-01-28 05:29:16] aa963577242 at gmail dot com who say this is not bug. i just say you don't know web security.-_- ------------------------------------------------------------------------ [2018-07-27 11:29:26] rasmus@php.net Of course not, but strpos() can't possibly know what sort of context your string is going to be used in. Only you know it is a URL. In this particular case you could simply check for '%' and urldecode() until they are gone. eg. while(strstr($url,'%')) $url = urldecode($url); ------------------------------------------------------------------------ [2018-07-27 10:24:21] a at b dot c dot de Well, you shouldn't be trying to prevent attacks by second-guessing what an attacker might do. Instead of *forbidding* certain requests, only *allow* requests that you know are safe. ------------------------------------------------------------------------ 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=76671 -- Edit this bug report at https://bugs.php.net/bug.php?id=76671&edit=1