Re: Re: [RFC][VOTE] Add validation functions to filter module
| From: | Christoph M. Becker | Date: | Tue, 16 Aug 2016 09:01:40 +0000 |
| Subject: | Re: Re: [RFC][VOTE] Add validation functions to filter module | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-95227@lists.php.net to get a copy of this message | ||
Hi!
On 16.08.2016 at 08:42, Stanislav Malyshev wrote:
>> Yasuo (who Dan quoted here) refers to completely invalid input, such as
>> invalid UTF-8 byte sequences. I think, that in this case the app should
>> bail out without even given detailed information, as such grossly
>> invalid input most likely is an attempt to attack (or a severe browser bug).
>
> I personally am not a big fan of "bail out without giving information",
> unless that information somehow crosses security boundary (e.g.
> displaying PHP error messages in production) or reveals unnecessary info
> (this part is super-tricky in crypto, but ouside of crypto common sense
> is usually not a bad guide).
>
> <snip>
>
> Now, how much easier your life would be if you app would just report
> "invalid UTF-8 sequence encountered in parameter FirstName" before
> bailing out? How many hours, pulled out hairs and 4am sessions would it
> save? I think it's worth considering.
I once introduced a check erroring with "Malformed UTF-8 detected" to a
CMS. Until that was changed to "Bad request. Please <a href=".">try
again</a>.", we got a lot of support requests from confused users who
had bookmarked URLs with ISO-8859-* query strings. Even pointing out
which parameter was the culprit, wouldn't have changed that, I presume.
Of course, it makes sense to *log* very detailed information in this
case (amongst others, the byte sequence that was malformed), but
presenting them to visitors doesn't seem to be helpful – most of these
wouldn't even know what UTF-8 is.
--
Christoph M. Becker