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.
I’m greatly surprised how Lemmy and the fediverse society has responded with this. The bug was found yesterday, maybe? And I’ve read about it three, four times (in different servers); a temporal solution was published in hours and it’s already patched on the repo.
Another victory for Open Source and the Fediverse in general.
More importantly the issue was tracked and resolved publicly.
The issue of trust in corporate spaces gets used to bury these things, this is a good model on how to restore it in the open.
I firmly believe open source is the future of software development and things like this really show off the strengths of this sort of collaborative work. Everyone benefits and it’s a great way to maintain high quality.
This is what happens when the people running a platform actually care about it and it's users
Security is crazy hard and having perfect security is impossible. Kudos to the dev team for resolving this so quickly.
In my opinion, the project would benefit from static vulnerability scanning. Low hanging fruit like this XSS would have definitely been flagged.
Most of those providers even give it out for free for open source projects. So it wouldn’t hurt.
So what happened:
Am I right?
I'm old-school developer/programmer and it seems that web is peace of sheet. Basic security stuff violated:
Am I right? Correct me if I'm wrong.
Again, web is peace of sheet. This would never happen in desktop/server application. Any of the bullet points above would prevent this from happening. Even if the previous bullet point failed to do its job. Am I too naïve? Maybe.
Marek.
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).
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
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).
And this is why you don't trust tankies. It's very easy to compromise the software and put back doors into it.
Use kbin instead.
And this is not me saying that this is a case of that, this is me saying that this could be the case in the future
And this is why you don’t trust tankies
What are you referring to here?
Tbf, there are far more pressing reasons for distrusting Tankies... Instances getting hacked is for sure aggravating, but it isn't the gulag-backed paranoid ultra-corrupt authoritarian hellhole they so admire and wish to expand globally.
This is a ridiculous take and fairly toxic. Don't ruin any communities with unnecessary hate. It's unwanted.
This is the dumbest possible take about the situation, my lord.