4 ms·

I'd like to write down a task with this app so I don't forget it! My task is this: <script>alert("XSS is still a thing and building plain HTML responses withou

I'd like to write down a task with this app so I don't forget it! My task is this: <script>alert("XSS is still a thing and building plain HTML responses without a proper templating engine is irresponsible");</script> (In this case, I don't see how the "task" column is sanitized anywhere.)

rafram 3y ago
In the bad old days, XSS was rampant because our views talked directly with our databases. Then we put templating engines and models in the middle and the problem seemed to be solved. Now we have XSS again because the database is the view?! This is a preventable problem!
- indigo945 3y ago
  I don't even hate the idea of generating HTML responses in the database (why not, that's where all the data is!), but this is very clearly not the way to do it. Those functions read like plain PHP scripts, and are obviously just as vulnerable. Just as PHP's problems are largely solved these days by frontend frameworks like Laravel, so could a frontend framework in the database solve the same problems here. I have to say I always liked the Postgres project, but this kind of dangerous and wrong information in an official tutorial makes me wary of using the platform. Who knows what other lessons from the bad old days have been forgotten by the developers?
  - deleted 3y ago
    [deleted]
  - steve-chavez 3y ago
    This doc was meant to be a POC, just to show what's possible. We're working on migrating it to Mustache templates which do automatic escaping: https://github.com/PostgREST/plmustache?tab=readme-ov-file#escaped-and-unescaped https://github.com/PostgREST/plmustache?tab=readme-ov-file#e... You're right though, we'll add a warning there. Thanks for the feedback.
winrid 3y ago
yep, htmx will happily run that script. they even had this bug in their demos: https://github.com/bigskysoftware/htmx/pull/1995/files https://github.com/bigskysoftware/htmx/pull/1995/files
- recursivedoubts 3y ago
  the htmx examples are done w/ a mock server based on sinon.js so everything is client-side. this means we can avoid deploying server-side functionality (which would cost money) and it also means that cross-site scripting attacks aren't an issue (you can only xss yourself.) the examples are to show how htmx works, the "server-side" (such as it is) is just there to support the front end demo.
Capricorn2481 3y ago
This seems like a strawman argument against example docs. HTMX just serves html, you have to sanitize your inputs somehow. You can render the HTML with any templating language that does that for you.
- indigo945 3y ago
  HTMX is not at fault here, the backend is. Of course "you have to sanitize your inputs somehow", but this example does that exactly nowhere, i.e. it is exploitable. Having the tutorial omit this problem altogether is dangerous, as not discussing it might create the impression that PostgREST somehow already handles this, or that the toy example given here does not have a glaring security vulnerability. This is particularly problematic because the reason that the docs for many other backend frameworks also don't discuss the problem is that they do in fact already handle it (usually via a built-in templating language). Steve acknowledged the problem in a sibling comment, so hopefully the next iteration of the tutorial will address this. (Thanks!)
- Nullabillity 3y ago
  HTMX is also at fault here. If you construct your DOM imperatively on the client with newElement and textContent then there is no room for XSS to sneak in, because you're never even parsing (non-static) HTML. You're inherently correct by construction! React is just a declarative wrapper around that, but all dynamic data is still structurally separate from the shape of the DOM tree. HTMX abandons all of that, going back to "lol hope your HTML escape function is correct" (and that you use it consistently!). You could argue that you were just moving the goalpost to serializing JSON safely… but that's a much smaller (and static!) target than escaping HTML's bespoke flavour of SGML.
  - recursivedoubts 3y ago
    Ladies and gentlemen, I'll be brief. The issue here is not whether we broke a few rules, or took a few liberties w/hypermedia — we did. winks But you can't hold a single library responsible for the behavior of a few developers unfamiliar w/ server-side template escaping. For if you do, then shouldn't we blame the whole web development ecosystem? And if the whole whole web development ecosystem is guilty, then isn't this an indictment of hypermedia's uniform interface in general? I put it to you, Nullability: isn't this an indictment of our entire American society? Well, you can say what you want about us, but I'm not going to sit here and listen to you badmouth the United States of America! Gentlemen!

rafram 3y ago

In the bad old days, XSS was rampant because our views talked directly with our databases. Then we put templating engines and models in the middle and the problem seemed to be solved. Now we have XSS again because the database is the view?! This is a preventable problem!

indigo945 3y ago
I don't even hate the idea of generating HTML responses in the database (why not, that's where all the data is!), but this is very clearly not the way to do it. Those functions read like plain PHP scripts, and are obviously just as vulnerable. Just as PHP's problems are largely solved these days by frontend frameworks like Laravel, so could a frontend framework in the database solve the same problems here. I have to say I always liked the Postgres project, but this kind of dangerous and wrong information in an official tutorial makes me wary of using the platform. Who knows what other lessons from the bad old days have been forgotten by the developers?
- deleted 3y ago
  [deleted]
