3 ms·

This is stupid and I don't see anyone quite hitting the mail on the head as to why. People normally dumb web vulnerabilities together. Xss and sqli especially.

by theboss 12y ago

This is stupid and I don't see anyone quite hitting the mail on the head as to why. People normally dumb web vulnerabilities together. Xss and sqli especially. Preventing xss you have to sanitize. Preventing sqli you used parameterized queries. To prevent stored xss you sanitize what you put in the database. So really... You still need to sanitize. I've also seen people make arguments about inexperienced web programmers and how this advice can cause them to write bad code. I think the argument is bad because so many resources exist to help them. There is real code on stack overflow, w3 schools, owasp, and other blogs that can be copied and pasted in to their projects.

zAy0LfpBZLC8mAC 12y ago
No, you don't sanitize what you put in your database, you validate what you put in your database, and convert into the output format when using data from the database. Sanitizing is always(!) wrong.
- theboss 12y ago
  If you never sanitize how do you prevent xss ... For the average web Dev my approach is plenty good enough.. It's funny because your approach still requires sanitizing
  - splitbrain 12y ago
    by properly escaping the output, not sanitizing the input
    - theboss 12y ago
      And... How is escaping different from sanitizing. I would expect escaping to inheret from sanitizing. The idea is the same. You take user input and put it in a safe format. The programmers needs may be different.
      - zAy0LfpBZLC8mAC 12y ago
        The problem is in the confusion that leads people to think in terms of a "safe format". There is no such thing. "&" is not a "safe form" of "&", but rather the HTML (among others) _encoding_ of what in plain text is represented by "&". If you need to generate output that causes an "&" to be displayed, you have to encode it according to the rules of thet target format, not in some general magic "safe format". If you are generating a plain text mail, you have to encode it as "&", encoding it as "&" is just wrong, because it leads to the user seeing "&" instead of "&". Only if you are generating HTML, you have to encode it as "&" in order for an "&" to be displayed. It's all about encoding things so that after decoding you get back the original input, not about "making things safe" - it's just a side effect that if you encode everything such that it causes a dumb series of characters to be displayed, that that tends to not cause any security problems.
  - zAy0LfpBZLC8mAC 12y ago
    Using validation and encoding. You check input for conformance to your data model and reject anything that fails the validation (you tell the user about the error and ask them to correct their mistake), and then you convert from your data model to the output format that you are generating. So, for example, you could have a data model of "plain text field", in that case you check that the input is a valid character string (so no undefined codepoints present and, for example, no syntax errors in the UTF-8 encoding if that is what you are using). Thus you can be sure that you have only characters strings in that column of your database. Then, if you want to output one of those strings to be displayed within an HTML page, you convert it from plain text to HTML (replacing "<" with "<", "&" with "&", and so on). That way there is no XSS possible, and also, any input the user makes is displayed back exactly as they entered it.
    - theboss 12y ago
      SDepends on what you need. Depends on the input field. Another example for why this is stupid
- marcosdumay 12y ago
  You mean that you put it unsanitized (for HTML) at the database, and sanitize only when converting to HTML... Well, I completely agree, but how can you then claim that sanitizing is always wrong?
  - zAy0LfpBZLC8mAC 12y ago
    I mean "sanitize" as in "clean up" (as in "remove 'special characters'"). If you use "sanitize" to mean "encode as" (as in "replace '&' with '&'"), then there is nothing wrong with that, I would just suggest that you don't call that "sanitize", because that is highly confusing, if you look in the dictionary what that word normally means. Assume a user uploads a TIFF file to your web application. Browsers don't understand TIFF. So, in order to display it on a web page, you convert it into a PNG. You wouldn't call that "sanitizing it for PNG" either, would you? For the same reason, you shouldn't call it "sanitizing" when you convert plain text to HTML.

by theboss 12y ago

zAy0LfpBZLC8mAC 12y ago

No, you don't sanitize what you put in your database, you validate what you put in your database, and convert into the output format when using data from the database. Sanitizing is always(!) wrong.

theboss 12y ago
If you never sanitize how do you prevent xss ... For the average web Dev my approach is plenty good enough.. It's funny because your approach still requires sanitizing
- splitbrain 12y ago
  by properly escaping the output, not sanitizing the input
  - theboss 12y ago
    And... How is escaping different from sanitizing. I would expect escaping to inheret from sanitizing. The idea is the same. You take user input and put it in a safe format. The programmers needs may be different.
    - zAy0LfpBZLC8mAC 12y ago
      The problem is in the confusion that leads people to think in terms of a "safe format". There is no such thing. "&" is not a "safe form" of "&", but rather the HTML (among others) _encoding_ of what in plain text is represented by "&". If you need to generate output that causes an "&" to be displayed, you have to encode it according to the rules of thet target format, not in some general magic "safe format". If you are generating a plain text mail, you have to encode it as "&", encoding it as "&" is just wrong, because it leads to the user seeing "&" instead of "&". Only if you are generating HTML, you have to encode it as "&" in order for an "&" to be displayed. It's all about encoding things so that after decoding you get back the original input, not about "making things safe" - it's just a side effect that if you encode everything such that it causes a dumb series of characters to be displayed, that that tends to not cause any security problems.
- zAy0LfpBZLC8mAC 12y ago
  Using validation and encoding. You check input for conformance to your data model and reject anything that fails the validation (you tell the user about the error and ask them to correct their mistake), and then you convert from your data model to the output format that you are generating. So, for example, you could have a data model of "plain text field", in that case you check that the input is a valid character string (so no undefined codepoints present and, for example, no syntax errors in the UTF-8 encoding if that is what you are using). Thus you can be sure that you have only characters strings in that column of your database. Then, if you want to output one of those strings to be displayed within an HTML page, you convert it from plain text to HTML (replacing "<" with "<", "&" with "&", and so on). That way there is no XSS possible, and also, any input the user makes is displayed back exactly as they entered it.
  - theboss 12y ago
    SDepends on what you need. Depends on the input field. Another example for why this is stupid
marcosdumay 12y ago
You mean that you put it unsanitized (for HTML) at the database, and sanitize only when converting to HTML... Well, I completely agree, but how can you then claim that sanitizing is always wrong?
- zAy0LfpBZLC8mAC 12y ago
  I mean "sanitize" as in "clean up" (as in "remove 'special characters'"). If you use "sanitize" to mean "encode as" (as in "replace '&' with '&'"), then there is nothing wrong with that, I would just suggest that you don't call that "sanitize", because that is highly confusing, if you look in the dictionary what that word normally means. Assume a user uploads a TIFF file to your web application. Browsers don't understand TIFF. So, in order to display it on a web page, you convert it into a PNG. You wouldn't call that "sanitizing it for PNG" either, would you? For the same reason, you shouldn't call it "sanitizing" when you convert plain text to HTML.