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. 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
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.
User provided content (post using custom emojis) caused havoc when processing (doesn’t matter if on server or on client). This is lack of sanitization of user-provided-data.
100%. Always act as though user provided content is malicious.
JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS.
Uh... what? JavaScript is a client-side language (unless you're using NodeJS, which Lemmy is not). Which means JavaScript runs in the browser. And that JavaScript has access to cookies, that's just a basic part of how web browsers work. Lemmy can't do anything to prevent that.
How the attacker got those JWTs? JavaScript sent them to him? Web browser sent them to him when requesting resources form his server? This is lack of site isolation, one web page should not have access to other domains, requesting data form them or sending data to them.
Again, Lemmy can't do anything about that. Once there's a vulnerability that allows an attacker to inject arbitrary JS into the site, Lemmy can't do anything to prevent that JS from making requests.
Then, if they want to administer something, they should log-in using separate username + password into separate log-in form and display completely different web page
On the backend you'd still have a single system which kind of defeats the purpose. Unless you're proposing a completely independent backend? Because that would be a massive PITA to build and would drastically increase the system's complexity and reduce maintainability.
all 11 comments