3 ms·
The amount of javascript is really beside the point here. The problem is that privileged users can easily edit the code without strong 2FA, allowing automatic p
by dns_snek 8mo ago
The amount of javascript is really beside the point here. The problem is that privileged users can easily edit the code without strong 2FA, allowing automatic propagation.
- shevy-java 8mo agoHow does 2FA prevent this here?
- dns_snek 8mo agoIf they required 2FA every time you wanted to modify JS then it couldn't propagate automatically. Just requiring 2FA when you first log in wouldn't help, of course.
- j45 8mo ago2FAs also may require a level of KYC that Wikipedia isn't after and advocating for 2FA might indirectly advocate for a lot more things than just 2FA.
- dns_snek 8mo agoKYC? I'm talking about standard 2FA methods like Time-based OTP codes.
- msla 8mo agoMore to the point, if they required 2FA every time you tried to modify the JS, nobody would do it because it would be too annoying. "Username, password... oh, the 2FA just timed out, gotta wait for the next one... what, that doesn't work? Does it want the old one? Oh... now it wants the next one... just a second... "
- zelphirkalt 8mo agoBut only one person needs to authenticate to edit. The code will still run for everyone loading it.
- j45 8mo agoIt's not, application logic exposed on the client side is always an attack vector for figuring out how it works and how attack vectors could be devised. It's simply a calculated risk. How much business and application logic you put in your Javascript is critical. On your second unrelated comment about Wikipedia needing to use 2FA, there's probably a better way to do it and I hope mediawiki can do it.
- dns_snek 8mo agoI don't know what you mean by application logic being exposed client-side. To change the content on the website, nuke articles, and propagate the malicious JS code you need to hijack privileged users' credentials and use them to trigger server-side actions. It doesn't matter how much functionality the JS was originally responsible for, it could've been as little as updating a clock, validating forms, or just some silly animation. Once that JS executes in your browser it has access to your cookies and local storage, which means it can trigger whichever server-side actions it wants. My second comment is not unrelated. The root cause of this mess is the fact that JS can be edited by privileged users without an approval process. If every change to the JS code required the user to enter their 2FA code (TOTP, let's say) then there would be no way for the worm to spread whenever users visited a page.
- j45 8mo agoAh, I’m not speaking about JavaScript within the content of wikipedia as you are. I’m referring to the use of JavaScript in general in the building of web apps themselves. My comment is the same about 2FA. I’m making these comments from the general perspective because I see it as a security risk when front end scriptability and app logic are more available than say server side apps. Hope that clarifies my comments.