this post was submitted on 10 Jul 2023
3286 points (99.3% liked)
Lemmy.World Announcements
29042 readers
3 users here now
This Community is intended for posts about the Lemmy.world server by the admins.
Follow us for server news ๐
Outages ๐ฅ
https://status.lemmy.world
For support with issues at Lemmy.world, go to the Lemmy.world Support community.
Support e-mail
Any support requests are best sent to info@lemmy.world e-mail.
Report contact
- DM https://lemmy.world/u/lwreport
- Email report@lemmy.world (PGP Supported)
Donations ๐
If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.
If you can, please use / switch to Ko-Fi, it has the lowest fees for us
Join the team
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Does an admin account have any permissions to view email addresses or data of registered users?
Did MichelleG not have 2FA enabled?
Now that this has happened, it's be worth pushing this issue through as high priority. If
HttpOnly
was enabled, then an admin takeover would not have been possible.https://github.com/LemmyNet/lemmy-ui/issues/1252
The JWT exploit bypasses 2FA requirements. It basically steals your active session and allows a third party to use it.
Good point. I suppose the only way to fix that particular issue to disallow cookie authentications from a new location
If by location you mean IP address, the XSS script could also send the IP address of the user to the attacker. Then the attacker could do write operations spoofing that IP. They wouldn't get a response but the write operation would be done anyways.
Maybe doing a 3 way handshake before every administrative action to ensure the IP wasn't spoofed? Idk, I'm not a security person.
User sends IP and JWT + administrative action. I mean, IP is extracted from src addr, not sent.
Server saves the command in a cache with a TTL of 10 seconds. Then sends a randomly generated string to the user. The random string is sent in A HTTP-only same-site cookie to avoid it being read by JS scripts or being sent to external domains.
The user sends it's JWT + randomly generated string cookie back to the server. The server checks the cache. If an action is found, it is executed.
Edit: actually, after thinking about it. If the XSS is not sending the JWT to a remote location but running the attack directly in the victim's browser, there's nothing that can be done. XSS is fucked up.
Using proper cookie flags can also mitigate this. I am not sure there is a reason to have the session cookie accessible via JS. HttpOnly flag alone could have helped here.