3 ms·

For people saying this is a bad idea to do on the front-end, I believe it's a great idea to have this as a standard. Generally, the process in the past has been

For people saying this is a bad idea to do on the front-end, I believe it's a great idea to have this as a standard. Generally, the process in the past has been: 1. Library that does the heavy lifting 2. Front-end catches up by creating a new standard (seems like https://wicg.github.io/sanitizer-api/ https://wicg.github.io/sanitizer-api/) 3. Node.js implements these native methods, unless it did something similar but actually different between 1. and 2. (and then we are in a mess). 4. Now you can use this everywhere without depending on random libraries. So hopefully with this coming to the front-end, it means that eventually we'll have this functionality native in Node.js at some point in the next 1-3 years! This has been similar (though not always 1-to-1 like desired unfortunately) with many things like promises, crypto, web workers, etc. I am still waiting for native Node.js' fetch().

lucideer 5y ago
There are 3 correct ways (and 1 incorrect way) to secure your strings in a web application: 1. Output escaping (server-side) 2. Output sanitization (server-side) 3. Output sanitization (client-side) - i.e. this standard 4. [Wrong] Input sanitization (server-side) (not to be confused with input validation, which is good but unrelated to this conversation) Without boring with the details of why 4 is wrong, normally you should choose either 1, 2 or 3 depending on different applications: (1) should generally be used in almost ALL cases. Contextual escaping is orders of magnitude more secure than sanitization, and is usable by any application not rendering user-provided rich text. Furthermore, most/many user-provided rich-text applications use a DSL like Markdown which sidesteps the need for sanitization, so you can use escaping for these cases as well. (2) should only be used if you are rendering user-provided rich-text. These cases are quite rare, and chances are if you need this feature you have a large application with lots of experienced engineers and you have the resources to put in place appropriate caching mechanisms. (3) is the same as (2) but offloads the work to the client (no caching necessary) and has a resultant negative impact on the performance of your app (client-side UI latency). Making browsers fast is already a gargantuan challenge for browser-makers; adding client-sized sanitization to the mix will exacerbate this. But mainly, this new standard will encourage inexperienced engineers to use (3) where (1) is much more secure for most applications.
- beepy 5y ago
  I'll bite - why is 2 right but 4 wrong? Is it because it's not reversible? Is it in case your sanitization rules change?
  - lucideer 5y ago
    Firstly, to distinguish sanitization -vs- validation: sanitization retains information lossily, validation throws. Validation may increase security, but the primary motivator is stability (avoiding unexpected state) and UX (relevant error messaging). Input sanitization is intended purely as a security measure but is at best insufficient and usually reduces system security. The first problem is that input sanitization is sanitizing without context: you don't know what threats you're fighting because threat vectors of this variety target the output format. Will your input variable be included into a HTML template, an Atom feed, saved to some file that's parsed later, sent in a JSON API, templated into a style or script block, used in an SQL query. The possibilities aren't known at input (or if they are they will change as your application grows) so protecting against all possibilities isn't viable. Often people html-escape or blindly html-strip their inputs, regardless of whether they'll ever be used in a html template. Given the above you might think input sanitization is at worst useless, inefficient, but not harmful to security, but that brings us to the follow-up problems: lossiness & unknown state. If you're doing input sanitization, you're not doing input validation (at least not properly). Input sanitization is about accepting lossy values (threats removed) when you receive unexpected input. That means you're accepting unexpected input, which leads to all the problems input validation is designed to protect against. Finally, there is of course double-escaping. As mentioned above, people often html-escape as part of input sanitization. This essentially disables your ability to do reliable secure output escaping because that leads to double escaped values in output (or horrible double-escape-reversal hacks in output templating code). Generally you want to be securely output/escaping everything, which means you want a system where you can rely on always receiving clean unescaped values into your output template. I have encountered too many systems using a good, secure html templating library with output escaping baked in by default, where devs had to disable output escaping explicitly because some inputs were already pre-escaped. In theory you can keep track of which vars need raw output and which vars don't, but that's an unmanageable mess in practice. And its impossible to automate enforcement.

lucideer 5y ago

There are 3 correct ways (and 1 incorrect way) to secure your strings in a web application: 1. Output escaping (server-side) 2. Output sanitization (server-side) 3. Output sanitization (client-side) - i.e. this standard 4. [Wrong] Input sanitization (server-side) (not to be confused with input validation, which is good but unrelated to this conversation) Without boring with the details of why 4 is wrong, normally you should choose either 1, 2 or 3 depending on different applications: (1) should generally be used in almost ALL cases. Contextual escaping is orders of magnitude more secure than sanitization, and is usable by any application not rendering user-provided rich text. Furthermore, most/many user-provided rich-text applications use a DSL like Markdown which sidesteps the need for sanitization, so you can use escaping for these cases as well. (2) should only be used if you are rendering user-provided rich-text. These cases are quite rare, and chances are if you need this feature you have a large application with lots of experienced engineers and you have the resources to put in place appropriate caching mechanisms. (3) is the same as (2) but offloads the work to the client (no caching necessary) and has a resultant negative impact on the performance of your app (client-side UI latency). Making browsers fast is already a gargantuan challenge for browser-makers; adding client-sized sanitization to the mix will exacerbate this. But mainly, this new standard will encourage inexperienced engineers to use (3) where (1) is much more secure for most applications.

beepy 5y ago
I'll bite - why is 2 right but 4 wrong? Is it because it's not reversible? Is it in case your sanitization rules change?
- lucideer 5y ago
  Firstly, to distinguish sanitization -vs- validation: sanitization retains information lossily, validation throws. Validation may increase security, but the primary motivator is stability (avoiding unexpected state) and UX (relevant error messaging). Input sanitization is intended purely as a security measure but is at best insufficient and usually reduces system security. The first problem is that input sanitization is sanitizing without context: you don't know what threats you're fighting because threat vectors of this variety target the output format. Will your input variable be included into a HTML template, an Atom feed, saved to some file that's parsed later, sent in a JSON API, templated into a style or script block, used in an SQL query. The possibilities aren't known at input (or if they are they will change as your application grows) so protecting against all possibilities isn't viable. Often people html-escape or blindly html-strip their inputs, regardless of whether they'll ever be used in a html template. Given the above you might think input sanitization is at worst useless, inefficient, but not harmful to security, but that brings us to the follow-up problems: lossiness & unknown state. If you're doing input sanitization, you're not doing input validation (at least not properly). Input sanitization is about accepting lossy values (threats removed) when you receive unexpected input. That means you're accepting unexpected input, which leads to all the problems input validation is designed to protect against. Finally, there is of course double-escaping. As mentioned above, people often html-escape as part of input sanitization. This essentially disables your ability to do reliable secure output escaping because that leads to double escaped values in output (or horrible double-escape-reversal hacks in output templating code). Generally you want to be securely output/escaping everything, which means you want a system where you can rely on always receiving clean unescaped values into your output template. I have encountered too many systems using a good, secure html templating library with output escaping baked in by default, where devs had to disable output escaping explicitly because some inputs were already pre-escaped. In theory you can keep track of which vars need raw output and which vars don't, but that's an unmanageable mess in practice. And its impossible to automate enforcement.