4 ms·

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the inpu

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

tester756 3y ago
Actually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree composition
- skottk 3y ago
  Parameterized SQL is your friend here.
  - mysterydip 3y ago
    Yeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.
    - dylan604 3y ago
      Before Parameterized SQL was a thing, sanitizing was the thing. There’s a lot of escape_string() type of methods out there.
- hobs 3y ago
  You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.
  - tester756 3y ago
    Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work When you can use approach which fundamentally prevents SQL injection?
    - hobs 3y ago
      I didn't say you should, I am just noting that there's no complexity in the solution required, it's simple and yet still many people don't do it.
  - dylan604 3y ago
    That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.
    - hobs 3y ago
      Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.
      - dylan604 3y ago
        look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.
        hobs 3y ago
        I didn't say I don't use parameterization, and I still haven't heard what the difference is between the old style escape methods and the quotes I mentioned, just you being salty :)
- reeeeaway 3y ago
  Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though
  - tester756 3y ago
    Could you describe it conceptually how they do it?
    - reeeeaway 3y ago
      The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/core/Utils.java#66 https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main... I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound
ajross 3y ago
> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.
- TacticalCoder 3y ago
  Is it a slow sunday for me or... If you hash the password on the client and send the hash then hash is the password. And if you then have, for example, a DB leak with username and hashes, you don't need the password anyway because you can just send the hash and log in? (but then it's sunday and I need more coffee so I may be wrong)
  - gvx 3y ago
    That is correct. The client sends the encrypted (via HTTPS) but not hashed password to the server, both for changing your password and checking your password. So the server receives the password in plaintext but shouldn't store it. Whatever the client sends to the server, an attacker can send too.
  - andy81 3y ago
    You're not the first to come up with that exploit- https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash
- deleted 3y ago
  [deleted]
- sevensevennine 3y ago
  Don't hash the password on the client. That just changes the password to the hash of the password. Parameterize the SQL on the server instead of concatenating strings.
  - hn_acker 3y ago
    If you're using a third-party reverse proxy, then the third party will have access to the user's password. What's the simplest way to prevent the third-party from knowing the password? Would adding an encryption layer between the user and the actual website owner be both feasible and sufficient for the average website owner?
GuB-42 3y ago
Thinking about it, it can also be that the input is sanitized a little too much. Imagine the user uses "select_mypassword" as a password. The sanitizer kicks in and silently mangles your password, resulting in another password being stored than the one you entered, effectively locking you out. Or maybe it just fails with an obscure error because some overzealous countermeasure triggered. I wonder what using the EICAR file as a password would do btw. Also, while the password may be stored properly (hashed), the password still transits in plaintext before it is stored or verified. So even with hashing, you can still be vulnerable to injection.
- MadnessASAP 3y ago
  Presumably you would apply the same sanitizer at login time to whatever password the user enters. If the input is the same and the transform is the same then the output will be the same. Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.
  - patrakov 3y ago
    This relies on a false assumption that the sanitizer is static.
    - MadnessASAP 3y ago
      If we're to continue with this thought experiment in doing the dumb thing. Clearly you would version your sanitizer and store which version you used when saving the password. That way you can ensure the same version is used against future user inputs.
  - GuB-42 3y ago
    What may happen is that every step is siloed in some way and every team assume the others are monkeys on typewriters. From a security perspective, it is not necessarily a bad thing, but it can make the user experience terrible. For example, I may write some piece of software that refuses to write files with spaces in them, because I suspect that later on, some shell script will process them and it is very common for poorly written shell script to break with spaces in file names. But it may turn out that unexpectedly, the people who write the back end are competent and deal with spaces just fine. But on their side they may expect me to be be the monkey and say, avoid replying with Unicode characters, assuming my code will break if it gets something that is not an ASCII printable character. So in the end, the user will have neither spaces in file names nor proper Unicode support, even though the software wouldn't have any problem with that if two team properly communicated and didn't think of each others as monkeys.

Obligatory meme-y "tell me you're not sanitizing input without telling me". Also not storing hashes of passwords, because then it wouldn't matter what the input is.

tester756 3y ago

Actually they do sanitization by blacklisting "Blacklist sanitizing cleans the input by removing unwelcomed characters such as line breaks, extra white spaces, tabs, &, and tags." But still this is not a way, input sanitization is bullshit. Using query parameters, thus inserting raw input into already built abstract syntax tree of SQL query is the correct solution since SQL injection is about affecting tree composition

skottk 3y ago
Parameterized SQL is your friend here.
- mysterydip 3y ago
  Yeah, that's what's mapped in my head to "sanitizing input" in these cases, as it's the correct way to handle them. I should've unrolled my brain shortcut for the discussion.
  - dylan604 3y ago
    Before Parameterized SQL was a thing, sanitizing was the thing. There’s a lot of escape_string() type of methods out there.
