Hi! > Even when there is no JavaScript nor HTML5 forms, input validations > can be done. It's matter of definition of "valid inputs" for <input > type="text" name="var" />. If page encoding is UTF-8, web browsers > must return response by UTF-8 encoding. (Unless other encoding is
I think you're still missing my point. The point is that it is absolutely irrelevant what browser might or might not do, since PHP does not have any means to know if browsers even exist. PHP doesn't talk to browser, it talks to HTTP channel (provided we're in webserver scenario), what's on the other end is unknown and irrelevant. So there's no point discussing browsers. > We recently added number of > php_error_docref(E_ERROR, "Cannot process too large data"); > in PHP core to avoid possible memory destruction attacks. We added it because we didn't have choice. PHP does not have generic error mechanism that allows to fail an arbitrary function and still continue execution. It's because PHP is highly complex C code and C is not the most friendly language out there. Your app is not in C, so it can do it differently. If you talk about such situations, fine, but it's not input validation - it's limitation of the environment (since PHP can't support arbitrary length string). If your application has such limitations - fine, but it would be application-defined and will not apply for most cases of input validation. > Broken char encoding shouldn't came from legitimate users. Text > contains CNTRL chars from <input type="text" name="var" /> shouldn't > come from legitimate users. 1MB data from <input type="text" > name="var" /> shouldn't come from legitimate users. Numeric database > record ID that is set by app shouldn't contain anything other than > digits. And so on. I think you are mixing abnormal situations due to physical limitations of software (like memory limits, etc.) with business logic. Numeric format validation and size limits are clearly business logic. Encoding may be not, depending on what the input is and used for. > Broken char encoding (Accept only valid encoding) > NUL, etc control chars in string. (Accept only chars allowed) > Too long or too short string. e.g. JS validated values and values set > by server programs like <select>/<input type=radio>/etc, 100 chars for > username, 1000 chars for password, empty ID for a database record, > etc. (Accept only strings within range) These all fine filters/validators, and may be very useful in many situations. What I still don't understand is insistence of application dropping everything and exiting when one of them fails. We already have sanitization/filtering infrastructure, we can add new filters and flags - what I don't understand, why we need parallel infrastructure which seems to be only different by an unhelpful feature of crashing each time it sees something unexpected. Am I missing something? > How to deal with bad inputs. > - You seem you would like to treat as normal input. No, you didn't understand. I would like to treat is as erroneous input, but not stop the application immediately, but return error status to the business logic and let it sort things out. > When plain <input> is used, users may type in any valid UTF-8 char by mistake. > For example, this wouldn't happen for date field, but autocomplete may > fill my name "大垣靖男" to name field that supposed to contain alphabets > only. If the software is properly internationalized (like my email client) there's absolutely nothing wrong with this string. If it is not, it should check that the text matches its expectations - that's part of business logic. > If developers try to validate "all inputs", validation in MVC model is > not efficient nor reasonable. It does not make sense to validate > browser request headers in db model, for example. Ideally, input > validation is better to be done as fast as possible to maximize the > mitigation effect. If you use browser headers, you validate them. If you don't use them, no point validating them, of course, since they are not your inputs. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
