5 ms·

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 sa

by 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

by 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