Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx does not play well with content security policy

sjoerdlangkemper.nl

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Htmx does not play well with content security policy

#21

Post by bakugo »

stouset wrote: post #17

If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost

Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do.

I'm surprised at the amount of comments on this post that seem to be completely clueless about CSP.

Re: Htmx does not play well with content security policy

#22

Post by isodev »

andybak wrote: post #18
iamkonstantin wrote: post #12

it’s unclear what point the post is trying to make. The outlined behaviour is not specific to HTMx per-se. These are security considerations for all server rendered pages. The “basic” golden rules: - Only call routes you control - Always use an auto-escaping template engine - Only serve user-generated content inside HTML tags - If you have authentication cookies, set them with Secure, HttpOnly, and SameSite=Lax https…

> These are security considerations for all server rendered pages Well - "server rendered" to my ears primarily means plain html generated on the server using Perl, Python, PHP, CGI or whatever. I presume you mean "server rendered with some client-side code to handle injecting into the current DOM. Am I just too old-school or does using "server rendered" to mean fairly specific things seem strange?

You're correct. Server-rendered pages may also have some client-side interactivity using, for example, JavaScript/AJAX.... It doesn't need to be a fancy framework like htmx, but one needs to be mindful about user input and remote content either way. The same "techniques" for securing a web page remain in effect.

Re: Htmx does not play well with content security policy

#23

Post by hannob »

I feel 2/3 of the comments here are missing the point.

CSP is a mitigation for XSS vulnerabilities. Yeah, if you always sanitize everything in the right way, you won't have XSS vulnerabilities.

CSP was born out of the recognition that people fail to properly sanitize everything, even if they know that this is what they should do. Because it's complicated, and there are so many corner-cases and different ways to have XSS. CSP is a mitigation on top, in case your "we sanitize everything in the right way" goes wrong.

Making the point that you don't need CSP if you don't have XSS vulnerabilities is like saying C is secure as long as you know know how to use it and don't write code with memory safety bugs.

Re: Htmx does not play well with content security policy

#25

Post by vidarh »

andybak wrote: post #18
iamkonstantin wrote: post #12

it’s unclear what point the post is trying to make. The outlined behaviour is not specific to HTMx per-se. These are security considerations for all server rendered pages. The “basic” golden rules: - Only call routes you control - Always use an auto-escaping template engine - Only serve user-generated content inside HTML tags - If you have authentication cookies, set them with Secure, HttpOnly, and SameSite=Lax https…

> These are security considerations for all server rendered pages Well - "server rendered" to my ears primarily means plain html generated on the server using Perl, Python, PHP, CGI or whatever. I presume you mean "server rendered with some client-side code to handle injecting into the current DOM. Am I just too old-school or does using "server rendered" to mean fairly specific things seem strange?

It doesn't matter how it's rendered or where it's rendered. If it lets user A put unescaped/filtered/sanitised data on user B's pages, it's a security issue, no matter how the page was rendered. It's one that can be mitigated in various ways, but it's important to take into account.

Re: Htmx does not play well with content security policy

#26

Post by elmigranto »

bakugo wrote: post #21
stouset wrote: post #17

If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do. I'm surprised at the amount of comments on this post that seem to be comple…

> if someone manages to inject arbitrary HTML

If they can, why wouldn’t it be inline ?

Re: Htmx does not play well with content security policy

#27

Post by Akronymus »

bakugo wrote: post #21
stouset wrote: post #17

If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost , htmx or otherwise.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do. I'm surprised at the amount of comments on this post that seem to be comple…

serving html with string concatenation is just like creating sql statements with string concat.

At least thats how I see it. Ideally you'd use something similar to prepared statements, just for html templates.

Re: Htmx does not play well with content security policy

#28

Post by [deleted] »

andybak wrote: post #18
iamkonstantin wrote: post #12

it’s unclear what point the post is trying to make. The outlined behaviour is not specific to HTMx per-se. These are security considerations for all server rendered pages. The “basic” golden rules: - Only call routes you control - Always use an auto-escaping template engine - Only serve user-generated content inside HTML tags - If you have authentication cookies, set them with Secure, HttpOnly, and SameSite=Lax https…

> These are security considerations for all server rendered pages Well - "server rendered" to my ears primarily means plain html generated on the server using Perl, Python, PHP, CGI or whatever. I presume you mean "server rendered with some client-side code to handle injecting into the current DOM. Am I just too old-school or does using "server rendered" to mean fairly specific things seem strange?

[deleted]

Re: Htmx does not play well with content security policy

#29

Post by amluto »

elmigranto wrote: post #26
bakugo wrote: post #21

Earlier quoted context omitted.

> If you allow random users to write arbitrary unsanitized HTML into other users’ pages, you have already lost Not really. The whole point of CSP is that, even if someone manages to inject arbitrary HTML into your page due to a bug or oversight, you can prevent injected scripts from running entirely, severely limiting what an attacker can do. I'm surprised at the amount of comments on this post that seem to be comple…

> if someone manages to inject arbitrary HTML If they can, why wouldn’t it be inline ?

Because CSP can be configured to block inline scripts.

Re: Htmx does not play well with content security policy

#30

Post by esjeon »

ackers wrote: post #14

I don't see the point of this article, it's just common sense. If you plan which parts of the DOM are replaced using HTMX, never trust user input. You'll be fine. I use Golang with HTMX and it's amazingly productive.

I mean that's the point. Reminding people of possible dangers is one very important security mission.
Post reply on HN