Hi!
> It's possible to design web pages/services to "unknown clients", but
> it's exceptional cases.
No, it's not. Every service exposed to the internet is for unknown clients.
> Almost all systems have intended clients. If protocol is HTTP/HTTPS,
> developers may reject strange data that cannot be right for
> HTTP/HTTPS. Even higher level than PHP does this. i.e. HTTP servers
> will rejects malformed and/or prohibited request and terminates
> execution. Web Application Firewall does more fancy things and
True, because we can have no PHP business logic that can work on HTTPS
level. We can have PHP business logic that works on PHP level though.
> validate/check, in general. IMHO, use of WAF is more burden and
> costly than the input validation that I'm proposing.
I'm not sure where WAF comes in - these are two completely different uses.
> Web application developers have right to define "valid" inputs. ("have
> right" does not mean "can do anything") PHP script termination for
> invalid input is just one of terminations. It's nothing special.
You can perfectly well have your app do anything you like - including
termination - on filter failure. I don't see how it necessitates making
new set of filters though?
> I think your premise is "Show nice error message for any errors,
> proceed as normal case". (Handle invalid/insane data just like mistakes)
>
> My premise is "Shouldn't show nice messages to attacker, terminate as
> abnormal case". (Treat them as attack or serious system bug)
>
> It's design choice. Either way is possible.
Sure, and it's possible with current filters too. If the check fails,
and you want to terminate, what prevents you from doing:
if(!filter_var($var, FILTER_VALIDATE_INT) === false) { exit(); }
Am I missing some important point here?
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
