6 ms·

It got me thinking, is client side rendering intrinsically safer than SSR. SQL queries with params are safer because data and code flow separately. Similarly,

It got me thinking, is client side rendering intrinsically safer than SSR. SQL queries with params are safer because data and code flow separately. Similarly, if you query backend for data and then do textContent = response, that cannot do xss, right?

jcims 5y ago
Anytime is possible for the data that returns to be interpolated by the client, you could have xss or related attack. Client side rendering does help but mistakes are still regularly made. Sometimes by the app dev, sometimes by the framework dev. You could probably go to an extreme and return all of your application data as sprites.
- furstenheim 5y ago
  Of course you can still do <div> + input + </div> in CSR, but you can definitely not do myelement.textContent = whateverIGot in SSR, right?
  - asddubs 5y ago
    you can use a template engine that escapes all variables by default. in either case, it's just about coding defensively and being secure by default
    - furstenheim 5y ago
      Then why is parameter query safer? And not just escapes variables? Escaping is hard, as shown in the article
      - asddubs 5y ago
        generating html using find and replace/regex safely is hard. escaping is easy. and the solution is to just not generate html using find and replace. You'll run into the exact same problem trying to do a bbcode/markdown/whatever parser using javascript
chrismorgan 5y ago
No, client-side rendering is not intrinsically safer than server-side rendering, provided all outputs of serialisation are parsed identically (as is the case for valid HTML trees). The problems start when you try to manipulate serialised data, which is not safe to do this in the general case. You should instead construct a proper representation of what you desire, and then serialise that, depending on the serialiser to take care of all of this sort of stuff. This approach has always been fairly popular in compiled languages and languages that like types, but dynamic languages have historically significantly preferred to manipulate strings, I suspect because they don’t have good ergonomics on the other approach, and it’s probably slower in interpreted languages—you’ll note that React felt the need to extend JavaScript to make its approach acceptable to people. Most JavaScript stuff that supports server-side rendering now is working in this way, crafting a DOM tree and then serialising that. Svelte is a notable exception in that it takes a declarative DOM tree and essentially serialises what it can at compile time, thereby still retaining the required safety guarantees. There are definitely downsides to strict adherence to the model of crafting a data structure and then serialising it; most significantly, you can’t start streaming a response until you’re done. The solution for this is to use an append-only data structure (or possibly one that allows you to “commit” the document up to a given point, while still allowing mutations in anything that occurs later in the document); thus serialisation can begin before you finish writing the document. You know the old favourite about parsing HTML with regular expressions? <https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open...> (If not, enjoy!) This is the thing people need to understand and realise in the general case: serialised data should be treated as opaque, and only interacted with after real parsing and before real serialisation. HTTP headers aren’t strings; "Date: Tue, 15 Nov 1994 08:12:31 GMT" is a serialised HTTP header, representing the actual header that’s more like {Date, 1994-11-15T08:12:31Z}. And that latter is the form you should interact with it in. HTML isn’t strings; "<p>Hello, world!</p>" is the serialised form of a paragraph element containing a text node with data “Hello, world!”. And that’s the form you should interact with it in. Yes, I am presenting a strongly-opinionated position that lacks any shade of pragmatism. Yes, my website is generated with templates that manipulate serialised HTML. Eventually I’ll replace it with something more sound. One last note: at the start I said valid HTML, because it’s not enough to just serialise an arbitrary HTML DOM tree, as you can easily craft invalid HTML DOM trees, like nesting hyperlinks. In most regards, the XML syntax of HTML (still a thing) is actually a safer target to serialise to because then you don’t even need to validate your tree to be confident it won’t get mangled by the serialise/parse round-trip.
alcover 5y ago
> textContent = response Good question (that none of the replies seem to address). That is exactly what I would do if rendering 'tainted' text. Can someone please tell us how it could be defeated ?
- tgsovlerkhgsel 5y ago
  This should be safe.
  - trulyme 5y ago
    ...unless it is a text that the attacker shows to another user, in which case they can trick this user to perform some action (send cryptocurrency,...).
