this post was submitted on 06 Jul 2023
65 points (97.1% liked)

Cybersecurity

5492 readers
214 users here now

c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.

THE RULES

Instance Rules

Community Rules

If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.

Learn about hacking

Hack the Box

Try Hack Me

Pico Capture the flag

Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !cybersecurity@lemmy.capebreton.social !securitynews@infosec.pub !netsec@links.hackliberty.org !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub

Notable mention to !cybersecuritymemes@lemmy.world

founded 1 year ago
MODERATORS
 

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.

top 23 comments
sorted by: hot top controversial new old
[–] lodion@aussie.zone 14 points 1 year ago (1 children)

Have you raised an issue on github for this? Its the best way to inform the devs.

[–] terribleplan@lemmy.nrd.li 11 points 1 year ago (1 children)

Damn... seems like there should be filtering to only allow http: and https: 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.

[–] terribleplan@lemmy.nrd.li 11 points 1 year ago (1 children)

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.

[–] hawkwind@lemmy.management 3 points 1 year ago (1 children)
[–] terribleplan@lemmy.nrd.li 2 points 1 year ago (1 children)

I believe if unsafe-inline were removed from script-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 in script-src is kinda worrying as well. Ideally you would lock the CSP down a lot more than they have.

[–] hawkwind@lemmy.management 0 points 1 year ago (1 children)

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.

[–] terribleplan@lemmy.nrd.li 1 points 1 year ago

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 on window to hydrate state from SSR to client-side they won't be able to change it without breaking things.

load more comments
view more: next ›