3 ms·

"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable

"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.

jstimpfle 4y ago
You don't understand what I said. I say, don't make assumptions unless you need them. Formatting an email address in an HTML document would work by wrapping it in the appropriate tag. (which implies html-quoting it correctly, but that is unrelated to email syntax). Sending an email using an API would work by passing the email as a string to the API. Looking up an email address from an address book using a pattern to match would be implemented with normal text search. It doesn't matter if the email is "valid" or not. Don't overthink it.
afiori 4y ago
SQL injection, XSS, and similar attacks are about incorrectly encoding embedded fragments. The solution is either not to embed (SQL parameter bindings) or to always escape embedded fragments based on the embedding context For reference: The Last XSS Defense Talk - Jim Manico - NDC Porto 2022 | https://youtu.be/wRC7jyhTkEM https://youtu.be/wRC7jyhTkEM
xigoi 4y ago
You don't avoid injection attacks by validation, but by escaping.
- rowanG077 4y ago
  escaping requires validation. You don't know what to escape if you aren't allowed to validate.
  - jstimpfle 4y ago
    You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.
    - rowanG077 4y ago
      HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.
      - xigoi 4y ago
        You seem to have a weird definition of “validation”.
      - jstimpfle 4y ago
        So you're "validating" symbols now (strange choice of word). But certainly validating that the higher-level construct that we're escaping is an email address. Because the escaping procedure doesn't care.
        rowanG077 4y ago
        Validating is just the process of ensuring an input is admissible in the way you want to use it. That can be symbols in a string, whether a string is an e-mail or even if a number is in a certain range. Escaping is just validation + fixup which can be used in some cases. Anyway the only way to validate an e-mail in practice is to use it and confirm.
        jstimpfle 4y ago
        > Escaping is just validation + fixup You're confused and annoyingly persistent. Escaping (or quoting in general) is a simple translation from a literal representation of a string to a (lexical) syntax representation with the purpose of embedding the string in an external medium (e.g. source code written in that lexical syntax). Escaping is a mechanical process that doesn't discriminate between "valid" and "invalid". It is completely ignorant to the higher-level meaning of the string that is translated (e.g. email address) but solely operates on the constituent characters. That is in contrast to validation, which is a simple function that decides whether a given object is admissible or not (as you say yourself). "Admissible" here is in with respect to a meaning that is higher-level than lexical syntax. It is semantic (is this a valid email), not syntactic. (There are sometimes certain technical restrictions on which values can be represented in a lexical syntax, for example hard limits on string lengths. So there is a small extent to which "validation" can fill a purpose with relation to lexical syntax, too - but that's not what we're discussing). To make it even more confusing, email addresses conform to a (albeit poorly specified) lexical syntax, too. And you can certainly attempt to validate if a given string is valid email address. However, HTML syntax doesn't care about that. Email address syntax is not part of the HTML syntax. HTML specifies how to escape _strings_, not email addresses. And HTML syntax is right not caring about email syntax because it would be unnecessary complication in practice. Just as the other examples I gave. E.g. looking up email addresses from an address book is not a task that in practice needs to be more specific than looking up a string from a list of strings. > Anyway the only way to validate an e-mail in practice is to use it and confirm. Which was my initial statement "Just use it" that you heavily disagreed with.

jstimpfle 4y ago

You don't understand what I said. I say, don't make assumptions unless you need them. Formatting an email address in an HTML document would work by wrapping it in the appropriate tag. (which implies html-quoting it correctly, but that is unrelated to email syntax). Sending an email using an API would work by passing the email as a string to the API. Looking up an email address from an address book using a pattern to match would be implemented with normal text search. It doesn't matter if the email is "valid" or not. Don't overthink it.

afiori 4y ago

SQL injection, XSS, and similar attacks are about incorrectly encoding embedded fragments. The solution is either not to embed (SQL parameter bindings) or to always escape embedded fragments based on the embedding context For reference: The Last XSS Defense Talk - Jim Manico - NDC Porto 2022 | https://youtu.be/wRC7jyhTkEM https://youtu.be/wRC7jyhTkEM

xigoi 4y ago

You don't avoid injection attacks by validation, but by escaping.

rowanG077 4y ago
escaping requires validation. You don't know what to escape if you aren't allowed to validate.
- jstimpfle 4y ago
  You don't know what you're talking about. For example, HTML escaping (a.k.a quoting) rules don't care what you're escaping - an email, a street name. It's just text. And that's the point of it. You quote precisely because the container syntax doesn't know the syntax of what you're embedding. If it knew, there would be no need of the escaping. It's called abstraction.
  - rowanG077 4y ago
    HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.
    - xigoi 4y ago
      You seem to have a weird definition of “validation”.
    - jstimpfle 4y ago
      So you're "validating" symbols now (strange choice of word). But certainly validating that the higher-level construct that we're escaping is an email address. Because the escaping procedure doesn't care.
      - rowanG077 4y ago
        Validating is just the process of ensuring an input is admissible in the way you want to use it. That can be symbols in a string, whether a string is an e-mail or even if a number is in a certain range. Escaping is just validation + fixup which can be used in some cases. Anyway the only way to validate an e-mail in practice is to use it and confirm.
        jstimpfle 4y ago
        > Escaping is just validation + fixup You're confused and annoyingly persistent. Escaping (or quoting in general) is a simple translation from a literal representation of a string to a (lexical) syntax representation with the purpose of embedding the string in an external medium (e.g. source code written in that lexical syntax). Escaping is a mechanical process that doesn't discriminate between "valid" and "invalid". It is completely ignorant to the higher-level meaning of the string that is translated (e.g. email address) but solely operates on the constituent characters. That is in contrast to validation, which is a simple function that decides whether a given object is admissible or not (as you say yourself). "Admissible" here is in with respect to a meaning that is higher-level than lexical syntax. It is semantic (is this a valid email), not syntactic. (There are sometimes certain technical restrictions on which values can be represented in a lexical syntax, for example hard limits on string lengths. So there is a small extent to which "validation" can fill a purpose with relation to lexical syntax, too - but that's not what we're discussing). To make it even more confusing, email addresses conform to a (albeit poorly specified) lexical syntax, too. And you can certainly attempt to validate if a given string is valid email address. However, HTML syntax doesn't care about that. Email address syntax is not part of the HTML syntax. HTML specifies how to escape _strings_, not email addresses. And HTML syntax is right not caring about email syntax because it would be unnecessary complication in practice. Just as the other examples I gave. E.g. looking up email addresses from an address book is not a task that in practice needs to be more specific than looking up a string from a list of strings. > Anyway the only way to validate an e-mail in practice is to use it and confirm. Which was my initial statement "Just use it" that you heavily disagreed with.