asddubs 5y ago
if you use a template engine with sane defaults, you can achieve the same level of safety.

jcims 5y ago

Anytime is possible for the data that returns to be interpolated by the client, you could have xss or related attack. Client side rendering does help but mistakes are still regularly made. Sometimes by the app dev, sometimes by the framework dev. You could probably go to an extreme and return all of your application data as sprites.

furstenheim 5y ago
Of course you can still do <div> + input + </div> in CSR, but you can definitely not do myelement.textContent = whateverIGot in SSR, right?
- asddubs 5y ago
  you can use a template engine that escapes all variables by default. in either case, it's just about coding defensively and being secure by default
  - furstenheim 5y ago
    Then why is parameter query safer? And not just escapes variables? Escaping is hard, as shown in the article
    - asddubs 5y ago
      generating html using find and replace/regex safely is hard. escaping is easy. and the solution is to just not generate html using find and replace. You'll run into the exact same problem trying to do a bbcode/markdown/whatever parser using javascript

chrismorgan 5y ago

No, client-side rendering is not intrinsically safer than server-side rendering, provided all outputs of serialisation are parsed identically (as is the case for valid HTML trees). The problems start when you try to manipulate serialised data, which is not safe to do this in the general case. You should instead construct a proper representation of what you desire, and then serialise that, depending on the serialiser to take care of all of this sort of stuff. This approach has always been fairly popular in compiled languages and languages that like types, but dynamic languages have historically significantly preferred to manipulate strings, I suspect because they don’t have good ergonomics on the other approach, and it’s probably slower in interpreted languages—you’ll note that React felt the need to extend JavaScript to make its approach acceptable to people. Most JavaScript stuff that supports server-side rendering now is working in this way, crafting a DOM tree and then serialising that. Svelte is a notable exception in that it takes a declarative DOM tree and essentially serialises what it can at compile time, thereby still retaining the required safety guarantees. There are definitely downsides to strict adherence to the model of crafting a data structure and then serialising it; most significantly, you can’t start streaming a response until you’re done. The solution for this is to use an append-only data structure (or possibly one that allows you to “commit” the document up to a given point, while still allowing mutations in anything that occurs later in the document); thus serialisation can begin before you finish writing the document. You know the old favourite about parsing HTML with regular expressions? <https://stackoverflow.com/questions/1732348/regex-match-open-tags-except-xhtml-self-contained-tags https://stackoverflow.com/questions/1732348/regex-match-open...> (If not, enjoy!) This is the thing people need to understand and realise in the general case: serialised data should be treated as opaque, and only interacted with after real parsing and before real serialisation. HTTP headers aren’t strings; "Date: Tue, 15 Nov 1994 08:12:31 GMT" is a serialised HTTP header, representing the actual header that’s more like {Date, 1994-11-15T08:12:31Z}. And that latter is the form you should interact with it in. HTML isn’t strings; "<p>Hello, world!</p>" is the serialised form of a paragraph element containing a text node with data “Hello, world!”. And that’s the form you should interact with it in. Yes, I am presenting a strongly-opinionated position that lacks any shade of pragmatism. Yes, my website is generated with templates that manipulate serialised HTML. Eventually I’ll replace it with something more sound. One last note: at the start I said valid HTML, because it’s not enough to just serialise an arbitrary HTML DOM tree, as you can easily craft invalid HTML DOM trees, like nesting hyperlinks. In most regards, the XML syntax of HTML (still a thing) is actually a safer target to serialise to because then you don’t even need to validate your tree to be confident it won’t get mangled by the serialise/parse round-trip.

alcover 5y ago

> textContent = response Good question (that none of the replies seem to address). That is exactly what I would do if rendering 'tainted' text. Can someone please tell us how it could be defeated ?

tgsovlerkhgsel 5y ago
This should be safe.
- trulyme 5y ago
  ...unless it is a text that the attacker shows to another user, in which case they can trick this user to perform some action (send cryptocurrency,...).

asddubs 5y ago

if you use a template engine with sane defaults, you can achieve the same level of safety.