- steve-chavez 3y ago
  This doc was meant to be a POC, just to show what's possible. We're working on migrating it to Mustache templates which do automatic escaping: https://github.com/PostgREST/plmustache?tab=readme-ov-file#escaped-and-unescaped https://github.com/PostgREST/plmustache?tab=readme-ov-file#e... You're right though, we'll add a warning there. Thanks for the feedback.

winrid 3y ago

yep, htmx will happily run that script. they even had this bug in their demos: https://github.com/bigskysoftware/htmx/pull/1995/files https://github.com/bigskysoftware/htmx/pull/1995/files

recursivedoubts 3y ago
the htmx examples are done w/ a mock server based on sinon.js so everything is client-side. this means we can avoid deploying server-side functionality (which would cost money) and it also means that cross-site scripting attacks aren't an issue (you can only xss yourself.) the examples are to show how htmx works, the "server-side" (such as it is) is just there to support the front end demo.

Capricorn2481 3y ago

This seems like a strawman argument against example docs. HTMX just serves html, you have to sanitize your inputs somehow. You can render the HTML with any templating language that does that for you.

indigo945 3y ago
HTMX is not at fault here, the backend is. Of course "you have to sanitize your inputs somehow", but this example does that exactly nowhere, i.e. it is exploitable. Having the tutorial omit this problem altogether is dangerous, as not discussing it might create the impression that PostgREST somehow already handles this, or that the toy example given here does not have a glaring security vulnerability. This is particularly problematic because the reason that the docs for many other backend frameworks also don't discuss the problem is that they do in fact already handle it (usually via a built-in templating language). Steve acknowledged the problem in a sibling comment, so hopefully the next iteration of the tutorial will address this. (Thanks!)
Nullabillity 3y ago
HTMX is also at fault here. If you construct your DOM imperatively on the client with newElement and textContent then there is no room for XSS to sneak in, because you're never even parsing (non-static) HTML. You're inherently correct by construction! React is just a declarative wrapper around that, but all dynamic data is still structurally separate from the shape of the DOM tree. HTMX abandons all of that, going back to "lol hope your HTML escape function is correct" (and that you use it consistently!). You could argue that you were just moving the goalpost to serializing JSON safely… but that's a much smaller (and static!) target than escaping HTML's bespoke flavour of SGML.
- recursivedoubts 3y ago
  Ladies and gentlemen, I'll be brief. The issue here is not whether we broke a few rules, or took a few liberties w/hypermedia — we did. winks But you can't hold a single library responsible for the behavior of a few developers unfamiliar w/ server-side template escaping. For if you do, then shouldn't we blame the whole web development ecosystem? And if the whole whole web development ecosystem is guilty, then isn't this an indictment of hypermedia's uniform interface in general? I put it to you, Nullability: isn't this an indictment of our entire American society? Well, you can say what you want about us, but I'm not going to sit here and listen to you badmouth the United States of America! Gentlemen!