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

41–50 of 64 posts

Re: Htmx does not play well with content security policy

#41

Post by yawaramin »

This article seems to be full of security vulns that the hypothetical htmx user is deliberately injecting into their own page. Sure, if you deliberately make your app vulnerable, it's vulnerable. This isn't, uh, unique to htmx.

For example, sure you can allow htmx on your page to make requests to domains you don't control. This is the proverbial shooting yourself in the foot. If you are allowing this in your site, you have much deeper problems than htmx and need much bigger interventions than CSP.

Re: Htmx does not play well with content security policy

#42

Post by bastawhiz »

mtlynch wrote: post #19

There are some good points here, but I think the author neglects to dig deeper and explain how you can mitigate some of these risks with htmx settings. I've been using htmx with CSP for the past couple of weeks, and I do find that it expands attack surface in an unpleasant way, but I do still think it brings enough value that I'm willing to rely on other protections. > That cors.php file contains the JavaScript paylo…

> you have to screw up a lot more to give the attacker complete control over the HTML.

Isn't this just a XSS vulnerability?

Re: Htmx does not play well with content security policy

#43

Post by latent22 »

Lets dig in:

Loading malicious fragments: This is in no way related to htmx and is the same for all web implementations because you don't go get possible script code from random untrusted domains you don't trust or control. Also if he had tried this with the current version of htmx (2.0) he would have not been able to do this as it now defaults to blocking hx requests to external sites and you can only use local relative paths now. So win to htmx on this point.

Unsafe eval: Yeah unsafe eval looks bad but almost every other client side framework also has this same issue and it is very hard to turn this one off on any modern interactive or SPA like website today. Htmx has the option to just ignore the two features that need unsafe eval and implement these features with other more custom solutions unlike most other solutions so I have to chalk this up as a second win for htmx.

Disabling HTMX with hx-disable: I think it fair that hx-disable is not a fool proof security feature and is there to stop silly things and provide some isolation for content to separate it from htmx. But you should probably not allow un-sanitized data in here and expect this to save you.

Nonces for inline scripts: Yeah htmx has some support for nonces and they can protect from inline scripts inserted into the page somehow but they won't protect you from scripts returned from your trusted local server via hx requests by design. Another small win here.

Configuration meta tag: This one is a fair point and the use of malicious meta tags is an interesting attack vector. This may weaken some of the security features built into htmx but if you allow un-sanitized user input to be returned by your server like in his example app there are not many solutions that will come off any better off.

Conclusion: When a site uses HTMX, the attack surface of HTML injection is the same as any other SSR solution. It is possible to limit the risk of XSS by using a content security policy. Security is simple and old school as you just sanitize your inputs which all modern backend stacks now make easy. But it not possible to have all HTMX features and provide 100% security against injection (unless you sanitize all inputs and only link to your own server).

Re: Htmx does not play well with content security policy

#44

Post by pessimizer »

esjeon wrote: post #30
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.

I think the point being made that you're replying to is that it has nothing to do with htmx. It isn't htmx that's not playing well with content security policy.

Re: Htmx does not play well with content security policy

#45

Post by latent22 »

mtlynch wrote: post #35
latent22 wrote: post #24

Checks security headers for web server hosting article and finds a F with no headers set

The headers say "Server: AmazonS3" which means it's a static site. Given that it's also a personal blog, there's not much point in CSP headers because a) it's not processing user input and b) even if an attacker achieves XSS, there's no data to steal or useful malicious actions to take on a static personal blog.

Yeah the risk here is very low unless they start hosting more complicated content later on. But it is not hosted on S3 and is actually hosted by AWS CloudFront with a S3 origin which now has a built in feature to set security headers for your static site in only a few clicks so you can get that sweet sweet A rating ;)

Re: Htmx does not play well with content security policy

#46

Post by mtlynch »

bastawhiz wrote: post #42
mtlynch wrote: post #19

There are some good points here, but I think the author neglects to dig deeper and explain how you can mitigate some of these risks with htmx settings. I've been using htmx with CSP for the past couple of weeks, and I do find that it expands attack surface in an unpleasant way, but I do still think it brings enough value that I'm willing to rely on other protections. > That cors.php file contains the JavaScript paylo…

