4 ms·
> PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely Every language phasing the web is
by tored 5y ago
> PHP encourages 'stringly typed programming', which makes SQL injection and cross-site-scripting vulnerabilities more likely
Every language phasing the web is stringly typed, I have seen unproper filtering and escaping in all languages I worked professionally with.
- chriswarbo 5y ago> Every language phasing the web is stringly typed Heh, not even close. Off the top of my head I can think of Ur/Web as an extreme example ( http://www.impredicative.com/ur http://www.impredicative.com/ur ), and slightly more mainstream systems like Yesod ( https://www.yesodweb.com https://www.yesodweb.com ). I've worked professionally with Haskell, although not for Web stuff. These days I mostly work with Scala, which has a similar typing mindset to ML/Haskell, but unfortunately inherits a lot of stringly typed legacy from Java. We use an in-house library that provides zero-cost newtypes to distinguish between different semantically-distinct data types, many of which just-so-happen to be representable as subsets of String (e.g. GET parameter names, GET parameter values, POST bodies, etc.). This makes it a type error to try and e.g. concatenate different sorts of data together. W.r.t. "escaping", I tend to avoid it entirely since it's inherently unsafe: - "Escaping" doesn't distinguish between its input and output types; they're both just "String", and we have to make assumptions about the contents of each (i.e. it's unsafe) - Having the same input and output types makes it possible to "double-escape" by accident. This discourages the use of escaping, just-in-case it happens to be done elsewhere; hence it's very common to end up without any escaping taking place. - Having the same input and output types makes escaping functionally unnecessary: anything we do to an escaped string could also be done to an unescaped string, so it's up to us to remember that it's needed (i.e. it's unsafe). The whole idea of "escaping a string" betrays a flawed approach to the problem. Instead of throwing everything into the same representation, then manually trying to figure out whether or not a value comes from a particular subset of that representation or not, it's much easier and safer to avoid lumping them all together in the first place. If our inputs have a certain type (e.g. HTTP.Get.Val) and we can only output certain other types (e.g. JSON, Map[HTTP.Header.Key, HTTP.Header.Val], etc.), then the processing which turns input into output is forced to specify any necessary conversions. Whilst such conversions may involve escape sequences, having them associated to particular types is more akin to serialisation. Heck, at my first PHP job we largely solved this problem not by 'filtering and escaping', but by modifying the PHP interpreter to distinguish between 'clean' and 'dirty' strings (with literals being clean, and $_GET, etc. being dirty). Operations like concatenation would propagate 'dirtiness', and output functions like 'echo' would crash if given a dirty string. Traditional 'escaping' functions would convert dirty strings to clean ones, and crash when given a clean string. Having this be dynamic was more annoying than ahead-of-time compile errors, but it still did a pretty good job. There's pretty much no excuse for stringly typed languages/libraries/etc. when such such trivial solutions exist, other than the historical inertia of legacy systems.
- tored 5y agoWeb consists of strings, not types. Somewhere in your pipeline you have string-to-type, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go string-to-type than others, but I can do all of that in PHP by creating my own types too.
- chriswarbo 5y agoWeb consists of bytestreams, not strings. Somewhere in your pipeline you have bytestream-to-string, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go bytestream-to-string than others, but I can do all of that in PHP by creating my own types too. --- Web consists of bitstreams, not bytestreams. Somewhere in your pipeline you have bitstreams-to-bytestreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go bitstreams-to-bytestreams than others, but I can do all of that in PHP by creating my own types too. --- Web consists of voltage fluctuations, not bitstreams. Somewhere in your pipeline you have voltage-fluctuations-to-bitstreams, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go voltage-fluctuations-to-bitstream than others, but I can do all of that in PHP by creating my own types too. --- Web consists of excitations of the electromagnetic field, not voltage fluctuations. Somewhere in your pipeline you have excitations-of-the-electromagnetic-field-to-voltage-fluctuation, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go excitations-of-the-electromagnetic-field-to-voltage-fluctuations than others, but I can do all of that in PHP by creating my own types too. --- Web consists of entanglement of energy quanta, not excitations of the electromagnetic field. Somewhere in your pipeline you have entaglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field, if you don't do that correctly you will either have data loss, injection or xss, true for every language. It is true that some languages makes it easier to go entanglement-of-energy-quanta-to-excitations-of-the-electromagnetic-field than others, but I can do all of that in PHP by creating my own types too. --- ...