hobs 3y ago
You don't even have to do that, just escape single quotes and you've defeated everything but homomorphic attacks as far as I can tell.
- tester756 3y ago
  Why use unreliable solutions that rely on various assumptions that may change in the future and rely on you not forgetting about even 1 case where it wouldnt work When you can use approach which fundamentally prevents SQL injection?
  - hobs 3y ago
    I didn't say you should, I am just noting that there's no complexity in the solution required, it's simple and yet still many people don't do it.
- dylan604 3y ago
  That’s a comment that makes me think someone read a blog 15 years ago, and never kept up with modern ways of doing things.
  - hobs 3y ago
    Cool - but neither of your comments addressed that I am still correct afaict, if you care about query plans and such parameterization is important, but not getting injected on is a different problem.
    - dylan604 3y ago
      look, if you still want to live like it's 1999, then sure, go ahead and wrap your params in quotes like you think you can. just don't come crying to the rest of us that have more than once provided you with better solutions when you get attacked. i mean, even using the old style escape methods would be better than your appending of quotes idea.
      - hobs 3y ago
        I didn't say I don't use parameterization, and I still haven't heard what the difference is between the old style escape methods and the quotes I mentioned, just you being salty :)
reeeeaway 3y ago
Looking at the postgres JDBC source, it sanitizes parameters when prepared statements and parameterization is used. Different implementations may do different things here though
- tester756 3y ago
  Could you describe it conceptually how they do it?
  - reeeeaway 3y ago
    The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/core/Utils.java#66 https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main... I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound

ajross 3y ago

> Also not storing hashes of passwords, because then it wouldn't matter what the input is. That only tells you they don't hash the passwords in the client. Likely the protection ("protection") is for the input validation layer, not the password backend itself.

TacticalCoder 3y ago
Is it a slow sunday for me or... If you hash the password on the client and send the hash then hash is the password. And if you then have, for example, a DB leak with username and hashes, you don't need the password anyway because you can just send the hash and log in? (but then it's sunday and I need more coffee so I may be wrong)
- gvx 3y ago
  That is correct. The client sends the encrypted (via HTTPS) but not hashed password to the server, both for changing your password and checking your password. So the server receives the password in plaintext but shouldn't store it. Whatever the client sends to the server, an attacker can send too.
- andy81 3y ago
  You're not the first to come up with that exploit- https://en.wikipedia.org/wiki/Pass_the_hash https://en.wikipedia.org/wiki/Pass_the_hash
deleted 3y ago
[deleted]
sevensevennine 3y ago
Don't hash the password on the client. That just changes the password to the hash of the password. Parameterize the SQL on the server instead of concatenating strings.
- hn_acker 3y ago
  If you're using a third-party reverse proxy, then the third party will have access to the user's password. What's the simplest way to prevent the third-party from knowing the password? Would adding an encryption layer between the user and the actual website owner be both feasible and sufficient for the average website owner?

GuB-42 3y ago

Thinking about it, it can also be that the input is sanitized a little too much. Imagine the user uses "select_mypassword" as a password. The sanitizer kicks in and silently mangles your password, resulting in another password being stored than the one you entered, effectively locking you out. Or maybe it just fails with an obscure error because some overzealous countermeasure triggered. I wonder what using the EICAR file as a password would do btw. Also, while the password may be stored properly (hashed), the password still transits in plaintext before it is stored or verified. So even with hashing, you can still be vulnerable to injection.

MadnessASAP 3y ago
Presumably you would apply the same sanitizer at login time to whatever password the user enters. If the input is the same and the transform is the same then the output will be the same. Hopefully you don't actually have to do any of this because your backend wasn't written by monkeys on typewriters.
- patrakov 3y ago
  This relies on a false assumption that the sanitizer is static.
  - MadnessASAP 3y ago
    If we're to continue with this thought experiment in doing the dumb thing. Clearly you would version your sanitizer and store which version you used when saving the password. That way you can ensure the same version is used against future user inputs.
- GuB-42 3y ago
  What may happen is that every step is siloed in some way and every team assume the others are monkeys on typewriters. From a security perspective, it is not necessarily a bad thing, but it can make the user experience terrible. For example, I may write some piece of software that refuses to write files with spaces in them, because I suspect that later on, some shell script will process them and it is very common for poorly written shell script to break with spaces in file names. But it may turn out that unexpectedly, the people who write the back end are competent and deal with spaces just fine. But on their side they may expect me to be be the monkey and say, avoid replying with Unicode characters, assuming my code will break if it gets something that is not an ASCII printable character. So in the end, the user will have neither spaces in file names nor proper Unicode support, even though the software wouldn't have any problem with that if two team properly communicated and didn't think of each others as monkeys.