> you have to screw up a lot more to give the attacker complete control over the HTML. Isn't this just a XSS vulnerability?

What I mean is that imagine you have HTML like this:
You might screw up and give the attacker a way to control the src attribute like:
So, maybe unintentional behavior but still no xss.

And if you let the attacker inject double quotes, then they can escape the attribute and do something like this:
In this case, htmx would still prevent the xss because hx-disable causes htmx to ignore the hx-delete attribute in the child element.

But if we assume the server fails to encode angle brackets too, then the attacker wins because they can terminate the hx-disable, as described in the post.
But they're different levels of screwup. Accidentally letting the attacker control the value of the attribute is one level, letting them inject extra attributes is another level, and letting them inject extra HTML elements is another level.

Granted, if you're screwing up output encoding, you're likely going to grant the attacker the ability to inject elements at the same time that you allow them to inject attributes, but the defender has a bit more protection if they disallow or encode angle brackets in user input.

Re: Htmx does not play well with content security policy

#47

Post by osmano807 »

HN really strange, page jumped from front to page 3...

I'm still searching for the holy grail of web development without Javascript or TypeScript, still not found.

Leptos still ahead but still imature, recently with panic! with signal usage. Dioxus today commited improvements to suspension such as placeholders...

egui unusable in mobile, as Android keyboard overlaps the window.

Don't know other alternatives in other languages, but for those who don't want JS it's difficult.

Re: Htmx does not play well with content security policy

#48

Post by iamkonstantin »

the8472 wrote: post #20
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…

The point of CSP is to lock down your site so that any content (buggy or malicious) can't do damage. This requires templating engines to separate styles, scripts and event handlers from the html. > These are security considerations for all server rendered pages. That's not true. With the right CSP and sandbox rules content can be made inert without sanitizing. Sanitizing is still a good idea of course, but a renderin…

What is a rendering engine with CSP in mind?

The server can, at best, set the correct CSP header. It’s a validation performed entirely in the browser. Even the best intended rendering from the server can’t prevent CSP violation attempts when the client is executing some kind of script. That’s why even frameworks like Vue and React need a correctly configured CSP.

Re: Htmx does not play well with content security policy

#49

Post by yawaramin »

ramon156 wrote: post #34
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.

Not everyone's as knowledged, hence information should be shared

And fortunately, it was https://htmx.org/essays/web-security-basics-with-htmx/

Re: Htmx does not play well with content security policy

#50

Post by the8472 »

iamkonstantin wrote: post #48
the8472 wrote: post #20

Earlier quoted context omitted.

The point of CSP is to lock down your site so that any content (buggy or malicious) can't do damage. This requires templating engines to separate styles, scripts and event handlers from the html. > These are security considerations for all server rendered pages. That's not true. With the right CSP and sandbox rules content can be made inert without sanitizing. Sanitizing is still a good idea of course, but a renderin…

What is a rendering engine with CSP in mind? The server can, at best, set the correct CSP header. It’s a validation performed entirely in the browser. Even the best intended rendering from the server can’t prevent CSP violation attempts when the client is executing some kind of script. That’s why even frameworks like Vue and React need a correctly configured CSP.

Rewrite the inline styles/scripts at build times to separate files, generate the appropriate script/style elements, compute the appropriate CSP directive.

The renderer could rewrite
to

   
   

   // handlers.js:

   document.querySelector("handler-Oov1to1o").addEventListener(() => foo())
   // [...] more handlers here

   // HTTP header

   content-security-policy: script-src sha256-b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c ;
(the boilerplate can be amortized over many such handlers)

Or at least use 'unsafe-hashes' and compute the hashes for onclick handlers and the like and include those in the CSP.

Separation of style/scripts/content has been encouraged for a long time, I don't know why people are walking it back. But if they insist then templates could also be structured more like a multipart document where those aspects sit in separate parts of the document.

As long as you do any of those when the template renderers are compiled then only scripts whitelisted at buildtime will be executed and scripts injected by dynamic content will get blocked.

Post reply on HN