- cross-posted to:
- lemmy@lemmy.ml
- cross-posted to:
- lemmy@lemmy.ml
What is XSS?
Cross-site scripting (XSS) is an exploit where the attacker attaches code onto a legitimate website that will execute when the victim loads the website. That malicious code can be inserted in several ways. Most popularly, it is either added to the end of a url or posted directly onto a page that displays user-generated content. In more technical terms, cross-site scripting is a client-side code injection attack. https://www.cloudflare.com/learning/security/threats/cross-site-scripting/
Impact
One-click Lemmy account compromise by social engineering users to click your posts URL.
Reproduction
Lemmy does not properly sanitize URI’s on posts leading to cross-site scripting. You can see this working in action by clicking the “link” attached to this post on the web client.
To recreate, simply create a new post with the URL field set to: javascript:alert(1)//
Patching
Adding filtering to block javascript:
and data:
URI’s seems like the easiest approach.
Have you raised an issue on github for this? Its the best way to inform the devs.
deleted by creator
Damn… seems like there should be filtering to only allow
http:
andhttps:
URIs…Did you try the security email on github? I sent a vulnerability (that actually is way fucking worse than I thought given this issue) over a week ago and have heard nothing, so will be posting publicly soon.
Holy shit holy shit holy shit. Serious vulnerability confirmed. Combined with the issue(s) I have tried to report this is insane. I just tested this (and purged it so as not to publicly disclose just yet). This is really bad.
deleted by creator
If you find a way to disclose vulnerabilities without being ghosted by Lemmy developers: update me.
How have you been “ghosted by Lemmy developers” especially if you “do not use GitHub”
Yeah, I just wrote this up as a bug on github and added in that I tried to email them and to please get in contact about the other thing. Hopefully they see it. I can understand checking that email being overlooked considering how busy they likely are given the sudden influx and scaling issues.
Thank you, I was going to write one up tonight for it. You emailed security @ correct? https://github.com/LemmyNet/lemmy/security/policy
I tried to email that previously with a different issue and got no response. I was planning to post publicly (on github) about a different issue on Friday, but that other issue is now way too severe to do that now given how this can be leveraged to exploit what I found.
deleted by creator
It’s been a bit of a busy week for them. Maybe you can cut them some slack and try again?
Yeah, I found something that was “holy shit this is bad if someone finds a way to do X” and tried to report that but didn’t dig any deeper. This is X.
Does the default CSP do anything to mitigate this?
I believe if
unsafe-inline
were removed fromscript-src
then the CSP would block this.If the frontend depends on inline script tags then this likely can’t be changed super easily… The fact that
unsafe-eval
is inscript-src
is kinda worrying as well. Ideally you would lock the CSP down a lot more than they have.Aye, I am pretty sure CSP is bypass-able in most situations unless your pinning checksums or hashes. Just thought it might help take the edge off the hacker panic.
Yeah, it can certainly help in some cases, defense in depth and all that. If the CSP were ‘self’ (allowing any JS hosted on your domain) this would probably be DoA. Sadly, until the frontend stops using
<script>
to set things onwindow
to hydrate state from SSR to client-side they won’t be able to change it without breaking things.