this post was submitted on 03 Feb 2024
486 points (94.2% liked)
Programmer Humor
32588 readers
929 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
CSP allows you to whitelist/blacklist arbitrary Javascript, and ideally you completely blacklist online js from being executed at all, such that only .js files of same domain can be invoked by your website.
This serves the role of locking down injection attacks, only your explicitly approved Javascript can be invoked.
HTMX enables invoking of logic via HTML attributes on HTML elements... which CSP can't cover
Which means you re-open yourself to injection attacks via HTML. Attackers can inject an HTML element with HTMX attributes and no amount of CSP will stop HTMX from going "Okey doke!" And invoking whatever the attributes say to do.
This effectively shoots even a completely locked down CSP config square in the nuts, totally defeating the entire point of using it.
It's a cute idea but what is needed is a way to pre-emptively treat HTMX as a template file that transpiles everything out so the ajax happens in a separate .js file
If we had that, then it'd be safe and secure, as the whole "htmx attributes on elements" thing would just be a templating syntax, but when transpiled it wouldn't be supported anymore so attackers can no longer inject html as an attack vector
This demonstrates a profound misunderstanding of HTMX, and how websites in general operate. So much so that I would not hesitate to describe this as somewhere between a baldfaced lie and just malicious incompetence. You can't "invoke logic via HTML attributes," but you can describe it. HTMX is a client side javascript library that parses custom elements you define in your HTML and uses the data described by them to initiate AJAX calls via the fetch() or XMLHttpRequest browser APIs, which CSP explicitly covers via the connect-src directive: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/connect-src. It's literally just a javascript library that parses HTML and uses it to parameterize AJAX calls. If HTMX were somehow able to bypass CSP, then every single piece of clientside JavaScript in the world could violate it.
Oh boy a semantic argument
Whatever you want to call it, trigger, invoke, whatever.
You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.
Trying to argue the semantics of this is stupid.
You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.
That's like, literally it's entire shtick.
And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.
"HTMX doesn't bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)"
It's bonkers how many people don't grok this, SMH.
I felt like I had a good understanding of both htmx and csp, but after this discussion I'm going to have to read up on both because both of you are making a logically sound argument to my mind.
I'm struggling to see how htmx is more vulnerable than say react or vue or angular, because with csp as far as I can tell I can explicitly lock down what htmx can do, despite any maliciously injected html that might try to do otherwise.
Thanks for this discussion 🙂
CSP works on the browser API level - all HTMX does is what you could do yourself with any AJAX: send an HTTP request to an endpoint. If the CSP disallows that endpoint, it will fail.