this post was submitted on 10 Jul 2023
6 points (87.5% liked)

Programming.dev Meta

2466 readers
3 users here now

Welcome to the Programming.Dev meta community!

This is a community for discussing things about programming.dev itself. Things like announcements, site help posts, site questions, etc. are all welcome here.

Links

Credits

founded 1 year ago
MODERATORS
[email protected]
[email protected]
6
FYI: Lemmy.world and other instances were hacked. Beehaw.org took itself down to mitigate risks (lemmy.world)
submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/[email protected]
15 comments fedilink hide all child comments
 

Drawing attention on this instance so Admins are aware and can address the propagating exploit.

EDIT: Found more info about the patch.

A more thorough recap of the issue.

GitHub PR fixing the bug: https://github.com/LemmyNet/lemmy-ui/pull/1897/files

If your instance has custom emojis defined, this is exploitable everywhere Markdown is available. It is NOT restricted to admins, but can be used to steal an admin's JWT, which then lets the attacker get into that admin's account which can then spread the exploit further by putting it somewhere where it's rendered on every single page and then deface the site.

If your instance doesn't have any custom emojis, you are safe, the exploit requires custom emojis to trigger the bad code branch.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 0 points 1 year ago (1 children)

Oh I forgot another line of defense / basic security mitigation. If a server produces an access token (such as JWT or any other old school cookie / session ID), pair it with an IP address. So in case of cookie theft, the attacker cannot use this cookie from his computer (IP address). If the IP changes (mobile / WiFi / ADSL / whatever), the legitimate user should log-in again, now storing two auth cookies. In case of another IP change, no problemo, one of the stored cookies will work. Of course limit validity of the cookie in time (lets, say, keep it valid only for a day or for a week or so).

[–] [email protected] 1 points 1 year ago (1 children)

I'm sorry you want a mobile user to login every time their IP address changes? Why bother to keep them authenticated at all, just make them login for every web request. /s

[–] [email protected] -1 points 1 year ago

It is trade-off between convenience and security. With my approach stolen cookies are not usable from different computer / IP, the attacker needs additional work, he needs the victim computer to do the harm, his computer cannot do any harm. The downside is the user needs another log-in in case of his external IP changes. How often is it? Switch between mobile/WiFi. Otherwise ... almost never ... maybe 1x per day? I'm not proposing to log-out the user after IP change, I'm proposing to keep multiple sessions (on server) / auth cookies (on client) for each IPv4 or IPv6 prefix (let's say /56).