Hi Lester, On Tue, Sep 6, 2016 at 4:59 PM, Lester Caine <les...@lsces.co.uk> wrote: > On 06/09/16 03:19, Yasuo Ohgaki wrote: >> Hi Lester, >> >> On Fri, Sep 2, 2016 at 7:58 PM, Lester Caine <les...@lsces.co.uk> wrote: >>> A filter of "is this string corrupted with an injection attempt" seems >>> rather more difficult to define than "email"? And applying the first in >>> general on every string when there are as set of simple filters that can >>> be used ... as an alternative to the more difficult to define ones? >> >> Input validation code does not have to address all of injections. It's >> output code responsibility to prevent injections in the first place. >> i.e. Top 10 Secure Coding Practices - #7 >> https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices > > Your statement and those coding points don't go together. > 1 ... Any input to PHP has to be untrusted since you can't rely on even > clean sources being intercepted. > 8 ... Why not use the best available checks on the input side? > 7 ... I've sanitised the data in the browser, but because of morons I > can't use it without addressing 1 and 8.
Software that are executed by other process and/or computer is outside of the software you're trying to protect. All other softwares that are executed by other processes/computers shouldn't be trusted even if it is written by you. Rule #8 is for multiple layer protections. It's for fail safe. I think you're familiar with defense in depth approach in network security. e.g. Protect overall network via internet firewall, protect service network via firewall, protect clients via client firewall. Software architecture could be like network systems. https://wiki.php.net/_detail/rfc/screenshot_from_2016-08-05_11-25-01.png?id=rfc%3Aadd_validate_functions_to_filter i.e. Protect application via application input validations, protect module via module validations, protect function/method via function/module validations. If you validate everything, software will be more secure, but it could be executed very slow due to repetitive/excessive validations. That's the reason why DbC validate everything (check every contract) during development, but doesn't validate everything for production environment. Removing all validations is risky. Therefore, we need to keep important validations in software for production environment. Application level validations (contracts) cannot be removed obviously, critical code such as command execution is better to keep validation active. > All this comes back to my simple idea of adding all these validation, > filtering and sanitation steps wrapped around the basic PHP variable. > And THAT also includes 'strict typing' since if we have the option to > select soft or hard failure when a problem is found in the variable we > can cover everybody’s 'need'! Forcing data type is "Weak form of validation". Data types forces (≒ validates) certain form. In spite of that forcing data type is valuable for security because programmers are tends to expect int/float to have numeric data representation. However, strict data typing is not enough obviously. It does not force certain form to "string", certain range of value to "int"/"float". String is the most dangerous data, yet it is not covered by data typing. Therefore, strict data typing is weak and secure coding specialists recommends validation for strongly typed languages, too. > >> Nonetheless, ID validation being poor is not rare even with well >> known code. parameters like ID is easy to make sure it's safe from any >> injections. >> e.g. https://groups.google.com/forum/#!topic/rubyonrails-security/ly-IH-fxr_Q > > I know the range of values available for 'id' it's provided by the > SEQUENCE source in the database but if you insist on 'autoinc' we can do > the job properly. So my filter on the variable :id is looking for a > number in a range. What could be a simpler validation than that? The example vulnerability is in Action Pack. ID does not have to be numeric ID, yet some users (including Rails developer I suppose) are blindly assume it's numeric. If users are deploying proper validation and reject malformed ID, they could avoid arbitrary code execution by malformed ID. We know there are countless vulnerabilities that are similar to this. > >> ID is not the only one, accept language, encoding, referer, etc are >> common source of injections also. >> >> Input validation code is for mitigation against unknown/unaddressed >> vulnerabilities in entire code not only PHP code, but also language, >> libraries written by C/C++ and/or external systems such as DB. > > If you need to retain the raw input of non-php material then that is > just a more complex filter. Point 5 above - Default Deny - do not > forward anything that you do not need. So once you have applied rule 9, > and assured you know what you expect to receive, then only that is > passed on to rule 8. If that data being passed on has a potential to > carry a vulnerability forward it's because you have to allow for that > data to be forwarded anyway, so a filter to prevent it is pointless? It's not pointless as I described above. I guess you are feeling secure coding is inefficient and repetitive. However, this is the whole point of secure coding. We have to admit that "people do mistakes". To build secure software, we need multiple layer of protections. Input and output control is the most important. http://cwe.mitre.org/top25/#Mitigations #1 - Input control #2 - Output control Validations make software more maintainable, i.e. mistakes can be found by validations in module/method/function, and more secure, i.e. most vulnerabilities are due to unexpected input data. If data is supposed to have certain form, it should be validated as soon as possible to make software works correctly. The reason why DbC can help securing code is "it can strictly force data/object domain during development". What's missing is runtime rule/validation to force input data domain. The proposed validator can be used to specify "form" of input data at runtime. Therefore the validator is mandatory. "Logical consistency" should be handled by models at runtime. It may differ from your software security model. Programmers are free to choose which model to adopt. However, one shouldn't disturb mandatory tool implementation for recommended security model by secure coding specialists, IMHO. If you don't like/need it, it's free not to using it after all. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
