2 ms·

No, it's just why developers should HTML-escape all user-contributed content before displaying it. Building it into the templating engine just punishes all the

No, it's just why developers should HTML-escape all user-contributed content before displaying it. Building it into the templating engine just punishes all the devs who know what they're doing. Look at the history of things like MAGIC_QUOTES_RUNTIME to see what happens if you go down that route.

pornel 16y ago
Clearly relying on developers to remember to escape didn't work (it's not first XSS and not last). I don't think it's anything like magic quotes. It's more like prepared statements. Magic quotes was enormous failure because it worked on input rather than output. In HTML-specific output code having HTML-escaping is just fine. Lack of escaping enables worms and error isn't immediately visible. Double escaping is quickly visible, and it's harmless, which is why I think not trusting variables in HTML is a better default.
- jasonkester 16y ago
  As soon as you start auto-escaping everything, you need to introduce a dontEscapeThis() method that you can use to actually render the HTML you intended. Having to do that would be enough to make me ditch any framework in favor of one that treats me like a grownup.
  - points 16y ago
    It's depressing to see your comment at -1. I guess there are lots of framework lovers here :/
  - sbov 16y ago
    Yes, lets needlessly make something harder and less secure in 99% of the cases because people want to be treated like a "grownup". How many times have you written code that actually required raw, dynamic, unescaped html output in a template engine? I think I have... 2 times? And for 2 times I still had to escape the output 50% of the time - when displaying it in a form for the user to edit.
  - jrockway 16y ago
    Not true. What you need is a type system. All data that comes from the user is of type UnescapedUserString. When the templating system sees this, it escapes it when written as HTML. Strings that you type into your program that you don't want to be escaped are of type EscapedString. Add some concatenation rules, and you're done. If you were using Haskell, you wouldn't even need to change much code to do this, thanks to overloaded strings.

pornel 16y ago

Clearly relying on developers to remember to escape didn't work (it's not first XSS and not last). I don't think it's anything like magic quotes. It's more like prepared statements. Magic quotes was enormous failure because it worked on input rather than output. In HTML-specific output code having HTML-escaping is just fine. Lack of escaping enables worms and error isn't immediately visible. Double escaping is quickly visible, and it's harmless, which is why I think not trusting variables in HTML is a better default.

jasonkester 16y ago
As soon as you start auto-escaping everything, you need to introduce a dontEscapeThis() method that you can use to actually render the HTML you intended. Having to do that would be enough to make me ditch any framework in favor of one that treats me like a grownup.
- points 16y ago
  It's depressing to see your comment at -1. I guess there are lots of framework lovers here :/
- sbov 16y ago
  Yes, lets needlessly make something harder and less secure in 99% of the cases because people want to be treated like a "grownup". How many times have you written code that actually required raw, dynamic, unescaped html output in a template engine? I think I have... 2 times? And for 2 times I still had to escape the output 50% of the time - when displaying it in a form for the user to edit.
- jrockway 16y ago
  Not true. What you need is a type system. All data that comes from the user is of type UnescapedUserString. When the templating system sees this, it escapes it when written as HTML. Strings that you type into your program that you don't want to be escaped are of type EscapedString. Add some concatenation rules, and you're done. If you were using Haskell, you wouldn't even need to change much code to do this, thanks to overloaded strings.